| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
* Address code review comments on ipc-improvements.
|
|
|
|
|
|
|
|
For start cirrus please use:
https://cirrus-ci.org/guide/quick-start/
choose public repositories plan and add only xmobar as observed by cirrus.
Also here is addes small fix for dividing by zero when cpu usage is calculated
|
|
Using this library allows us to receive swap info which is more
similar with result of command swapinfo.
|
|
In FreeBSD /proc/pid/stat is missing we should use for top procstat
library.
|
|
|
|
We should make better split os specify code for FreeBSD and Linux.
Idea comes from @liskin.
|
|
in freebsd swap info is available by sysctl
|
|
In freebsd /sys/class/net is absent so we should use sysctl for
obtaining info about stats of network.
For parsing if_data struct we could use a "Foreign.Storable"
|
|
In freebsd /proc/memoryinfo is absent so we should use sysctl for
obtaining info about stats of memory.
|
|
* A queue reader for xmobar using `TQueue a` from `stm`.
This is a flexible and performat solution for sharing
data between arbitrary haskell and xmobar.
* I am not sure if I did the haddocks correctly.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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 automatically derived read instance expects the type to be given in
record syntax; this is not what most users want. In order to simply
specify the type via
Run NotmuchMail "mail" [MailItem "name" "" "tag:unread"] 3000
we have to write our own Read instance.
Related: https://github.com/jaor/xmobar/issues/547
|
|
This is needed for the plugin to parse properly in non-Haskell based
configurations.
Related: https://github.com/jaor/xmobar/issues/547
|
|
programmatically
|
|
|
|
The existing support for the coretemp kernel driver only works with
Intel CPUs.
This commit extends support for temperature monitoring to AMD CPUs.
k10temp is a kernel driver for monitoring the temperature of AMD
processors. It supports everything from AMD's 10h (Opteron/Athlon)
family of processors to the latest 19h (Zen 3) family.
Reference: https://www.kernel.org/doc/html/latest/hwmon/k10temp.html
The meaning of the various temperatures made available has changed over
the years and only `Tctl` is available on processors prior to the 17h
family.
Labels for these temperatures are present but as Tctl and Tdie do not
contain a number I could not find a way to use these as
`checkedDataRetrieval` expects an integer label.
It is a PCI device and so an address needs to be supplied as part of the
configuration.
Example configuration:
`Run K10Temp "0000:00:18.3" ["--template", "T: <Tdie>C | <Tccd1>C"] 60`
|
|
While using xmobar to reproduce/fix a bug in xmonad I noticed that
xmobar doesn't react immediately to the signals to reposition or change
screen.
Apparently none of the Xlib functions called from `repositionWin` flush
the Xlib output buffer (XMoveResizeWindow is known to not flush,
although it's unfortunately not documented), so when compiled with the
threaded runtime that runs XNextEvent in a separate thread, the
reposition is sent to the X server only later when other stuff happens.
With all monitors set to refresh once a minute, this can take a looong
time.
(It's entirely possible this happens even without the threaded runtime,
I didn't test that, sorry.)
The fix is to call XSync at the end of `repositionWin`.
While at it, I spotted that drawInWin calls XSync with discard=true,
which seems like a mistake. We don't want to discard any events, do we?
(In practice, I'd expect the `eventer` thread to read all events even
before the drawing thread manages to discard them, so even if this
discarding XSync ever had any reason to be there, I don't think it does
anything meaningful these days. I may be wrong, though.)
|
|
This reverts commits c6669e26e1 (partially; changelog entry kept),
73e02934d6, 78efa5900a.
These commits were introduced as a workaround for a double UTF-8
encoding bug in xmonad-contrib which itself was meant to be a
fix/workaround for another issue. We have now identified the underlying
issue and fixed it right at the root, so this entire cascade of hacky
(and wrong) workarounds can be safely reverted. Thankfully, none of the
xmonad-contrib hacks made it into a release, so there's no backward
compat to worry about.
Should anyone be interested in the details,
https://github.com/xmonad/xmonad-contrib/commit/63e31ccd8d2865863778207b679f806941bf2788
provides a summary and links to all the related issues and PRs.
Related: https://github.com/jaor/xmobar/pull/482
Related: https://github.com/jaor/xmobar/issues/476
Related: https://github.com/xmonad/xmonad-contrib/commit/63e31ccd8d2865863778207b679f806941bf2788
Related: https://github.com/xmonad/xmonad-contrib/pull/471
Related: https://github.com/xmonad/xmonad-contrib/issues/377
|
|
hlint started failing recently:
src/Xmobar/X11/Text.hs:121:32: Error: Parse error: on input `-'
Found:
textExtents (Utf8 fs) s = do
let (_,rl) = wcTextExtents fs s
> ascent = fromIntegral $ - (rect_y rl)
descent = fromIntegral $ rect_height rl + fromIntegral (rect_y rl)
return (ascent, descent)
It's probably a change in the parser or something, didn't really look
into it, just changed it to something that's parsable.
|
|
Pixel intervals in _NET_WM_STRUT_PARTIAL are closed, not open [1], so
xmobar of width 1920 at x=0 needs to be encoded as ⟨0, 1919⟩, not ⟨0,
1920). The code already does this for Top/Bottom positioning, but Static
has been buggy for years.
[1]: https://specifications.freedesktop.org/wm-spec/1.5/ar01s05.html#idm46075117229424
Fixes: https://old.reddit.com/r/xmonad/comments/mynegr/xmobar_dual_monitor_bug/
Fixes: https://github.com/jaor/xmobar/issues/530
|
|
|
|
The cpp option `-DRTSOPTS` results in `RTSOPTS` being defined.
|
|
|
|
This plugin checks for new mail, provided that this mail is indexed by
notmuch. As mail that was tagged is moved from the new directory to
cur, the 'Mail' plugin (and its variants) won't work for such mail.
|
|
|
|
|
|
Introducing the throttling unfortunately has a negative side-effect: it
delays all stdin processing, including EOF detection, which can cause
confusion the previous commit tries to fix.
The only benefit of the throttling is to prevent 100% CPU usage when a
lot of garbage is provided on xmobar stdin. We still don't know where
that garbage comes from in https://github.com/jaor/xmobar/issues/438, or
rather why there's more than a handful of lines of such garbage. @psibi
has since fixed his setup to not produce that garbage, and no one else
ever reported such a problem, so it's probably safe to ignore it for
now.
Should anyone ever encounter that again, feel free to ping me, even in
the middle of the night, to help debug this.
Fixes: 7759df11f746 ("StdinReader: Improve exception handling")
Fixes: b7a3d6745817 ("Avoid busy looping by not catching all exceptions")
|
|
This corrects a misleading comment "EOF check is necessary for certain
systems" which was added without complete understanding of the root
cause of #442. That issue was in fact caused by old xmobars not being
terminated on early EOF, and is thus necessary on _all_ systems that
rely on EOF to terminate old xmobar before starting a new one. (To
trigger the bug, one additionally needs to close the xmobar pipe before
sending any input to it, which is unusual, but incorrectly configured
xmonad might trigger that.)
Furthermore, this fixes another execution path that could lead to xmobar
not being terminated on EOF:
`echo -e '\xff' | xmobar -c '[Run StdinReader]' -t '%StdinReader%'`
would terminate the StdinReader thread upon catching the "invalid
argument (invalid byte sequence)" so there'd be no thread to detect the
subsequent EOF and xmobar would get stuck.
Additionally, I believe that terminating either the thread or the entire
xmobar upon receiving a single miscoded byte isn't desirable, as this
might be an intermittent issue and another input line can be perfectly
okay. Therefore I suggest that the original issue @psibi was trying to
fix by b7a3d6745817 is worked around by introducing a throttling delay
instead of terminating the thread, as I assume that exceptions other
than async and EOF are recoverable.
Fixes: b7a3d6745817 ("Avoid busy looping by not catching all exceptions")
Fixes: 68ac4d3ae6f3 ("Update stderr and the bar on receiving exception")
Fixes: ed0663aac942 ("Add EOF check before getLine operation from stdin")
Fixes: https://github.com/jaor/xmobar/issues/442
Related: https://github.com/jaor/xmobar/pull/439
Related: https://github.com/jaor/xmobar/pull/448
|
