- xmonad - Haskell.org

darcs patch: bump LOC limit to 550 (and 1 more)
by Jason Creighton 10 May '07

10 May '07

Wed May 9 21:27:31 MDT 2007 Jason Creighton <jcreigh(a)gmail.com> * bump LOC limit to 550 Wed May 9 21:36:20 MDT 2007 Jason Creighton <jcreigh(a)gmail.com> * Swap workspaces instead of switching screens Previously, xmonad if workspace 1 and 2 were visible on screens 1 and 2, and workspace 1 was the current workspace, mod-2 would simply simple switch focus to screen 2. The new behavior is to always show the workspace you're switching to on the current screen. If the new workspace was visible on another screen, the formerly-current workspace will appear on that screen. In the example above, workspace 2 would appear on screen 1 and workspace 1 would appear on screen 2.

2 3

Statusbar ideas
by Robert Manea 10 May '07

10 May '07

Hi, i just played a bit with xmonad and added 2 new actions to dzen2 to be better suitable as a statusbar. * Example 1: Custom statusbar Add the following to your .xinitrc just before xmonad is being called: dwm-status.sh | dzen2 -p -e 'sigusr1=raise;sigusr2=lower;onquit=exec:rm /tmp/dzen2-pid;button3=exit' & echo $! > /tmp/dzen2-pid Add 2 keybindings to Config.hs: , ((modMask, xK_s ), spawn "kill -10 `cat /tmp/dzen2-pid`") , ((modMask, xK_t ), spawn "kill -12 `cat /tmp/dzen2-pid`") dwm-status.sh can be found here (zsh script!): http://gotmor.googlepages.com/dwm-status.sh mod-s raises the statusbar to view mod-t lowers it (hides it behind the other windows) * Example 2: xmonad debugging output .xinitrc: xmonad 2>&1 | dzen2 -p -e 'sigusr1=raise;sigusr2=lower;onquit=exec:rm /tmp/dzen2-pid;button3=exit' & echo $! > /tmp/dzen2-pid while :; do sleep 3600; done Add the same key bindings as described above. You could use then '-l <n>' feature to keep a log of the debugging output and scroll through it, too. This is a really hackish approach but good enough for debugging purposes as i think :). IMPORTANT: For all this to work you'll need the latest svn version of dzen2! Get it with: svn checkout http://dzen.googlecode.com/svn/trunk/ dzen Have fun, Rob

1 0

