July 2012 - xmonad - Haskell.org

XMonad and Xfce panel workspace question
by Pablo Olmos de Aguilera C. 13 Jul '12

13 Jul '12

After some suffering, I managed to configure to use Xfce as a DE with xmonad as its WM. As stated in the wiki, the workspace panel plugin worked nice with xmonad workspaces, and it does... partially. I ran xmonad in two monitors, my main monitor (1920*1080), the laptop monitor (1366*768) and I have 7 workspaces. The problem is that Xfce thinks both monitors are ONE workspace, so each workspace "slot" is divided into two, the left half is the first monitor, and the right half the second monitor. The rest of the workspaces left side shows the apps opened in their respective WS, and the right side is empty. I'm sending a screenshot, maybe it can help to clear things a bit: http://imgur.com/Oogzq. In this case, I have three terminals opened in the first WS and only one in the sixth. As you can see, the panel shows the 6th WS empty (which is not). If I move between the workspaces in the main monitor, in the panel looks like only the right half is moving. I can see that xmonad and xfce understands workspaces differently, but it's a bit annoying (and confusing) to have those empty spaces. Honestly, I don't mind being able to make xfce "ignore" the second monitor and just show the first one. I imagine that something similar has to happen with kde or gnome, so I was wondering if there was a way to deal with this. Warm regards, -- Pablo Olmos de Aguilera Corradini - @PaBLoX http://www.glatelier.org/ http://about.me/pablox/ http://www.linkedin.com/in/pablooda/ Linux User: #456971 - http://counter.li.org/

2 1

Re: [xmonad] doFullFloat keybinding?
by Matthew Hague 11 Jul '12

11 Jul '12

> Date: Tue, 10 Jul 2012 10:23:23 +0200 > From: 1126 <mailinglists(a)elfsechsundzwanzig.de> > Subject: [xmonad] doFullFloat keybinding? > To: Xmonad Mailinglist <xmonad(a)haskell.org> > Message-ID: <20120710082323.GA17177(a)1126.localdomain> > Content-Type: text/plain; charset=us-ascii > > When evince is FullFloating I got problems when opening more than one > instance of it, like a second paper. It just lets the first one disappear > under the freshly opened one. The solutions discussed already are probably the way to go for a clean approach, but just a remark on this point, as it's a general problem with floating windows in xmonad. There's a (undocumented, i think) function raiseWindow that you can use to put a window in front of all others. I guess this isn't called by default since tiled windows don't need to be raised in front of each other (whereas floats do). So you can add this to your config to get around it, but maybe it's a hack: raiseFocused :: X () raiseFocused = do disp <- asks display mw <- gets (W.peek . windowset) maybe (return ()) (io . (raiseWindow disp)) mw myLogHook = ... <+> raiseFocused <+> ... Matt

4 3

"Park" windows in a named group automatically
by Klaas van Schelven 11 Jul '12

11 Jul '12

Hi all, I really love what XMonad is doing for my productivity. There is, however, one particular scenario in which I feel I'm doing to much by hand. Say I've got my development env. set up and I'm working on project A. On screen 1 I've got my browser, on 2 one or two shells and on 3 my editor. Now, a client calls with an urgent question, or my coworker asks if I can help her out. Now I need to set up screens 1, 2 & 3 with a browser with different content, one or two shells on different servers/directories and an editor with different open files. It would be great if I could have some command / keybinding / whatever that quickly parks the contents of certain screens to a named location, i.e. (conceptually) "Park my current state to 'Project A'" set up new stuff to deal with the interruption park the new stuff in "Helping coworker" go back to "Project A" I'd love to hear a solution for this, even if it's not exactly along the lines of what I just described. ciao -- Klaas van Schelven +31 6 811 599 10

3 2

Re: [xmonad] doFullFloat keybinding?
by Matthew Hague 11 Jul '12

11 Jul '12

> >> Date: Tue, 10 Jul 2012 10:23:23 +0200 > >> From: 1126 <mailinglists(a)elfsechsundzwanzig.de> > >> Subject: [xmonad] doFullFloat keybinding? > >> To: Xmonad Mailinglist <xmonad(a)haskell.org> > >> Message-ID: <20120710082323.GA17177(a)1126.localdomain> > >> Content-Type: text/plain; charset=us-ascii > >> > ... > > The way to raise the focused floating window without going behind > xmonad's back is to use shiftMaster. mod+click does this by default. > http://hackage.haskell.org/packages/archive/xmonad/latest/doc/html/XMonad-S… > ...prolly don't want to stick that in your log hook, though. Ah, yeah, this too: though if you do this to every window that gets focus, you won't be able to mod+j/k your way through anything but the first two windows. (In fact, for floats, i shiftMaster on modkey release (emulating the usual Windows alt-tab stacking behaviour), but this means you can't see what you're selecting until you've selected it...). Matt

1 0

ManageHook and child windows
by Raghavendra D Prabhu 09 Jul '12

09 Jul '12

