| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
This reverts commit 0fec9d3fdf9bc86187f9f670dafd2ef57fe03f29.
Mouse actions can already be attached to the monitor, and for instance use
there invocations to setxbdmap to switch layouts.
Fixes #703.
|
|
|
|
|
|
Previously, xmobar would ignore SIGCHLD, but only when the configuration
is recompiled. This means child processes would not leave zombies, so
that waiting for them to exit (either directly by calling
waitForProcess, or indirectly through another function from
System.Process, like system or readProcessWithExitCode) would produce an
error. This breaks the Alsa, Com (#657) and NotmuchMail plugins, as well
as the <action> tag (#687) and low battery action (#688).
As far as I can tell, bracketing the recompilation in
uninstallSignalHandlers and installSignalHandlers was inherited from
xmonad. In xmonad, SIGPIPE and SIGCHLD are always ignored
(installSignalHandlers is called at the start of xmonad and launch), so
the bracket is necessary to be able to wait for the compiler or build
script to exit. Since xmobar does not otherwise ignore the signals, it
is not necessary to change signal handlers at all during recompilation.
Removing it leaves the default action for SIGCHLD, which fixes the
issues described above.
Fixes #657, #687 and #688.
|
|
This effectively reverts c54d93e and 991a168. While those fix #687 and
#688 respectively in the case where the configuration is recompiled, in
all other cases they leave zombie processes, since they undo the fix for
#181.
However, instead of reverting to the deprecated system function, we use
the newer spawnCommand and waitForProcess. And like with 991a168, the
low battery action now runs in the background to avoid blocking the bar.
|
|
|
|
|
|
should fix for real #688 this time
|
|
This should address the problems reported in issue #688
|
|
Haskell libraries can be linked statically or dynamically. Either way, all packages must be linked the same way. This means that if all dependencies of `xmobar` are shared libraries, then `xmobar` itself must be built using dynamic linking.
Therefore, to compile the individual `xmobar` executables, add the `-dynamic` flag to signal that they are built with shared libraries.
This flag is put behind an #ifdef to easily configure static vs dynamic linking.
To use shared libraries, define SHARED_LIBRARIES
|
|
|
|
|
|
|
|
Extends the solution from 8a53271cd6 to also handle SocketError, so that the process will not terminate. See also issue #537.
|
|
|
|
|
|
|
|
|
|
Might help with #655
|
|
|
|
Adds a new DPI configuration, especially useful for HiDPI displays. This changes the scaling factor for fonts as displayed by Pango. It defaults to 96.0 which corresponds to an average screen and is the default in [Cairo](https://hackage.haskell.org/package/pango-0.13.5.0/docs/Graphics-Rendering-Pango-Cairo.html#v:cairoFontMapGetDefault). It's also possible to supply a zero or negative value to use the default scaling factor, but I felt setting the default to 96.0 makes it more explicit.
It also adds a matching command line option.
I haven't tested it too thoroughly, but in my limited use it appears to be working as intended.
One thing this does not do is scale XBM and XPM bitmap files which I'm unsure how to do or if that should even be our concern (instead leaving it up to the user to supply appropriate bitmaps).
Co-authored-by: Jonathan Grochowski <jon@grocho.net>
Reviewed-on: https://codeberg.org/xmobar/xmobar/pulls/660
Co-authored-by: jgrocho <codeberg@jon.grocho.net>
Co-committed-by: jgrocho <codeberg@jon.grocho.net>
|
|
|
|
|
|
|
|
should make things better for #650 and #655
|
|
|
|
|
|
- TopHM: Top position with left/right/top margins and specific height
- BottomHM: Bottom position with left/right/bottom margins and specific height
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