darcs patch: make rotView only consider non-visible workspaces (Xin...
by Jason Creighton 10 May '07

10 May '07

Wed May 9 19:20:59 MDT 2007 Jason Creighton <jcreigh(a)gmail.com> * make rotView only consider non-visible workspaces (Xinerama)

2 1

Issue 6 in project xmonad
by codesite-noreply＠google.com 09 May '07

09 May '07

Issue 6: Xmonad does not respect size hints http://code.google.com/p/xmonad/issues/detail?id=6 Comment #1 by quilotta: I made a quick & dirty patch for size hints: http://www.haskell.org/pipermail/xmonad/2007-May/000132.html Though you'll find that xpdf and imagemagick don't set useful size hints. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings

1 0

Issue 6 in project xmonad
by codesite-noreply＠google.com 09 May '07

09 May '07

Issue 6: Xmonad does not respect size hints http://code.google.com/p/xmonad/issues/detail?id=6 New issue report by stefa...(a)cox.net: Darcs xmonad does not respect size hints and will try to make everything fill the size allotment; this is annoying and ugly with xterm / emacs, and greatly reduces usability for imagemagick 'display' and xpdf's find. Issue attributes: Status: New Owner: ---- Labels: Type-Defect Priority-Medium -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings

1 0

0.1: Missing border around some windows
by Kai Grossjohann 09 May '07

09 May '07

There is a red border around xterm windows when they have focus. This border is lacking for Emacs, Gaim, and Firefox windows. (And possibly others.) Running xmonad-0.1. Kai

2 2

Compile error
by Kai Grossjohann 09 May '07

09 May '07

I just ran "darcs pull", then configure, and then build. I get this compiler error: ketchup% runhaskell Setup.lhs build Preprocessing executables for xmonad-0.1... Building xmonad-0.1... [1 of 6] Compiling StackSet ( StackSet.hs, dist/build/xmonad/xmonad-tmp/StackSet.o ) StackSet.hs:221:0: Warning: Defined but not used: `isFloat' [3 of 6] Compiling Config[boot] ( Config.hs-boot, nothing ) [4 of 6] Compiling Operations ( Operations.hs, dist/build/xmonad/xmonad-tmp/Operatio ns.o ) [5 of 6] Compiling Config ( Config.hs, dist/build/xmonad/xmonad-tmp/Config.o ) [6 of 6] Compiling Main ( Main.hs, dist/build/xmonad/xmonad-tmp/Main.o ) Main.hs:157:32: Couldn't match expected type `Display' against inferred type `Event' In the first argument of `refreshKeyboardMapping', namely `e' In the second argument of `($)', namely `refreshKeyboardMapping e' In the expression: io $ (refreshKeyboardMapping e) tia, Kai

4 4

Proofs of StackSet
by Neil Mitchell 08 May '07

08 May '07

Hi, {- ICFP referees look away now -} Dons asked me to check some of the StackSet code for potential pattern match errors, and indeed, there are some. I used Catch (http://www-users.cs.york.ac.uk/~ndm/catch/) to do all the testing. The first thing I had to do was apply a 2 line patch to get that module building with Yhc/nhc, to do with defaulting. Next I ran the program and found: 1) view related: * view calls error, this clearly makes it possible to crash. * raiseFocus calls view 2) head related: * promote calls head, in a potentially unsafe manner 3) tail related: * swap calls tail, again potentially unsafe. This one is easy to fix, simply use drop 1. This also means that promote could crash due to swap. 4) fromJust related: index calls fromJust, which means that it may crash. This means that all functions calling index are potentially unsafe, including: delete, insert, promote, push, shift, view, raiseFocus I took a look at delete, and it looks like the safety depends on the stacks and the cache all agreeing - plus possibly some other invariants. You could probably rewrite some of this code to be more rebust, and gain a proof of safety. 5) everything else: Everything else is safe, apart from (potentially) the Ord instances passed around - I abstracted them away for the testing of Data.Map. Realistically, I think you are fine on this point. This means you have a proof of pattern match safety for: screen, peekStack, empty, peek, member, rotate, workspace, visibleWorkspaces No changes were required for testing (other than the 2 line one for Yhc) - the test sits in a separate module and is very simple: main = screen ||| peekStack ||| index ||| empty ||| peek ||| push ||| delete ||| member ||| raiseFocus ||| rotate ||| promote ||| shift ||| view ||| workspace ||| insert ||| visibleWorkspaces ||| swap I hope some of that is useful to you. The testing is 100% automatic and pretty easy to run, once you have Yhc and Catch installed and configured. You have two choices related to pattern match failure: 1) Ignore it, guard against with QuickCheck 2) Prove it, using Catch You also have three options regarding Catch use: 1) Integrate the 2 line change, add the Catch module testing framework in so anyone with Catch installed can replicate these tests - and check you don't get worse. 2) Have a catch branch, which has the library driver and the patch. This would be a really small branch :-) 3) Don't do anything, I can continue to check things occasionally. I'm on #haskell as ndm, so let me know if you want any help running any of this. Thanks Neil

2 1

Haskell 98 compliance
by Neil Mitchell 08 May '07

08 May '07

Hi, This patch makes the StackSet file Haskell 98 once more, by using list comprehensions instead of pattern guards. This patch has not been tested, so please do the test script first. Use of Haskell 98 makes your lambdas sleep better at night, knowing they are more portable. Thanks Neil

1 0

darcs patch: keep focus stack.
by David Roundy 08 May '07

08 May '07

Hi all, Here's a cut at a focus stack. It's a bit crude, but seems to work. I had to tweak the rotate properties, since rotating the focus (obviously) changes the focus stack. I don't think this weakening of those checks is really a Bad Thing. And I'm a little puzzled how prop_delete_push ever passed. Maybe it failed, and noone noticed? Or maybe we aren't running enough tests with large enough stack sizes, so we never ran into the case where the focus wasn't on the master window to start with? I don't know, but it suggests something is wrong. David P.S. Sorry for my crude code. If we like this behavior, we can clean it up. Sat May 5 10:57:09 PDT 2007 David Roundy <droundy(a)darcs.net> * keep focus stack.

2 2