| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
readDefaultConfig should prefer $XDG_CONFIG_HOME/xmobarrc if it exists, however the code was always reading path. This fixes the logic to actually use xdgconf if it exists.
|
|
Avoids an extra dependency.
|
|
|
|
|
|
|
|
|
|
This reverts commit cae6f2bc049d4b7ed57a7a18a828bc4ea35df4aa, until we
find a reason why it's causing high CPU consumption in the X server.
|
|
This makes xmobar work in windowmanagers that support _NET_WM_WINDOW_TYPE_DOCK
but not _NET_WM_STRUT, such as Notion
|
|
Realign methods, remove unnecessary imports and remove clutter
|
|
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.
|
|
|
|
Using the -C option, *additional* commands can be given to Xmobar. This
allows a common configuration to be used and then differentiated in just
the -C calls.
|
|
|
|
|
|
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.
|
|
|
|
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.
|
|
This way we also avoid issue 30, although we're not solving the real
issue (which is that the commands parser cannot correctly parse
commands with a single argument unless they appear at the end of the
list).
|
|
|
