August 2007 - xmonad - Haskell.org

help with layout modifiers
by Andrea Rossato 29 Aug '07

29 Aug '07

Hi, this is something I'm not able to solve without some help, I think. Suppose I want to implement the mouse focus with a layout modifier: now XMobar changes the focused window when you enter it with the pointer, and this is done in Main.handle. It would be nice to do that at the layout level, with modifyLayout returning a new layout when a crossing event is generated. In order not to bother layout writers, it should be possible to implement the mouse focus as a layout modifier, which add a hook to a specific layout event handler. While this approach (code below) works in general, it doesn't work with layouts that add other X event hooks, like Tabbed, or DragPane. The problem is that, when I modify the windows stack in the event handler below, I don't have a clear idea of how the XState should be modified. I think I just need some direction...;-) To test the code below you need to comment out from Main.hs this function: handle e@(CrossingEvent {ev_window = w, ev_event_type = t}) | t == enterNotify && ev_mode e == notifyNormal && ev_detail e /= notifyInferior = focus w And this is the example code. You use it like this, in your Config.hs: defaultLayouts = [ mouseFocus $ dragUpDownPane "dd" 0.1 0.5 , mouseFocus $ tabbed shrinkText defaultTConf , mouseFocus tiled ] mouseFocus :: Layout a -> Layout a mouseFocus cl@(Layout {doLayout = dl , modifyLayout = ml}) = Layout {doLayout = doLay , modifyLayout = modLay} where doLay r s = dl r s modLay sm | Just e <- fromMessage sm = do handle_event e ml sm -- right?? | otherwise = ml sm handle_event e@(CrossingEvent {ev_window = w, ev_event_type = t}) | t == enterNotify && ev_mode e == notifyNormal && ev_detail e /= notifyInferior = do focus w -- what should I do to XState after this? return () handle_event _ = return () Thanks for your kind attention. Andrea

2 4

darcs patch: fix bug leading to early exit in XPrompt.
by David Roundy 29 Aug '07

29 Aug '07

I think perhaps this bug only manifests itself when working with tabbed. David Mon Aug 27 14:58:58 EDT 2007 David Roundy <droundy(a)darcs.net> * fix bug leading to early exit in XPrompt.

3 6

darcs patch: make code more compact in XPrompt.
by David Roundy 28 Aug '07

28 Aug '07

This should definitely not be applied unless it's approved by Andrea. It's a side-effect of my debugging attempt which resulted in the previously-sent bug fix for XPrompt. I compactified the code so I could read it (since I can't read what I can't see, so a function that doesn't fit on the screen is pretty hard to debug. But obviously some people like large quantities of superfluous space... David Mon Aug 27 14:59:23 EDT 2007 David Roundy <droundy(a)darcs.net> * make code more compact in XPrompt.

2 3

'rules' like in dwm
by Karl. 28 Aug '07

28 Aug '07

Hi, I'm currently using dwm, and considering switching to Xmonad. I've been trying to figure out whether Xmonad supports the features that are important to me. The one I haven't been able to figure out for certain is: Does Xmonad support defining rules as to which workspace a new window will appear in? Under dwm I use specific workspaces for specific things - my web browser always goes on the same workspace, regardless of where I am when I launch it. I have some rules defined in my dwm config that specify this. This consistency is one of the essential things that I like about dwm. Another approach, instead of rules defining workspace based on client properties, would be if it is possible for a keybinding to specify where a client should go when it is launched eg. Ctrl-Alt-B = launch browser and make it go to workspace 'web' As far as I can tell so far, under Xmonad, new windows will just appear in the current workspace. thanks, Karl.

3 2

Issue 45 in xmonad: xmonad should be smarter about mouse movement
by codesite-noreply＠google.com 27 Aug '07

27 Aug '07

Issue 45: xmonad should be smarter about mouse movement http://code.google.com/p/xmonad/issues/detail?id=45 Comment #7 by SpencerJanssen: Turns out to be an unclutter issue -- and there is a workaround "unclutter -grab". 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

Make some workspaces prefer some heads
by Kai Grossjohann 27 Aug '07

27 Aug '07

I find that the current workspace switching model does not match my usage pattern. My usage pattern is that I tend to use the same head to view a given workspace. Is there anyone who prefers a similar working style and who could provide code to implement it? I know that you guys usually tell me that I can do it myself and that it is very easy, but this time, I am doubtful. My working style: - There should be a command to say "workspace X prefers head Y" (for example with X being the currently focused workspace and Y the currently focused head). - When switching to a workspace, display it on the preferred head. (If there is no preferred head, have some rule such as to always show it on the second head.) - There should be a way to say that I want to view workspace X on the current head, no matter what X's preferred head is. FWIW, I have a single workspace dedicated to full-screen windows (currently, Firefox, OpenOffice.org and Adobe Reader) that I display on the internal laptop display, whereas all other workspaces are usually displayed on the external display. This means that I can keep up with my favorite newsticker while waiting for compilations to finish, and watch the logs while using the web application I'm developing. However, from time to time I want to see a workspace with terminal windows and a workspace with VMware at the same time, so I either move the terminal windows workspace to the internal head, or the VMware workspace to the internal head. Kai

2 1

Issue 45 in xmonad: xmonad should be smarter about mouse movement
by codesite-noreply＠google.com 27 Aug '07

27 Aug '07

Issue 45: xmonad should be smarter about mouse movement http://code.google.com/p/xmonad/issues/detail?id=45 Comment #6 by chikito...(a)yahoo.es: Thanks :) Now it works ok. Antonio -- 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 45 in xmonad: xmonad should be smarter about mouse movement
by codesite-noreply＠google.com 27 Aug '07

27 Aug '07

Issue 45: xmonad should be smarter about mouse movement http://code.google.com/p/xmonad/issues/detail?id=45 Comment #5 by andrea.rossato: as far as I understand, when unclutter hides the pointer it sends a fake EnterEvent, which makes XMonad think the mouse just entered the window. a workaround is to launch unclutter with the -grab option: unclutter -grab I keep on suggesting to get rid of the CrossingEvent stuff...;-) andrea -- 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 45 in xmonad: xmonad should be smarter about mouse movement
by codesite-noreply＠google.com 27 Aug '07

27 Aug '07

Issue 45: xmonad should be smarter about mouse movement http://code.google.com/p/xmonad/issues/detail?id=45 Comment #4 by andrea.rossato: You are right: I can reproduce it indeed. Sorry, but I did not correctly understand your report, before. Andrea -- 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 45 in xmonad: xmonad should be smarter about mouse movement
by codesite-noreply＠google.com 27 Aug '07

27 Aug '07

Issue 45: xmonad should be smarter about mouse movement http://code.google.com/p/xmonad/issues/detail?id=45 Comment #3 by chikito...(a)yahoo.es: Now I installed the darcs version and still the same problem. Btw, when typing mod-j or mod-k, focus changes a moment and quickly returns to first window (same behaviour in previous version). Antonio -- 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