summaryrefslogtreecommitdiffhomepage
AgeCommit message (Collapse)Author
2021-06-18Add Gentoo to installation method.187Qrly
2021-06-18Fix MultiCoreTemp --hwmon-path argument docsSebastian Nagel
2021-05-24changelog updatesjao
2021-05-24Merge branch 'notmuchmail-fix' [#548]jao
2021-05-24NotmuchMail: Update documentationslotThe
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
2021-05-24NotmuchMail: Manually implement Read instanceslotThe
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
2021-05-24Add NotmuchMail as a runnable typeslotThe
This is needed for the plugin to parse properly in non-Haskell based configurations. Related: https://github.com/jaor/xmobar/issues/547
2021-05-22Add show instances for several types so that configs can be generated ↵Ryan Trinkle
programmatically
2021-05-21changelog and authorsjao
2021-05-21Add documentationSam Kirby
2021-05-19Remove unused import; apply lint hintSam Kirby
2021-05-19Add k10temp pluginSam Kirby
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`
2021-05-19Version 0.380.38jao
2021-05-14Fix delayed reaction to USR1/2 signalsTomas Janousek
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.)
2021-05-06Fix a linkJulin S
Fix a link to an example.
2021-04-27Revert "Conditional encoding …" and "Avoid double utf8 encoding" (#482)Tomas Janousek
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
2021-04-27Changelog update (#538, #530)Tomas Janousek
2021-04-26Workaround for hlint failureTomas Janousek
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.
2021-04-26Fix off-by-one in strut calculation for Static positionTomas Janousek
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
2021-03-30Add FreeBSD support to Cpu pluginKevin Zheng
2021-03-18Fix typo `DRTSOPTS` -> `RTSOPTS`Claudio Bley
The cpp option `-DRTSOPTS` results in `RTSOPTS` being defined.
2021-02-25Examples link correction (fixes #527)jao
2021-01-28Add plugins.org to readmeslotThe
2021-01-18Expose Xmobar.Plugins.Monitors.Common (fixes #520)jao
Exposing Common.Types and Common.Run is now redundant, but we could break configurations out there, so i'm not sure if we should remove them.
2021-01-15Extract compiling xmobar from source to its own fileslotThe
2021-01-15Add installation instructions for OpenSUSEslotThe
2021-01-15Extract writing your own plugin into its own fileslotThe
2020-12-20Including new .org doc files in extra-source-filesjao
2020-12-15Subdivide system monitorsslotThe
2020-12-15Subdivide window manager integrationslotThe
2020-12-15Prefer UnsafeXmonadLog over UnsafeStdinReaderslotThe
2020-12-14Further improvementsslotThe
2020-12-14Split out contributing and quick-start part from readmeslotThe
The contributing.org file also contains information on how to write a new monitor for xmobar. The quick-start guide got reworked a bit to inline similar parts.
2020-12-14Add installation instructions via package managerslotThe
2020-12-14Move plugins to doc/plugins.orgslotThe
This also moves Date and DateZone to the monitors section (as they are monitors themselves). A little bit of documentation was also added/updated.
2020-12-14Update readme.orgslotThe
Mostly updating links and old (i.e. outdated) information
2020-12-14Convert readme to org-modeslotThe
2020-11-29Tweaks to website makefilejao
2020-11-290.370.37jao
2020-11-29Update readme and changelogslotThe
2020-11-29Add new plugin: NotmuchMailslotThe
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.
2020-11-25More consistent argument order for MPDXjao
2020-11-25Use tripple backticks for Haskell codeslotThe
Also make indentation of shell code a little bit more regular.
2020-11-24New monitor: MPDXjao
2020-11-19test: Fix flaky CpuSpecTomas Janousek
Failed at least once in GitHub Actions: predicate failed on: "Cpu: <fc=red>100</fc>% <fc=red>##########</fc>" Also, there's no need to guard the Xmobar.Plugins.Monitors.CpuSpec module with the with_alsa flag. (And it doesn't really work anyway, hspec-discover doesn't care about what modules are declared in cabal, so stack/ghc complains that "These modules are needed for compilation but not listed in your .cabal file's other-modules: Xmobar.Plugins.Monitors.AlsaSpec" and then fails to detect changes in those modules.)
2020-11-19StdinReader: Remove throttling on exceptionTomas Janousek
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")
2020-11-19StdinReader: Improve exception handlingTomas Janousek
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
2020-11-18changelog linkjao
2020-11-18Nitsjao
2020-11-18clean-ups for web page generationjao