January 2013 - xmonad

Re: Issue 135 in xmonad: toggleBorders (XMonad.Action.NoBorders) Causes floating windows to grow in size
by codesite-noreply＠google.com 16 Jan '13

16 Jan '13

Comment #2 on issue 135 by neoraider: toggleBorders (XMonad.Action.NoBorders) Causes floating windows to grow in size http://code.google.com/p/xmonad/issues/detail?id=135 This bug occurred when I tried to disable the border of a Gnome-Do window automatically (it doesn't look nice with one), causing the Gnome-Do window to grow indefinitely, filling the whole screen after a few seconds. The attached patch solves the problem for me, making XMonad.Operations.floatLocation use the actual window border width instead of the globally configured one. Attachments: xmonad.patch 588 bytes -- 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 2

xmonad, XMonad.Hooks.EwmhDesktops, wmctrl -l and Firefox
by Thomas Løcke 16 Jan '13

16 Jan '13

Hey all, I've more or less solved all my issues, and I'm ever so slowly moving towards handing over the first two xmonad powered desktops to my employees. I do though still have one unsolved problem: wmctrl -l does not list all the windows that are currently open, so I can't reliable close Firefox with "wmctrl -c firefox" meaning that more often than not when Firefox is started, I get the nasty "restore" page. Quite annoying. I've added XMonad.Hooks.EwmhDesktops to xmonad.hs, but it does not appear to solve the problem. http://hpaste.org/80773 Anybody got an idea as to what else I can do to fix this? I need to be able to quit Firefox gracefully from a script, and plain pkill/kill just doesn't cut it. :o) Thomas Løcke

3 5

Workspace ordering and DynamicWorkspaces (+ patch)
by Hans Chen 14 Jan '13

14 Jan '13

I use DynamicWorkspaces with a few predefined workspaces. The problem is that when creating a new workspace, it gets sorted before my predefined workspaces and thus I can't always have e.g. "web" on Mod+1. When searching for this issue I found the following patch: http://www.haskell.org/pipermail/xmonad/2012-July/012810.html I've been using it successfully since then, and in my opinion this new behavior makes much more sense. My question is, does anyone know why the patch hasn't been merged yet? Is there anything I can do to get it merged? Note that I don't have anything to do with the patch, all credits goes to the original author Matthew Hague. Cheers, and great work with the 0.11 release! Hans

4 8

Updating focus after switching workspaces.
by Allen S. Rout 14 Jan '13

14 Jan '13

Could someone point me to the right area of the Fine Manual in which I'd find techniques to assert focus changes? I've got a bunch of workspace display features set more or less as I desire, with chords set to things like "Show me the web on the right, the mail client on the left, and the two screens for project 6 on the center two monitors". But when I've done so, I often find the focus is set differently than I'd prefer. As an initial goal, I was aiming for something like 'See where the mouse is? Put focus there'. - Allen S. Rout

2 1

Issue 524 in xmonad: fine-grained restoring of layout state
by codesite-noreply＠google.com 14 Jan '13

14 Jan '13

Status: New Owner: vogt.a...(a)gmail.com Labels: Type-Enhancement Usability New issue 524 by vogt.a...(a)gmail.com: fine-grained restoring of layout state http://code.google.com/p/xmonad/issues/detail?id=524 If the 'a' stays the same but the user changes the layout 'b', such that it cannot be read for layouts: onWorkspace "1" a b a ||| b Currently the whole layout will be reset to whatever the default is. It is possible to use the 'a'. For example using template haskell: https://github.com/liskin/liskin-xmonad-conf/blob/master/lib/XMonad/Layout/… Perhaps there's a way to do it without issues such as: - complicated code - template haskell - breaking all code that has `import XMonad'

1 0

Issue 523 in xmonad: Too small remembered pids hooks in XMonad.Actions.SpawnOn
by codesite-noreply＠google.com 14 Jan '13

14 Jan '13

