May 2007 - xmonad - Haskell.org

reserved keyboard shortcuts
by brad clawsie 06 Jun '07

06 Jun '07

after an update from darcs, i see alt-LeftArrow and alt-RightArrow are no longer used as shortcuts, which is nice because they are used in firefox. alt-b is still in the default, which is used to access the firefox bookmarks menu. i personally maintain a private Config.hs to deal with this, not sure if it is something worth addressing

5 5

darcs patch: first shot at a floating layer
by Jason Creighton 02 Jun '07

02 Jun '07

Wed May 30 22:47:33 MDT 2007 Jason Creighton <jcreigh(a)gmail.com> * first shot at a floating layer This is a first attempting at a floating layer: mod-button1: move window mod-button2: swapMaster mod-button3: resize window mod-t: make floating window tiled again Moving or resizing a window automatically makes it floating. Known issues: Hard to manage stacking order. You can promote a window to move it to the top, (which you can do with mod-button2) but it should be easier than that. Moving a window by dragging it to a different Xinerama screen does not move it to that workspace. Code is ugly.

6 22

A plan for the floating layer
by dons＠cse.unsw.edu.au 01 Jun '07

01 Jun '07

The current floating layer code handles the interface to the outside world quite nicely, but interacts strangely with fullscreen mode. The problems stem from the fact that windows are lifted into the floating layer by setting a bit flag, basically. They are then rendered separately if this flag is set. This is good, but means that floating windows keep an implicit position in the tiled ordering -- although they don't physically appear to be in the tiled layer. This leads to some oddities: * moving a floating window in fullscreen tiled mode, will shift focus of the tiled layer to the window after the implicit position of the floating mode. * mod-shift-j reorders the implicit position of a floating window in the tiled layer, but this change isn't visible I think the best way to solve this is to move from an 'implicit' floating layer, denoted by flag bits, to an explicit floating layer on each workspace: data Workspace i a = Workspace { tag :: !i , tiled :: Stack a , float :: Stack a } Now we can be sure that the floating layer is fully detached, and can be operated on in isolation, as its own zipper. For one, this will mean fullscreen mode works (since focus isn't lost on the tiled stack). Should be able to reuse the existing code (changing modify a bit). We also get a new set of operatoins on the float layer alone, or on the union of the two layers. Spencer, Jason, suggestions? Everyone else, not tracking the stable branch -- what do you think of the tiling mode as it is? this will likely be the main new (and final!) feature missing before 0.3 (and forward to 1.0). -- Don

3 3

why no refresh on focus events?
by David Glasser 31 May '07

31 May '07

I'm working on an "accordion" layout in which the layout depends on which window is focused. (Basically: the focused window takes up most of the screen; the windows before it in the list are strips on the top, and the windows after it are strips on the bottom.) It mostly works, but only when you use focus changes that go through the "windows" function; when a window is focused by mouse-over, nothing happens. This is because of the patch quoted below, which doesn't refresh when you call "focus". I'm wondering what the problem caused by that refresh was, and if there's another way to fix it? (Also, the current doLayout signature is pretty restrictive. It would be nice if it was told the workspace ID of the workspace it is laying out; that way it can get the windowset from the X state and, say, find out what the top window of the workspace being laid out is; W.peek just gives you the focused window of the entire StackSet.) --dave Mon May 28 09:31:27 EDT 2007 Don Stewart <dons(a)cse.unsw.edu.au> * don't refresh on focus events leads to a race. this will affect how gaps are redrawn when moving to a new screen with the mouse. diff -rN -u old-xmonad/Operations.hs new-xmonad/Operations.hs --- old-xmonad/Operations.hs 2007-05-31 18:22:36.000000000 -0400 +++ new-xmonad/Operations.hs 2007-05-31 18:22:36.000000000 -0400 @@ -220,7 +220,7 @@ -- the mouse to a new screen). focus :: Window -> X () focus w = withWorkspace $ \s -> do - if W.member w s then modify (\st -> st { windowset = W.focusWindow w s }) >> refresh + if W.member w s then modify (\st -> st { windowset = W.focusWindow w s }) -- >> refresh else whenX (isRoot w) $ setFocusX w -- we could refresh here, moving gap too. -- XXX a focus change could be caused by switching workspaces in xinerama. -- if so, and the gap is in use, the gap should probably follow the -- David Glasser | glasser(a)mit.edu | http://www.davidglasser.net/

2 1

dynamic configuration? (e.g. hsplugins)
by David Roundy 31 May '07

31 May '07

I know others here have far more experience in this arena than I do, but are there any plans to support hsplugins or the ghc api, or just plain running under ghci, so that a recompile-reinstall cycle won't be necesary to update one's configuration? I'd assume this'd be in the works for version 0.7 or so, but thought I might as well ask. -- David Roundy Department of Physics Oregon State University

3 5

layout combinators
by Joe Thornber 31 May '07

31 May '07

I'm not going to get time to look at this again until the weekend, so I thought I'd post what I had for people to muse over. Combining splitters rather than rectangles is a neat idea (I hope). However I think we do need a combinator that merges rectangles back together again. Consider a layout consisting of three columns, where the middle column is twice the width of the out ones. To do this I'd like to create four columns and then merge together the two middle columns: eg, merge [1..2] . hcat . replicate 4 $ unit I really don't like passing indexes to merge, so if anyone can come up with a nicer way I'd be very interested. For now, this approach ignores the whole issue of scaling factors given by the user to get the window sizes exactly as they want. But I do wonder if that can be done as a seperate distortion pass over the resultant rects anyway. - Joe -- -- Layout combinators -- type Splitter = Rect -> [Rect] unit :: Splitter unit = (: []) catDir :: Direction -> [Splitter] -> Splitter catDir dir splitters = concat . zipWith ($) splitters . divideMany (length splitters) dir hcat, vcat :: [Splitter] -> Splitter hcat splitters = catDir East splitters vcat splitters = catDir South splitters hjoin, vjoin :: Splitter -> Splitter -> Splitter vjoin left right = vcat [left, right] hjoin left right = hcat [left, right] mkLayout :: (Int -> Splitter) -> Layout mkLayout s = Layout { doLayout = l, modifyLayout = const Nothing} where l sc ws = return . zip ws . map fromRect . s (length ws) . toRect $ sc -- -- Layouts -- ejtTall :: Layout ejtTall = mkLayout tall' where tall' 1 = unit tall' n = unit `hjoin` (vcat . replicate (n - 1) $ unit) ejtWide :: Layout ejtWide = mkLayout wide' where wide' 1 = unit wide' n = unit `vjoin` (hcat . replicate (n - 1) $ unit) ejtColumn :: Layout ejtColumn = mkLayout $ \_ -> hcat . replicate 4 $ (unit 'vjoin' unit)

2 1

a patch for 6.4 users
by Daniel Wagner 31 May '07

31 May '07

Hello, I copied GHC 6.6's instance of Read, and thought I'd save other 6.4 users from having to dig around for it. ~d New patches: [add a Read instance for Map daniel(a)wagner-home.com**20070531210704 This adds an instance of Read for Maps. If you have GHC 6.4, see the README for how to enable it; otherwise, this shouldn't affect you. ] { hunk ./README 56 + +Note: If you are using GHC 6.4, you will need to add a line to StackSet.hs. At + the end of the list of imports, add + + import ReadMap () + + to provide GHC with an instance of Read for Data.Map. addfile ./ReadMap.hs hunk ./ReadMap.hs 1 +module ReadMap where + +-- stolen from GHC 6.6 sources + +import Data.Map +import Text.Read +import GHC.Read + +instance (Ord k, Read k, Read e) => Read (Map k e) where + readPrec = parens $ prec 10 $ do + Ident "fromList" <- lexP + xs <- readPrec + return (fromList xs) + + readListPrec = readListPrecDefault } Context: [Revert accidental change to border color Spencer Janssen <sjanssen(a)cse.unl.edu>**20070531145509] [comments on why fullscreen tiling doesn't work with `implicit' floating Don Stewart <dons(a)cse.unsw.edu.au>**20070531090537] [clean up mouse code a bit Don Stewart <dons(a)cse.unsw.edu.au>**20070531085308] [first shot at a floating layer Jason Creighton <jcreigh(a)gmail.com>**20070531044733 This is a first attempting at a floating layer: mod-button1: move window mod-button2: swapMaster mod-button3: resize window mod-t: make floating window tiled again Moving or resizing a window automatically makes it floating. Known issues: Hard to manage stacking order. You can promote a window to move it to the top, (which you can do with mod-button2) but it should be easier than that. Moving a window by dragging it to a different Xinerama screen does not move it to that workspace. Code is ugly. ] [remove LOC cap (but still print count after tests) Jason Creighton <jcreigh(a)gmail.com>**20070531043417] [TAG 0.2 Spencer Janssen <sjanssen(a)cse.unl.edu>**20070531010004] Patch bundle hash: a81ee5c5006c3eaf508e8b9ea2610874ece3ee19

1 0

Issue 16 in project xmonad
by codesite-noreply＠google.com 31 May '07

31 May '07

Issue 16: xmonad does not mark non-visible windows as iconafied http://code.google.com/p/xmonad/issues/detail?id=16 Comment #1 by dons00: The issue here is that an external client is calling X behind our back. If we properly denote hidden windows as hidden to X (via the iconified property?) then clients will have a better chance to know what is visible on the screen. There'd still be issues with fullscreen mode, but setting iconfified (if that's the right thing to do) on 'Operations.hide' seems easy enough. Issue attribute updates: Status: Accepted -- 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 15 in project xmonad
by codesite-noreply＠google.com 31 May '07

31 May '07

Issue 15: Enter one-line summary http://code.google.com/p/xmonad/issues/detail?id=15 Comment #1 by dons00: (No comment was entered for this change.) Issue attribute updates: Status: Invalid -- 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 16 in project xmonad
by codesite-noreply＠google.com 31 May '07

31 May '07

Issue 16: xmonad does not mark non-visible windows as iconafied http://code.google.com/p/xmonad/issues/detail?id=16 New issue report by tim.thelion: What steps will reproduce the problem? 1. install emacs 2. start emacs 3. paste: (x-focus-frame (window-frame (get-buffer-window "*Messages*" 'visible))) in the buffer that appears after you see the spash screen(you get it to go away by pressing any key) 4. Press C-x 5 2 (C=Control) 5. Move the newly created window to another workspace 6. press C-x C-b and then type *Messages* and press enter 7. go back to the first workspace 8. Go to the end of the line you pasted. 9. Press C-x C-e you will find that though the elisp only looks for windows that are not iconified. It still finds the window which is on another workspace What is the expected output? What do you see instead? Well I expected that this window manager would follow convention and mark windows that are not visible as iconified. What version of the product are you using? On what operating system? 0.2 on GNU-debian/Linux Please provide any additional information below. 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