May 2007 - xmonad - Haskell.org

Issue 9 in project xmonad
by codesite-noreply＠google.com 27 May '07

27 May '07

Issue 9: 'amarok' (KDE music program) causes reproducible failures from xmonad. http://code.google.com/p/xmonad/issues/detail?id=9 Comment #1 by dons00: stepcut> hrm, I run amarok almost every day and have never had a crash. -- 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 9 in project xmonad
by codesite-noreply＠google.com 27 May '07

27 May '07

Issue 9: 'amarok' (KDE music program) causes reproducible failures from xmonad. http://code.google.com/p/xmonad/issues/detail?id=9 New issue report by dons00: What steps will reproduce the problem? 1. Just start an xterm and run amarok What is the expected output? What do you see instead? Should lead to xmonad exiting, and X reporting a fatal IO error 32 (Gebroken pijp) or KillClient on X server ":4.0" Todo: investigate this, find out if it is reproducible, work out if the client is behaving itself, or being unreasonable. Issue attributes: Status: New Owner: dons00 Labels: Type-Defect Priority-Medium Usability -- 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

Small key binding change
by dons＠cse.unsw.edu.au 26 May '07

26 May '07

I just pushed a patch that changes the bindings for incMaster/swapLeft/swapRight. swapLeft/Right are movement operators, that did clash with firefox's back key. So they're now bound to: mod-shift-j and k That means incMaster ops are now mod-comma and mod-period (the < and > keys) Hope that's a bit more intuitive (particular 'swap', and avoids a clash). -- Don

1 0

[Patch: XMonadContrib] Spiral tidying
by Joe Thornber 26 May '07

26 May '07

Various patches for the Spiral tile layout. Now use a fibonacci spiral rather than one based on the golden ratio - since this always seems to look better. The entry in the layouts list in Config.hs should now read: spiral (1 % 1) * [Spiral] add fibonacci spiral * [Spiral] remove old spiral code * [Spiral] misc tidying * [Spiral] divideRects now takes a list of directions to split in * [Spiral] Introduce a simpler Rect data type to remove a lot of the fromIntegrals * [Spiral] last rect takes all available space * [Spiral] blend in the scale factor so it doesn't have any effect on the smallest windows - Joe

3 2

resizeing xterms
by Tim Docker 26 May '07

26 May '07

This is not an xmonad question per-se, but... In using xmonad my xterms get shrunken and expanded much more often than with a regular window manager. When this happens how do I prevent them from losing the text that was hidden by the shrinking? Is there some sort of config option - or should I be using an alternative terminal? Tim

6 9

Catch patches
by Neil Mitchell 26 May '07

26 May '07

Hi Two patches. The first one deletes tests/Catch.hs. Using the darcs version of Catch, you can simply do: $ catch StackSet.hs And that fires off the test, without requiring driver scripts etc. The second one introduces abort, and uses it instead of error. This lets Catch know that an error is intentional, and won't be flagged. With these, I can't prove pattern match safety for two reasons: * new gives an error on compiling with Yhc: -- during after type inference/checking Error: Context for Prelude.Enum and Prelude.Num needed in left hand pattern at 1 67:13. Error: Context for Prelude.Enum and Prelude.Num needed in left hand pattern at 1 66:9-166:21. catch: Failed to compile, StackSet.hs I guess its defaulting issues - Malcolm may be able to suggest an appropriate work around. * view uses pattern guards, these don't work with Yhc. By commenting out those two bits, Catch is able to prove safety of the rest. Thanks Neil

2 1

fixing warnings with stricter type?
by David Roundy 26 May '07

26 May '07

Maybe we should replace data Stack a = Empty | Node { focus :: !a -- focused thing in this set , left :: [a] -- clowns to the left , right :: [a] } -- jokers to the right deriving (Show, Read, Eq) with something like: type Stack a = Maybe (NonEmptyStack a) data NonEmptyStack a = Node { focus :: !a -- focused thing in this set , left :: [a] -- clowns to the left , right :: [a] } -- jokers to the right Then (modify Empty f) could just be (fmap f), and (modify d f) becomes (Just . maybe d . fmap f), which seems cleaner to me. This also allows nice use of pattern matching in the Maybe monad. I like Maybe. -- David Roundy Department of Physics Oregon State University

3 3

sticky windows?
by David Roundy 26 May '07

26 May '07

Hi all, Is there now any reason why we can't have sticky windows? I'd love to be able to show the same xclock on every workspace, instead of having to start N xclocks. Actually, I'd like something akin to dwm's tagging, I believe (although I've never used it). I want something like "copy this window to that workspace." Is there any reason this would be tricky? Or undesirable? I have no idea how it'd interact with Xinerama, since two visible workspaces could then both contain the same window. -- David Roundy http://www.darcs.net

4 5

Less code smell for xinerama code
by dons＠cse.unsw.edu.au 26 May '07

26 May '07

Some more changes to the Xinerama code just landed: we removed the separate table tracking Xinerama screens to virtual workspaces. Instead the core data structure now tracks directly the current, visible and hidden workspaces. Makes policy regarding how workspaces are moved around on xinerama screens a lot simpler. The trick is to use the 'one hole context' workspace list (a list with a hole punched in it to track focus). A list of workspaces: Workspaces = [w] The same list, but with a hole punched in it to track focus: Cursor = { left :: [w] , current :: w , right :: [w] } We use the partitioning of the this punched list to separate those workspaces that are visible on a xinerama, but not in focus, and those that are hidden entirely. Cursor = { visible :: [w] , current :: w , hidden :: [w] } That is, the workspaces to the 'left' of the currently focused workspace are now only the xinerama-visisble ones, and those to the 'right' are those that are completely hidden. The result, much less bookkeeping, and 4 dynamic checks are removed, as the data structure tracks them by design. Moving between current and visible workspaces becomes obvious to implement and test, and deciding when and how to raise a hidden workspace also becomes easy. Finally, we have a natural account for the concept of 'visible but not current' workspaces, as managed by Xinerama, directly in the StackSet data structure. The result being code that doesn't smell quite so much. -- Don

2 2

darcs patch: Introduce NonEmptyStack.
by David Roundy 26 May '07

26 May '07

Hi all, Here's a patch implementing a NonEmptyStack type that is our zipper without the Empty possibility. I like this change, but haven't cleaned up the comments as it's not clear that others will like it. I made modify accept a function that will only modify NonEmptyStacks, which covers all the possibilities but delete. Actually, I think I'll implement a clean:q Fri May 25 19:18:04 PDT 2007 David Roundy <droundy(a)darcs.net> * Introduce NonEmptyStack.

2 2