Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
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.
|
|
|
|
I added `QueueReader` as a section under `Software Transational
Memory`, but it is all alone. Some other plugins actually use STM,
and maybe they should actually go in that section too.
I didn't make a safe versions since the plugin is not readable. It
still would be nice to have, but I think exposing `stripActions` is
the appropriate solution. That should be handled in a new PR I guess.
|
|
* 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
|
|
|
|
|
|
|
|
|
|
|
|
Ever since d51b9d5dd6537e5369e13a9a11ae98aeadce50dd we can't specify a
MailItem via the record syntax anymore. This could conceivably be added
back in by being part of the Read instance, but that would make it more
complicated for perhaps little gain.
Related: https://github.com/jaor/xmobar/issues/547
|
|
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.)
|