summaryrefslogtreecommitdiffhomepage
path: root/src/Xmobar.hs
AgeCommit message (Collapse)Author
2012-08-12Run the DBus/IPC handler only once on program startJochen Keil
The startCommand function is called for every configured plugin. This results in multiple calls to runIPC. This it not necessary however. startLoop is a much more appropriate place, since the other signal handler (checker and eventer) are run here to.
2012-08-10Run the DBus event handler in startCommandJochen Keil
Actually run this stuff
2012-08-10New SignalType TogglePersistentJochen Keil
By sending a TogglePersistent signal the configuration option "persistent" can be changed. Thus it is possible to hide or show xmobar constantly.
2012-08-10New configuration option "persistent"Jochen Keil
When persistent is set to True then xmobar will always be mapped (revealed) and never be hidden. The flag is checked in eventLoop and operation to map/unmap windows is not carried out if persistence is desired.
2012-08-09Add functions for {reveal,hid,toggl}ing the windowJochen Keil
Toggling is based is based on the current window status. If unmapped then reveal else hide. Sync is necessary or delays might occur. The functions are called from the event loop when the according signal is received When mapping (revealing) the window again we need to set the struts property again. The easiest way to do this is to call repositionWin. However, repositionWin needs access to the Config structure which is available in eventLoop. Because decomposition wouldn't be easy and I don't want to pass Config down to showWindow (which would need to return the new Rectangle then) this is done here.
2012-08-09Create signal handler in main and pass it down to the start* functionsJochen Keil
This is necessary for setting up the signal callback (trigger) from the Plugin interface. As another benefit it is now possible to implement the lowerOnStart config option properly by simply sending a Hide signal in startLoop.
2012-08-09Move signal handler and data types to own moduleJochen Keil
This is necessary to make SignalType available for other modules without import loops. This also decoupels the modules and their functionality a bit more so this is generally a cleaner solution.
2012-08-09Modularize Window handling functionsJochen Keil
These functions are about creation, positioning and property setting of the xmobar window. An own module does them justice and eases the task of adding functions for revealing/hiding and toggling the window.
2012-06-04Added --with_threaded configuration flagJose Antonio Ortega Ruiz
Fixes #36
2012-05-05LintingJose Antonio Ortega Ruiz
2012-05-05Redundant import Foreign removedJose Antonio Ortega Ruiz
2012-03-11Use Xrandr support from the X11 packageBen Boeckel
2012-01-14Remove dependency for ghc's threaded runtimeMartin Perner
2011-12-18Better vertical alignment (stab at #56)Jose Antonio Ortega Ruiz
2011-11-16Partial attempt at better vertical alignmentJose Antonio Ortega Ruiz
2011-09-19Refactored eventLoopMartin Perner
2011-09-16Changes signals usedMartin Perner
Switches HUP to USR1 and USR1 to USR2, as requested
2011-09-11Minor cleanupMartin Perner
2011-09-10Wrong value used to check for xrandr eventMartin Perner
Didn't tested xrandr events with that event detection. Notify value is 0, the one used (keypress) is 1
2011-09-10moved signal handler setup into eventloopMartin Perner
2011-09-10removed threading problem with XlibMartin Perner
The output just stopped at some point until a new XEvent was received As XLockDisplay is in theory a good idea, with XNextEvent blocking its not usable. As it turned out, a window can be shared between display connections. Now the eventloop has its own display connection (which also removes the need for the lock introduced before). Additionally the screeninfo doesn't need to be fetched into a TVar in the eventerloop anymore. Also this was needed for the signalHandlers to work correctly again.
2011-09-09complete reword of the eventLoopMartin Perner
*) replaced window destroy and create with a reposition *) replaced the exception for redraw with an MVar *) put nextEvent into an own thread, communication over the MVar *) signal handlers for repositioning and screen swap Notes: *) getScreenInfo is a parameter of eventLoop because it blocks when there is an nextEvent waiting for an new event
2011-08-31Working versionMartin Perner
The last commit removed the exposure event which turned out to be a big problem. Although the bug still exists that not all xrandr events are received when normal events are enabled. To work around this problem a second display is created on which only the xrandr events are enabled. On an exposure event the eventqueue for this display is processed. The results are very good, in the worst case an exposure event must be triggered by the user on xmobar to update its position.
2011-08-31Update on Screen change worksMartin Perner
But I'm not sure if something is broken now...
2011-08-30Init commitMartin Perner
handle doesn't get all events. simple c program and simple haskell program are getting all of them. there must be something in xmobar which catches about 3 of the screenchange events ...
2011-08-21Show invalid input in case of parsing error in templateJose Antonio Ortega Ruiz
As a side-effect, parts without substitution vars will be displayed as-is, fixing a bug reported by RC in the mailing list.
2011-02-03More XPROPS for the xmobar execJose Antonio Ortega Ruiz
2011-01-22Wee refactoringJose Antonio Ortega Ruiz
2011-01-22Bug fix: don't get confused by align separators in input (issue 14)Jose Antonio Ortega Ruiz
This solves the common case of a template separator character (such as {) popping up in xmobar's input (e.g., inside a window title) and confusing the parser.
2010-12-27LintingJose Antonio Ortega Ruiz
2010-12-27Bug fix: correctly center text verticallyJose Antonio Ortega Ruiz
2010-12-27Fix for FullBM border specificationJose Antonio Ortega Ruiz
2010-12-27Respect height in BottomSize (issue 27)Jose Antonio Ortega Ruiz
2010-12-21Haskell sources moved to src/ to unclutter toplevelJose Antonio Ortega Ruiz