| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
Thinking of eventually adding a Sway JSON output, or simply add fonts
to Pango specification, so it's more than colors.
Also, NoColors -> Plain.
|
|
|
|
Signed-off-by: Pavel Kalugin <pavel@pavelthebest.me>
|
|
Signed-off-by: Pavel Kalugin <pavel@pavelthebest.me>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* Address code review comments on ipc-improvements.
|
|
|
|
|
|
We are now—in case the user specified a Haskell file as their xmobar
configuration—threading the command line arguments that xmobar receives
to the relevant execv() call. However, we simply shove in all arguments
originally given to xmobar, including the path to the configuration
file. As main is now defined within that very file, this seems
unneccessary.
By filtering out that part of the arguments, the pattern that a lot of
users seem to follow for easy setting of certain options becomes a
little bit nicer. For example:
main :: IO ()
main = getArgs >>= \case
["-x", n, _] -> xmobar . config $ read n
_ -> xmobar $ config 0
becomes
main :: IO ()
main = getArgs >>= \case
["-x", n] -> xmobar . config $ read n
_ -> xmobar $ config 0
Related: https://github.com/jaor/xmobar/pull/553
|
|
|
|
The cpp option `-DRTSOPTS` results in `RTSOPTS` being defined.
|
|
This fixes the following crash that happens with the default xmobar
configuration (using HOME=/ makes xmobar ignore ~/.xmobarrc):
$ echo "<fn=1>x</fn>" | HOME=/ xmobar
xmobar: Prelude.!!: index too large
Commit 3e9e1cb9d300 ("Fix crashes/busy looping happening via index")
meant to fix this but apparently it only fixed indexing of fontlist, not
voffs, so the crash was still there.
Fixes: https://github.com/jaor/xmobar/issues/504
|
|
Provide an option the user can specify any number of times to add to the
additionalFonts config field.
|
|
|
|
ColorInfo contains background offsets, it is no longer only about colors
TextRenderInfo can hold information such as color, offsets, etc
|
|
Implemented only for XFT fonts.
Adds a new "part" in the fc tag.
> Example: <fc=white,gray:0>foo bar</fc> will make the font background
as tall as the bar (absolute offset, here set to 0 for both top &
bottom)
Changes ColorString to ColorInfo, containing both top and bottom
offsets. The "colors string" is still in only one string.
|
|
|
|
By checking full paths, instead of just dirs (option 1).
|
|
Right now, with the `StdinReader` plugin enabled - you can crash/cause
busy looping of xmobar if the following html file is opened:
```
<html>
<head>
<title>hello <fn=1>string</fn> </title>
</head>
</html>
```
More details about this bug is here:
https://github.com/jaor/xmobar/issues/442#issuecomment-625706001
This MR also fixes another bug which produces a crash in xmobar if you
pass non integer items between fn:
<fn=crash>
|
|
|
|
|
|
This corrects my (wrong) assumption that the timer coordination thread
will only fail if there's an error in the code, and in that case any
attempt to recover is futile. It turns out that the thread does fail
recoverably in one notable case: when running in the non-threaded RTS,
registerDelay fails immediately. And we probably still wish for xmobar
to support the non-threaded RTS.
One way to solve this issue is to add a bunch of #ifdefs and compile the
code only in the threaded case. This would double the number of
configurations that need to be tested, though.
Instead, let's make the code robust against all kinds of exceptions in
the timer coordination thread, and get non-threaded RTS support for
free.
|
|
The first implementation assumed all timers (monitors) are fast and
frequent (which happens to be the case in my configuration). This meant
that a single on-line weather monitor could block the entire xmobar
instance for a long time due to the refresh pausing (meant to reduce
power consumption).
This commit attempts to fix that by limiting the refresh pause time and
using the old periodic sleep method for these slow timers (monitors).
|
|
xmobar currently runs every monitor in its own thread. Monitors that do
periodic updates simply sleep and loop. This unfortunately leads to
these threads coming out of sync, and xmobar ends up waking up and
redrawing for every periodic monitor. In my case, that is 7 times per
second, which is enough for xmobar to be at the top of "top" with more
than 1% CPU usage, and to have a noticeable impact on battery life.
This commit adds a central timer coordination thread which makes sure
that periodic updates happen together and that we only redraw once
they're all done.
Together with PR #409, I managed to lower the idle power draw of my
laptop from 4W to 3W.
|
|
src/Xmobar/X11/Draw.hs:51:11-12: warning: [-Wunused-matches]
Defined but not used: ‘wr’
|
51 | drawInWin wr@(Rectangle _ _ wid ht) ~[left,center,right] = do
| ^^
src/Xmobar/App/EventLoop.hs:50:1-36: warning: [-Wunused-imports]
The import of ‘Xmobar.X11.Events’ is redundant
|
50 | import Xmobar.X11.Events(nextEvent')
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
This time taking into account that ~/.config/xmobar could be populated
|
|
|
|
Write xmobar.errors to XMOBAR_DATA_DIR, not XMOBAR_CONFIG_DIR. This
allows XMOBAR_CONFIG_DIR to be read-only. This brings xmobar into
alignment with how xmonad manages its analogous directories (before this
change, a read-only DATA dir worked with xmonad but not with xmobar).
|
|
|
|
|
|
|
|
Should take care of issue #371
|
|
Fixes #370, and then some
|
|
|
|
|
|
|
|
|
|
|
