| Age | Commit message (Collapse) | Author |
|---|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Switches HUP to USR1 and USR1 to USR2, as requested
|
|
|
|
Didn't tested xrandr events with that event detection.
Notify value is 0, the one used (keypress) is 1
|
|
|
|
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.
|
|
*) 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
|
|
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.
|
|
But I'm not sure if something is broken now...
|
|
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 ...
|
|
As a side-effect, parts without substitution vars will be displayed
as-is, fixing a bug reported by RC in the mailing list.
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
