| Age | Commit message (Collapse) | Author |
|---|
|
* Removed PipeReader2
* PipeReader pipename can be prefixed with default. (e.g. "I am default:/home/foo/pipe")
|
|
|
|
|
|
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.
|
|
For a ChangeScreen or Reposition signal the setProperties function is
called which sets the StrutValues regardless of the mapping state.
This means that for an unmapped window a window manager will produce an
empty gap. Fixing this is easy. Just set the StrutValues to 0.
|
|
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.
|
|
This reverts commit f7076307b7e896e6d776e319fddff860b63f735f.
|
|
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
|
|
|
|
|
|
|
|
Conflicts:
readme.md
|
|
Mainly code from my config which does the following:
When I press my modifier key (which is xK_Alt_L) then xmobar appears.
When I keep the key pressed for longer than 400ms (which is often the
when tabbing through windows, changing workspaces, etc), then upon
release xmobar will be hidden immediately. If I press xK_Alt_L for less
than 400ms (very briefly), then xmobar pops up, and will automatically
disappear after 2 seconds.
|
|
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.
|
|
It's easy to implement, since arguments to dbus method calls are handed
over as list anyway. It also removes the need for safeHead.
Bottom line: extra functionality without extra cost.
|
|
|
|
Following the discussion of pull request #59 in github.
|
|
Following the discussion of pull request #59 in github.
|
|
Fix build failure: safeHead is needed even when dbus isn't.
|
|
Conflicts:
readme.md
|
|
|
|
When set to True the window is initially not mapped, i.e. hidden. It
then can be toggled manually (for example using the dbus interface) or
automatically (by a plugin) to make it reappear (unhide/reveal).
|
|
The problem was a race condition which occured when running multiple
threads with a small timeout value. Then the TMVar could be left empty.
(e.g. hitting a key which causes an operation to write to the pipe very fast)
This meant that tryTakeTMVar would return Nothing which would cause all
subsequent reset threads to not call cb and keep a stale string on
display.
By using a Maybe String wrapped in a TVar there is always a valid value
available which can be used to restore the display (or not if it's
Nothing, but that's desired then and not because another thread was
scheduled earlier).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This is a bash script, so for correctness is needs to be /bin/bash
|
|
Only one process can export the dbus interface at a time.
|
|
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.
|
|
This sample script uses colors and unicode signs for drawing a status
bar for e.g. volume. The unicode character can be simply changed to an
ascii one in case of problems.
|
|
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.
|
|
connectSession throws a ClientError Exception when
DBUS_SESSION_BUS_ADDRESS is unset. Without exception handler this will
result in program termination.
Since the DBus handler merely sends a signal to the event loop it does
no harm when it won't run. Normal operation will continue just if
compiled without dbus support.
|
