| Age | Commit message (Collapse) | Author | |
|---|---|---|---|
| 2024-03-30 | fix for unmet pattern matches warnings (clean build) | jao | |
| 2023-03-22 | Handle SocketError when attempting to connect to dbus | Corey Halpin | |
| Extends the solution from 8a53271cd6 to also handle SocketError, so that the process will not terminate. See also issue #537. | |||
| 2022-09-26 | more little import clean ups | jao | |
| 2022-05-12 | Remove the now useless -DUTF8 flag | jao | |
| 2022-04-18 | New dbus signal: SetAlpha (fixes #499) | jao | |
| 2022-02-06 | Little refactoring: forkThread | jao | |
| 2021-11-07 | Let xmobar be used with a signal TMVar when used from other haskell. | John Soo | |
| 2021-08-12 | Add getGrpNames to get layout group names | Nikolay Yakimov | |
| 2021-08-12 | Fix xkbFreeNames call in getLayoutStr | Nikolay Yakimov | |
| 2021-08-12 | Fix XkbNamesRec type and Storable instance | Nikolay Yakimov | |
| 2020-11-19 | StdinReader: Improve exception handling | Tomas 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-08-07 | Redundant imports (mostly <$>) removed | jao | |
| 2020-05-11 | more hlinting | jao | |
| 2020-05-11 | hlinting | jao | |
| 2020-05-10 | Fix crashes/busy looping happening via index | Sibi Prabakaran | |
| 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> | |||
| 2020-05-02 | Update stderr and the bar on receiving exception | Sibi Prabakaran | |
| 2020-04-30 | Spurious import and hlinting | jao | |
| 2020-04-30 | Refactor the usage of hGetLineSafe | Sibi Prabakaran | |
| hGetLineSafe is always hGetLine and hence we can directly use it. | |||
| 2018-11-25 | Xmobar.System.Utils, Xmobar.X11.Events | jao | |
| 2018-11-25 | Back to app/src, since it seems they're the default convention for stack | jao | |
 |
index : xmobar | |
| a minimalistic status bar | jao |
| summaryrefslogtreecommitdiffhomepage |