| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
Conflicts:
src/Config.hs
src/Main.hs
src/Parsers.hs
src/XUtil.hsc
src/Xmobar.hs
|
|
|
|
Conflicts:
src/Xmobar.hs
|
|
For all <icon=path/> if path does not start with "/", "./", "../"
it will have iconRoot ++ "/" prepended to it.
|
|
|
|
|
|
the baseline (valign) is now set so the font will render with
equal vertical margin above and below the font extents
|
|
|
|
|
|
button clicked
|
|
New configuration option 'alpha' which adjusts alpha transparency
(0 is transparent, 255 is opaque).
Signed-off-by: Edward Z. Yang <ezyang@mit.edu>
|
|
|
|
totSLen was wrong
|
|
|
|
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).
|
|
|
|
|
|
|
|
|
|
<icon=/path/to/icon>
|
|
|
|
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.
|
|
|
|
|
|
|
|
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.
|
|
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.
|
|
Since the timeout is passed on as hide or reveal signal, it must not be
changed or the multiplications will pile up.
|
|
This is a more abstract way of implementing the Toggle operation.
|
|
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.
|
|
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.
|
|
|
|
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.
|
|
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.
|
|
Actually run this stuff
|
|
By sending a TogglePersistent signal the configuration option
"persistent" can be changed. Thus it is possible to hide or show xmobar
constantly.
|
|
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.
|
|
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.
|
|
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.
|
|
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.
|
|
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.
|
|
Fixes #36
|
|
|
|
|
|
|
|
|
|
|
