Hi,
I'm going to release Xmobar-0.8 shortly and so, with the hope to have
some more testers, I'm making this release candidate:
http://code.haskell.org/~arossato/xmobar/xmobar-0.8-rc1.tar.gz
NOTE: xmobar-0.8-rc1 requires X11-1.3.0 from hackage.
There are a lot of changes since the last release. The main include:
a. Configuration:
- removed xPos, yPos, width, height, align, and refresh
configuration options;
- added position and alignSep configuration options: the first is
used to set the position (Top, Bottom or Static; the second to
set the characters to be used to separate, in the output
template, text that must be aligned to the left, centered, or
aligned to the right;
(please have look at xmobar.config-sample)
b. Plugins:
- added a plugin to read Unix named pipe (useful to display XMonad
logs);
- added a plugin to read from standard input;
- a new plugin API makes it possible to write plugins that perform
asynchronous actions. The new API is totally backward compatible;
c. Output template:
- it is now possible to align text in the output template. By
default text before a '}' will be align to left, the text in
between '}' and '{' will be centered, and the text after a '{'
will be align to the right, like:
"left } centered { right"
- strings can have also a background color set:
"
Hi, thanks! The PipeReader-Plugin is perfect, before I used an ugly combination of dzen and xmobar. Xrandr-support for resolution changes works without a glitch, however I cannot test rotations since my hardware does not support it. One suggestion: it may be useful to be able to combine position=Bottom or Top with a width smaller than the screen width: One way to do it would be to use X geometry-like syntax for the position, that is ypos=-1 means Bottom, xpos=-1, Right and so on. I think this would be a more elegant solution... Anyway, thanks for this great app :) Hans Philipp
On Sat, Nov 03, 2007 at 05:16:52PM +0100, Hans Philipp Annen wrote:
Xrandr-support for resolution changes works without a glitch, however I cannot test rotations since my hardware does not support it.
great. When the screen gets bigger does xmobar resize correctly too?
One suggestion: it may be useful to be able to combine position=Bottom or Top with a width smaller than the screen width: One way to do it would be to use X geometry-like syntax for the position, that is ypos=-1 means Bottom, xpos=-1, Right and so on. I think this would be a more elegant solution...
And what about this? data XPosition = Top Width | Bottom Width | Static {xpos, ypos, width, height :: Int} deriving ( Read, Eq ) data Width = All | Left Int | Right Int | Center Int deriving ( Read, Eq ) so we would have: position = Top All for top with maximum width, or position = Top Left 70 for top, left aligned, 70% of the screen width, or Bottom Center 50 and so on?
Anyway, thanks for this great app :)
Thank you for your kind words. Andrea
On 11/3/07, Andrea Rossato
On Sat, Nov 03, 2007 at 05:16:52PM +0100, Hans Philipp Annen wrote:
Xrandr-support for resolution changes works without a glitch, however I cannot test rotations since my hardware does not support it.
great. When the screen gets bigger does xmobar resize correctly too?
Andrea, could you publish some screenshots? Thanks. -- vvv
On Sat, Nov 03, 2007 at 08:31:13PM +0200, Valery V. Vorotyntsev wrote:
could you publish some screenshots?
there you go: http://haskell.org/sitewiki/images/a/ae/Arossato-config.png http://code.haskell.org/~arossato/xmobar/xmobar-0.8.png http://gorgias.mine.nu/tmp/myDesktop.png Cheers, Andrea
On 11/3/07, Andrea Rossato
there you go:
http://haskell.org/sitewiki/images/a/ae/Arossato-config.png
Thanks!
On Sat, Nov 03, 2007 at 05:52:16PM +0100, Andrea Rossato wrote:
On Sat, Nov 03, 2007 at 05:16:52PM +0100, Hans Philipp Annen wrote:
Xrandr-support for resolution changes works without a glitch, however I cannot test rotations since my hardware does not support it.
great. When the screen gets bigger does xmobar resize correctly too?
Confirmed. Starting xmobar in a low resolution screen and increasing the resolution works fine.
And what about this?
data XPosition = Top Width | Bottom Width | Static {xpos, ypos, width, height :: Int} deriving ( Read, Eq )
data Width = All | Left Int | Right Int | Center Int deriving ( Read, Eq )
so we would have:
position = Top All for top with maximum width, or
position = Top Left 70 for top, left aligned, 70% of the screen width, or
Yes, that's nice. However, now that I think of it, my suggestion shows signs of featuritis, since I cannot think of any real use for a 70% screen-width statusbar. It's probably best the way it is ;) Hans Philipp
On Sun, Nov 04, 2007 at 07:37:43AM +0100, Hans Philipp Annen wrote:
Yes, that's nice. However, now that I think of it, my suggestion shows signs of featuritis, since I cannot think of any real use for a 70% screen-width statusbar. It's probably best the way it is ;)
I don't know, but perhaps when you use more than one... the fact is that I'd already implemented it when I read this message, and so 0.8-rc2 is out: http://code.haskell.org/~arossato/xmobar/xmobar-0.8-rc2.tar.gz Consider it a test: position can be: position = Top A position = Top (C Int) position = Top (L Int) position = Top (R Int) position = Bottom A position = Bottom (C Int) position = Bottom (L Int) position = Bottom (R Int) position = Static {xpos = Int , ypos = Int, width = Int, height = Int } where A = all, C = center, L = left and R = right. I don't know. Let me know what you think. Andrea
On Sun, Nov 04, 2007 at 02:29:39PM +0100, Andrea Rossato wrote:
Consider it a test:
position can be:
position = Top A
In the darcs repository I changed this to Top (for backward compatibility).
position = Bottom A
and this to Bottom for the same reason.
I don't know. Let me know what you think.
Andrea
Just to clarify: the new position configuration option, which is backward compatible, can be now set to: Top Bottom TopW L/C/R Int (es: TopW C 75 or TopW R 50) BottomW L/C/R Int Static {xpos = Int, ypos = Int, width = Int, height = Int} This is what's needed to have this feature: M ./Config.hs -2 +4 M ./Xmobar.hs -11 +28 Not too much after all. Moreover this should not break recent configuration files. Does it make sense? Do you have any suggestion for changing the names of TopW and BottoW? here's the latest code: http://code.haskell.org/~arossato/xmobar/xmobar-0.8-rc3.tar.gz this is a precompiled binary: http://code.haskell.org/~arossato/xmobar/xmobar-0.8.bin Thanks for your kind attention. Andrea
On Sat, 3 Nov 2007 14:43:13 +0100, Andrea wrote:
I'm going to release Xmobar-0.8 shortly and so, with the hope to have some more testers, I'm making this release candidate:
http://code.haskell.org/~arossato/xmobar/xmobar-0.8-rc1.tar.gz
NOTE: xmobar-0.8-rc1 requires X11-1.3.0 from hackage.
...
I would really appreciate if you could report back any issue you may discover.
Unfortunately xmobar.0.8 does not compile on my machine (linux, amd64, ghc 6.6.1): [18 of 19] Compiling Xmobar ( .//Xmobar.hs, dist/build/xmobar/xmobar-tmp/Xmobar.o ) .//Xmobar.hs:155:46: Couldn't match expected type `GHC.Word.Word32' against inferred type `Atom' In the expression: v In the sixth argument of `changeProperty32', namely `[v]' In the expression: changeProperty32 d w a2 c2 propModeReplace [v] -- Markus
participants (4)
-
Andrea Rossato -
Hans Philipp Annen -
Markus Trippelsdorf -
Valery V. Vorotyntsev