summaryrefslogtreecommitdiffhomepage
path: root/src/Xmobar.hs
AgeCommit message (Collapse)Author
2014-02-20Change actions syntaxMarcin Mikołajczyk
2014-02-18Add support for multiple actions per item, activated depending on mouse ↵Marcin Mikołajczyk
button clicked
2013-03-13Help type inferencer a bit, kills warningAlexander Polakov
2013-03-13Fix actions for right side of the barAlexander Polakov
totSLen was wrong
2013-03-13Use fmap instead of >>=Alexander Polakov
2013-03-13Introduce ActionsAlexander Polakov
Actions are event re-actions. Currently only ButtonPress event is handled by Actions and only one action is defined, which is called Spawn (run external command). Type (and parser) can be extended to EWMH actions (switch to desktop, close window, whatever).
2013-02-04Better icon alignmentAlexander Polakov
2013-02-04Use real icon widthAlexander Polakov
2013-02-03Fixes for previousAlexander Polakov
2013-02-03Implement icon cachingAlexander Polakov
2013-01-27XBM icon supportEdward O'Callaghan
<icon=/path/to/icon>
2012-10-08Fixes for warnings reported in github issue #71Jose Antonio Ortega Ruiz
2012-09-11Avoiding X server leaks with XftColor cacheJose Antonio Ortega Ruiz
This patch is a first complete solution to the long-standing memory leak (on the X server side) caused by repeteadly asking the server to allocate XftColor instances. Despite the fact that we were freeing them, the server didn't seem to care... this was also happening for non-Xft Colors, and solved in the same way we'd done here, i.e., by caching XftColor instances. And additional complication has been that Graphics.X11.Xft doesn't export any function to create and retain an XftColor, nor the necessary datatype constructors to write a compatible version outside the module (there's no way to construct an XftColor instance to pass to the other functions in the library). So, i've created my own lite version of the whole module, until the day it supports XftColor creation.
2012-09-10New module ColorCacheJose Antonio Ortega Ruiz
2012-09-09Missing Window module in cabal fileJose Antonio Ortega Ruiz
2012-09-09Correct vertical alignment for XFT fontsJose Antonio Ortega Ruiz
2012-09-01Some cosmetic fixes.Jochen Keil
I tried to scrap the hide/reveal boilerplate, but that didn't work out due different functions ({show,hide}Window) and signaltypes. Got almost as ugly. Maybe a pattern matching function instead of the "case typ of" would be nicer. But that's just code golfing.
2012-09-01Set StrutValues from showWindowJochen Keil
This is superior to calling the repositionWin function. It will only set the StrutValues and avoid additional work. This means, that extra parameters need to be passed down to showWindow. However, that is not a problem here.
2012-09-01Pass the timeout value unchanged to the toggle functionJochen Keil
Since the timeout is passed on as hide or reveal signal, it must not be changed or the multiplications will pile up.
2012-09-01Send hide or reveal signal for togglingJochen Keil
This is a more abstract way of implementing the Toggle operation.
2012-08-22Make it possible to delay Hide, Reveal and Toggle signalsJochen Keil
Previously Hide, Reveal and Toggle were immediate actions. This is the same behaviour as if called now with 0 as parameter. If the parameter is a positive non zero value it is taken as a delay for the requested action. After the delay (implemented using threadDelay) a new signal is sent with zero with no timeout being effective immediately. This is necessary to evaluate the persistency flag after the delay because it might have changed in the meantime. Effectively this means that it is possible to cancel the delayed operation by calling TogglePersistent.
2012-08-22Refactor MVar SignalType to TMVar SignalTypeJochen Keil
Replace MVar with TMVar from the STM package. This is common for ghc now. Since STM is used everywhere else in the src it also adds no additional dependencies. The main reason for this switch is, that readMVar, swapMVar, etc. are only atomically if there is no other producer for this MVar i.e. putMVar. For example readMVar is a combination of putMVar and takeMVar. Due to scheduling and readMVar's non-atomicity it is possible that values written to the MVar appear in the wrong order. Using TMVar fixes this problem, since it allows really atomical read/swap operations.
2012-08-13Missing file headers and lintingJose Antonio Ortega Ruiz
2012-08-13Revert lowerOnStart to its original behaviourJochen Keil
I misunderstood the intention of lowerOnStart and changed the implementation to what I thought it would have to do. This was wrong indeed, so back to original behaviour.
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.
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-01 13:59:27 +0000