Hi, I am using ManageHook to assign windows to workspaces; however, sometimes I tend to move the window to other workspace and after that happens, any dialog/child window of this window appears in the original assigned workspace and not in the new workspace. Is there a way to fix / workaround this? Regards, -- Raghavendra Prabhu GPG Id : 0xD72BE977 Fingerprint: B93F EBCB 8E05 7039 CD3C A4B8 A616 DCA1 D72B E977 www: wnohang.net

4 9

Re: [xmonad] ManageHook and child windows
by Matthew Hague 08 Jul '12

08 Jul '12

> >>> On Sat, Jun 23, 2012 at 2:30 PM, Raghavendra D Prabhu > >>> <raghu.prabhu13(a)gmail.com> wrote: > >>>> > >>>> Hi, > >>>> > >>>> I am using ManageHook to assign windows to workspaces; however, > >>>> sometimes I > >>>> tend to move the window to other workspace and after that happens, any > >>>> dialog/child window of this window appears in the original assigned > >>>> workspace and not in the new workspace. > >>>> > >>>> Is there a way to fix / workaround this? Not really a fix to the problem, but my workaround for this is to use manageHook to say which workspaces Firefox should *not* appear on, rather than which ones it should appear on. Whether this makes sense for you depends on your set up really. So i have something like this in my manageHooks: myManageHook = composeOne . concat $ [ [ resource =? t -?> doViewShift specialWorkspace1 | t <- mySpecials1 ] [ [ resource =? t -?> doViewShift specialWorkspace2 | t <- mySpecials2 ] , [ fmap Just doAvoidSpecial ] ] where doViewShift = doF . viewShift viewShift = liftM2 (.) W.greedyView W.shift doAvoidSpecial = doF avoidSpecial avoidSpecial ss = viewShift ws ss where curws = W.currentTag ss ws = if (curws `elem` mySpecialWorkspaces) then defaultWorkspace else curws where viewShift was taken from the online tutorials, and composeOne comes from managehelpers. Matt

1 0

Newbie questions (wrt floating windows)
by Matthew Hague 07 Jul '12

07 Jul '12

Hi, I've just begun an attempt at moving to XMonad, and have a couple of questions. 1) I like titlebars but find that the decorators (e.g. noFrillsDeco) do not apply to floating windows. Is there a way to decorate the floats too? Even better: is there a way to apply decorations only to certain windows (i.e. in the manageHook)? 2) The floating windows are always in front of tiled windows. This is annoying: i would like to be able to script something so that the floating layer is hidden if a tiled window is focused. Is there some command along the lines of "hide all floats"? (I'm sure #2 runs against the whole philosophy of tiling window managers, but i like a "mongrel" workspace for freeform messing around, and tiling for when i'm down to some serious work.) Best, Matt

2 2

Workscreen extension
by kedals0＠gmail.com 06 Jul '12

06 Jul '12

Hi, I'm glad to send you a patch to introduce 'workscreen' concept. A workscreen permits to display a set of workspaces on several screens. In xinerama mode, when a workscreen is viewed, workspaces associated to all screens are visible. The first workspace of a workscreen is displayed on first screen, second on second screen, etc. Workspace position can be easily changed. If the current workscreen is called again, workspaces are shifted. This also permits to see all workspaces of a workscreen even if just one screen is present, and to move windows from workspace to workscreen. I use XMonad since 3 years, and I want to thank you for this WM. Hoping that you will be interested by this extension, Yours sincerely, Dal

1 0

Proposed patch to workspace ordering by index
by Matthew Hague 04 Jul '12

04 Jul '12

I have attached a proposed patch for workspace ordering by index. Currently, when using dynamic workspaces, newly created workspaces appear before configured ones in various default orderings. This is because new workspaces, which do not appear in the config file, are assigned the index Nothing (rather than, e.g. Just 4). In particular when using DynamicWorkspaces' "toNthWorkspace", you would find that, say, your 2nd workspace changes each time you add a new workspace -- so you can't reliably have, e.g., your email on workspace 2. A more general solution would be to add custom sortings to the methods in DynamicWorkspaces (and similarly the hooks for xmobar &c). However, i think putting "Nothing" last is more natural as a default. Matt

1 0

Capturing modkey release
by Matthew Hague 03 Jul '12

03 Jul '12

Hi (again), Is there a way to capture a release of the modkey using e.g. the event hooks? I've tried modifying the source for debugkeyevents: http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Hooks-DebugKeyEvents.ht… but this only captures the release of "proper" keys, not the modifiers. (E.g. pressing mod+j will generate a press and release of the j key (with information about it's modifiers), but not the press and release of the modkey). The goal is to have a tiling layout where, after selecting a window with mod+j/k, that window is promoted to master. To do this cleanly we need an event that means "the window has been chosen", for which the release of the modkey is ideal. (There is the MagicFocus layout modifier, but instead of waiting for the release of the modkey, it performs the shift after every mod+j, and needs an unintuitive window cycling policy to allow access to anything but the top two windows.) Thanks, Matt

3 3