August 2008 - xmonad - Haskell.org

Issue 202 in xmonad: Magnifier NoMaster doesn't work for 2nd master window
by codesite-noreply＠google.com 18 Aug '08

18 Aug '08

Issue 202: Magnifier NoMaster doesn't work for 2nd master window http://code.google.com/p/xmonad/issues/detail?id=202 Comment #3 by m...(a)twifkak.com: Correction. I'm an idiot. s/all the misinformation about state and types/it would be nice to have runtime "reflection" on layouts/g. (I hope this comment is actually valid...) -- 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 202 in xmonad: Magnifier NoMaster doesn't work for 2nd master window
by codesite-noreply＠google.com 18 Aug '08

18 Aug '08

Issue 202: Magnifier NoMaster doesn't work for 2nd master window http://code.google.com/p/xmonad/issues/detail?id=202 Comment #2 by m...(a)twifkak.com: Um, slight correction. Tall's numMaster state *is* part of its type, which is why it's able to persist across restarts. Shutting up now... -- 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 202 in xmonad: Magnifier NoMaster doesn't work for 2nd master window
by codesite-noreply＠google.com 18 Aug '08

18 Aug '08

Issue 202: Magnifier NoMaster doesn't work for 2nd master window http://code.google.com/p/xmonad/issues/detail?id=202 Comment #1 by m...(a)twifkak.com: Unfortunately, there's not much can be done without a significant rewrite. IncMasterN is something layout-specific to Tall, and Magnifier, as a general LayoutModifier, knows nothing of its sub-layout's internals (or even its type, except perhaps through some Olegery of which I'm unaware), so it cheats and assumes first window. In general, though, it would be nice for the xmonad 'framework' to support layout state, queriable and persistent across restarts. -- 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 202 in xmonad: Magnifier NoMaster doesn't work for 2nd master window
by codesite-noreply＠google.com 18 Aug '08

18 Aug '08

Issue 202: Magnifier NoMaster doesn't work for 2nd master window http://code.google.com/p/xmonad/issues/detail?id=202 New issue report by djdon2005: What steps will reproduce the problem? 1. Create a magnified layout myLayout = magnifier'( Tall 2 (3/100) (2/3) ) 2. Open two windows in master 3. Switch focus between windows What is the expected output? What do you see instead? I would expect neither window to change size as they are both in the master pane. It seems that the 2nd of the two windows is resized, even though it is in the master pane. What version of the product are you using? On what operating system? I am using version 0.7 from darcs on ubuntu hardy heron. Please provide any additional information below. I suspect it may be todo with the following code although I can't work out how to determine the number of master windows. (Line 139-141 XMonadContrib/XMonad/Layout/Magnifier.hs ) unlessMaster :: NewLayout a -> NewLayout a unlessMaster mainmod r s wrs = if null (up s) then return (wrs, Nothing) else mainmod r s wrs If this error is due to a module from XMonadContrib, please tag this issue with 'Component-Contrib' below. Component-Contrib 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

Web page redesign ideas
by Don Stewart 17 Aug '08

17 Aug '08

Luis Araujo's himerge project has a nice structure, imo, http://www.haskell.org/himerge/index.html Perhaps something like that? -- Don

1 0

unified tile+tab layout?
by Klaus Weidner 16 Aug '08

16 Aug '08

I find myself switching between tiled and tabbed layouts frequently, and the Combo layout to combine two tabbed layouts is nice but a bit inflexible since it needs to be preconfigured in the config file. I've been thinking about a way to combine tabs and tiles more flexibly - would something like the following be feasible? I haven't looked into coding it myself so far, and I worry that my haskell-fu may be insufficient. Assume you start out with a tiled layout like the standard "Tall" one with a few windows, something like this: 00000 1111 00000 1111 00000 2222 00000 2222 00000 3333 00000 3333 If window 1 is active and you press Mod-Shift-J, the current behavior (swapDown) is to move window 1 down after window 2. The behavior I'd like is that moving window 1 down would combine windows 1 and 2 into a tabbed windowset, with window 1 being active: 00000 -1-2- 00000 1111 00000 1111 00000 3333 00000 3333 00000 3333 Then, if you press Mod-Shift-J again, the active window 1 gets removed from the tabbed set and moved below window 2: 00000 2222 00000 2222 00000 1111 00000 1111 00000 3333 00000 3333 This way, you should be able to create pretty much any tabbed+tiled combination by just using Mod-Shift-J/K to collapse selected windows into tabs, including recreating the combineTwo layout from the Combo documentation, without needing to configure layouts in the config file or switching between them explicitly, and without needing to remember many different keystroke combinations. Does this sound like such a layout mechanism would be reasonably easy to implement? Or is there already a way to get this behavior with existing modules? -Klaus