Status: New Owner: ---- New issue 523 by kag...(a)genshiken.org: Too small remembered pids hooks in XMonad.Actions.SpawnOn http://code.google.com/p/xmonad/issues/detail?id=523 I use spawnOn in the startup hook because I want to run all needed programs at the their workspaces on window manager start. (I don't want to use manageHook because I may start using them on another workspaces.) The hook looks like this: startupHook' :: X () startupHook' = do args <- io getArgs -- Check for the first start unless ("--resume" `elem` args) $ do spawnOn "1" "firefox-bin" spawnOn "1" "deadbeef" spawnOn "2" "gajim" spawnOn "2" "thunderbird-bin" It works great but as soon as I need more programs for startup it doesn't shift all of them to the right place because spawnOn remember only 5: XMonad/Actions/SpawnOn.hs maxPids :: Int maxPids = 5 I tried to increase it to 20 and it keep working as supposed. So could you please apply it to upstream as well? However "20" fails in this issue too: it could be too small for some people, so maybe it should be "100" or even we should simply strip out any restrictions on max number of remembered pid/hook pairs. The only drawback that I can see in the last case: if window with remembered pid property will not appear, we will keep info about it in the state forever. But I don't think that it is a big problem. Labels: Component-Contrib

1 3

Re: [xmonad] Issue 182 in xmonad: Key bindings should be showable
by codesite-noreply＠google.com 12 Jan '13

12 Jan '13

Comment #2 on issue 182 by daniel.s...(a)gmail.com: Key bindings should be showable http://code.google.com/p/xmonad/issues/detail?id=182 Issue 489 has been merged into this issue.

1 12

Help with achieving desired layout
by Bryan Huh 12 Jan '13

12 Jan '13

Hi, I'm looking to achieve a certain layout with xmonad, but I'm finding the codebase and language quite daunting. I'm using "Mirror Tall" with dual monitors. The top half of my screens are for master windows, and the bottom half are for slave windows. I find though, that as long as I have more than one slave window in a workspace it makes the bottom half of the screen pretty unusable because it gets split evenly amongst all the slaves, and each slave window becomes unpleasant to view. It'd be nice if there was a main slave so that most or all of the "slave pane" is filled with the main slave window. Then I would have half of the screen filled with the master window, ~half filled with the main slave window, and a small fraction of the screen (maybe accordion style) filled with the remaining slaves. I imagine switching between the master and slave panes with alt-enter and alt-shift-enter, and navigating between slave windows with alt-j alt-k. The DragPane layout is close to achieving my desired layout, but the problem is that whenever the master window is focused, the second window in the stack is shown in the slave pane. This means that if I'm looking at a particular slave window and want to now focus on the master window, the slave window switches back to the second window and I essentially lose my spot in the slave stack. Does this make sense? How hard would this be to implement? Bryan

2 2

Re: Issue 306 in xmonad: Magnifier: keep magnified status if transient focused
by codesite-noreply＠google.com 11 Jan '13

11 Jan '13

Updates: Status: Accepted Labels: Type-Enhancement Component-Contrib Comment #3 on issue 306 by byorgey: Magnifier: keep magnified status if transient focused http://code.google.com/p/xmonad/issues/detail?id=306 This shouldn't be too difficult to implement (either Riccardo or Daniel's proposed behavior) given the new extensible state. -- 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 3

Re: Issue 304 in xmonad: CycleWS should actually track workspace history rather than depending on order of hidden workspaces
by codesite-noreply＠google.com 09 Jan '13

09 Jan '13

Updates: Summary: CycleWS should actually track workspace history rather than depending on order of hidden workspaces Status: Accepted Labels: Type-Enhancement Component-Contrib Comment #2 on issue 304 by byorgey: CycleWS should actually track workspace history rather than depending on order of hidden workspaces http://code.google.com/p/xmonad/issues/detail?id=304 The problem is that toggleWS simply assumes that the "previous workspace" is the one at the head of xmonad's internal list of hidden workspaces. But there are various operations other than switching away from a workspace which will also place it at the head of this list. There is nothing special about scratchpads here; if you shift any window on the current workspace to another workspace, that other workspace will now be the "previous workspace" as far as toggleWS is concerned. The real problem is that the order of workspaces in xmonad's list of hidden workspaces is not really supposed to mean anything, so toggleWS is depending on undefined behavior. The only way to really fix this would be to have CycleWS track the workspace history itself. Here's a sketch of a possible solution: CycleWS could use the new extensible state to track the workspace history, and provide something to put in the logHook that would notify CycleWS every time the current workspace changes. (It would be nicer if putting something in the logHook was not necessary, but otherwise it is not clear how CycleWS would find out about workspace changes.) -- 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 3