| Age | Commit message (Collapse) | Author |
|---|
|
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 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
|
|
|
|
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.
|
|
Fix build failure: safeHead is needed even when dbus isn't.
|
|
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).
|
|
|
|
|
|
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.
|
|
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.
|
|
This commit updates the mpris plugin to use the DBus 0.10 interface.
DBus-Core does no longer exist and is deprecated.
DBus 0.10 does not use proxies anymore.
The dependency on Data.Text also disappeared.
Since I do not have/use mpris I cannot test if this works. It should
however, since the functionality was just transformed to use the new
interface.
|
|
Actually run this stuff
|
|
This belongs here, otherwise ghc will complain about orphaned instances
|
|
safeHead is a very general utility function with suits better into a
common Util module.
|
|
|
|
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.
|
|
The window became hidden although the toggling behaviour was set to
False for a particular pipe. This fixes this behaviour and hides the
window only if the configuration option is set to True.
|
|
This solves a problem when there is only one pipe in place. With a
default value of "" and only one pipe with a timeout the value is
overwritten with "" after the timeout. To prevent this from happening a
TMVar is used which will never be filled if there is only one pipe.
|
|
Using the trigger method activity on a pipe can now cause the window to
appear (reveal) and disappear again after a given timeout. The timeout
for hiding the window is the same as for restoring the pipes content.
The timeout value is given in tenth of seconds.
|
|
Realign methods, remove unnecessary imports and remove clutter
|
|
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.
|
|
Also: realign methods to look pretty again.
|
|
Also make them {Read,Show}able which can be useful for printf debugging
and does not hurt otherwise.
|
|
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.
|
|
This plugin allows to display data from multiple pipes.
New data will always overwrite the currently displayed data.
However, if a timeout is specified, the previous content is restored.
Configuration works like this:
BufferedPipeReader <Alias> [ ( Timeout, "/path/to/fifo/pipe" ), (..), .. ]
If Timeout is set to 0 then the content is persistent, i.e. it will be
reset to any previous value, it will itself become the previous value.
If Timeout is set to a negative value the earth will stop spinning, so
don't do it.
|
|
We're using now the recommended statvfs interface, instead of the
obsolete statfs64. Moreover, we compute correctly the used space.
|
|
Conflicts:
xmobar.cabal
|
|
|
|
Now all values are returned as 'Value' wrapped entries.
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
|
|
|
|
|
|
This allows monitors to define update times other than time-based.
|
|
Fixes #36
|
|
Since a kernel upgrade about two months ago, DiskU just blows up my
xmobar apparently at random.
|
|
|
|
|
|
|