2 1

Issue 201 in xmonad: published contrib docs have some bad inline links
by codesite-noreply＠google.com 16 Aug '08

16 Aug '08

Issue 201: published contrib docs have some bad inline links http://code.google.com/p/xmonad/issues/detail?id=201 New issue report by vogt.adam: What steps will reproduce the problem? 1. http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Doc-Extending.html 2. look at the manageHook inline link; it points to http://xmonad.org/home/sjanssen/share/doc/xmonad-0.7/html/XMonad-Core.html#… What is the expected output? What do you see instead? sjanssen's home directory path should not be included; I only see this on inline links that refer to a specific section (....#that section) Please provide any additional information below. If this error is due to a module from XMonadContrib, please tag this issue with 'Component-Contrib' below. Component-Contrib 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

Issue 200 in xmonad: xmonad spins in a tight loop changing focus back and forth
by codesite-noreply＠google.com 15 Aug '08

15 Aug '08

Issue 200: xmonad spins in a tight loop changing focus back and forth http://code.google.com/p/xmonad/issues/detail?id=200 Comment #3 by k.kosciuszkiewicz: I have tried the patch, but the issue persists. No, I haven't used UpdatePointer in my config. -- 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 188 in xmonad: Changing focus from a dialog box in openoffice causes 100% cpu usage
by codesite-noreply＠google.com 15 Aug '08

15 Aug '08

Issue 188: Changing focus from a dialog box in openoffice causes 100% cpu usage http://code.google.com/p/xmonad/issues/detail?id=188 Comment #7 by Klaus.Weidner: See also issue #200, I've attached a previously posted patch there that works for me - OOo still refuses to let me move the pointer out of the window, but it doesn't loop and calms down as soon as I stop moving the mouse. -- 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 200 in xmonad: xmonad spins in a tight loop changing focus back and forth
by codesite-noreply＠google.com 15 Aug '08

15 Aug '08

Issue 200: xmonad spins in a tight loop changing focus back and forth http://code.google.com/p/xmonad/issues/detail?id=200 Comment #2 by Klaus.Weidner: Could you try the attached patch? I had sent this previously to the mailing list but it doesn't appear to have been applied. I tried your reproducing steps and everything is behaving as expected. Do you have the UpdatePointer module active? Mailing list posting copied below: [xmonad] patch: fix looping due to unnecessary window crossing events This patch fixes a race condition reported by David Roundy (Subject: Re: [xmonad] darcs patch: quick hack to avoid infinite (but breakable) loop when...): > The isMouseFocused hack introduced a race condition where if you click on a > tab to select a window, and then move the mouse down before the new window > is selected, the focus will alternate between the previously-focused and > newly-focused windows in an infinite loop. This loop can be broken by > moving the mouse up to the tab area, but it's pretty unpleasant. This race > condition is easily triggered on my laptop (and presumably on any older > computer running bloated applications like firefox). What is happening is apparently: a) click on tab causes window B to be focused (with mouseFocused true) b) mouse moves down into old window A, queueing an enter event for A c) xmonad maps window B, appearing under the mouse pointer d) enter event for B gets queued e) xmonad handles enter event for A, causing it to be focused f) xmonad maps window A, appearing under the mouse pointer g) enter event for B gets queued ... goto (c) The change is to ignore crossing events when the pointer is not currently in the window being reported as entered, for example due to having left it already, or if the windows were reshuffled due to keyboard commands. -Klaus Attachments: xmonad-core-ignore-obsolete-crossing-events.dpatch 4.9 KB -- 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