- xmonad - Haskell.org

Show name of focused window in status bar
by Kai Grossjohann 21 Aug '07

21 Aug '07

Do people think that showing the name of the currently focused window in the status bar (in addition to the workspaces) would be a worthwhile addition? If so, could you advise how to improve the quality of the code I've concocted? Given that I don't know Haskell, I'm happy that it runs. Here's what I did. To NamedWindows.hs I added the following function (and exported it): unWindow :: NamedWindow -> String unWindow (NW n _) = n In Config.hs I wrote: dynamicLogWName :: X () dynamicLogWName = do withWindowSet $ io . putStr . pprWindowSet io (putStr " // ") withNamedWindow $ io . putStr . unWindow io (putStrLn "") logHook = dynamicLogWName tia, Kai

2 3

darcs patch: CycleWS: a couple of simple functions to cycle between...
by Andrea Rossato 21 Aug '07

21 Aug '07

Hi, this is a module that exports a couple of simple functions to cycle between workspaces. It'll keep working when we will switch the type WorkspaceID = String Andrea Tue Aug 21 07:45:18 CEST 2007 Andrea Rossato <andrea.rossato(a)unibz.it> * CycleWS: a couple of simple functions to cycle between workspaces

1 1

xmonad on one head display
by jason 21 Aug '07

21 Aug '07

Hi all, I am satisfied user xmonad on PC with two head display configuration (with XINERAMA). I would like use xmonad on my notebook too. But I haven't found any way how to configure it. Xmonad always try to use XINERAMA and fails on one display notebook. Is there any howto or decription for this simple case? Thanks Jason

4 4

I just noticed...
by Isaac Dupree 20 Aug '07

20 Aug '07

XMonad layouts make the menu-bars of a window often be at the top of the screen. Well, one pixel away from the top of the screen. It would be better for mouse movement not to go off the window, like in Mac OS menu-bars: if the cursor wouldn't go onto those pixels, it is ergonomically easier (Fitts's law) to reach the menubars, because there is no limit on how much vertical movement you make. If there are buttons or something on the side or bottom of windows, this applies to them too. Is it a disadvantage not to be able to remove the cursor from within the bounds of the window? The ability to have full-screen windows automatically when there is only one window displayed at once seems like a really nice property (for VNC, or qemu, ... perhaps). I am then concerned about the small possibility of there being a way to remove the cursor from any window (assuming the current workspace contains ANY windows). If the border highlighting doesn't appear at the edges of the monitor, how to distinguish which of two windows is active? A two pixel (or four pixel possibly? depending on screen resolution...) buffer between windows, could indicate that with a color difference or gradient, and it could be as if the cursor were in the *nearest* window, on the edge of it (I wonder if that would confuse any apps, or if it could be done right...) P.S. I also have xmodmap my command/apple keys to Control modifier Here is what I currently do to my MacBook keyboard in case anyone's interested #Turn off caps-lock. #Make left and right command (apple) keys function as control keys # as well as the actual control keys. #keycode 108 (keysym 0xff8d, KP_ENTER) #I guess I'll turn "enter" into a "right alt/option" for now #rightAlt-shift-Return doesn't seem to work, but others # (rightAlt-shift-c) seem to (even with right shift) xmodmap \ -e 'remove Lock = Caps_Lock' \ -e 'clear Control' \ -e 'keycode 115 = Control_L' \ -e 'keycode 116 = Control_R' \ -e 'add Control = Control_L' \ -e 'add Control = Control_R' \ -e 'clear Mod1' \ -e 'keycode 108 = Alt_R' \ -e 'add Mod1 = Alt_L' \ -e 'add Mod1 = Alt_R' (for middle- and right- click I use F12 and [eject], which could be improved) Isaac

2 2

getting rid of CrossingEvent
by Andrea Rossato 20 Aug '07

20 Aug '07

Hi, I don't know if these patches ere going to be accepted, anyway this is my proposal: XMonad should not respond to CrossingEvent(s). That is to say, it should be the layout to decide whether entering a window with the pointer makes that window focused. The present behavior is incompatible with Tabbed (it forces a redraw of tabs every time the pointer enters a window). Moreover I don't like very much the fact that a keyboard driven WM gives such a power to the mice. It is possible to adopt a different approach, with the second patch attached: a layout modifier that makes a layout respond to CrossingEvent(s) by giving focus to the entered window. Unfortunately this second patch is incompatible with Tabbed too (well I'm not going to use it with Tabbed, obviously...;-), and in general with layouts that add hooks to modifyLayout the way Tabbed (via Decoration) does. This is a more general issue we should take care of: there's probably the need to add hooks to respond to different X Events, like Decoration.hs, without messing up with other hooks. I need it for my remote controlling stuff. But I'm not the only one. Indeed the same problem can be seen with SwitchTrans.hs (Lukas decided not to let David do the nice stuff he does with modifyLayout ...;-). This is also the reason why XMonadContrib.LayoutHelpers.idModMod is not a real identity, like erasing something is not anything anymore. We are hitting this problem frequently... Andrea

3 3

darcs patch: code cleanup in Main.
by David Roundy 20 Aug '07

20 Aug '07

Mon Aug 20 04:34:44 PDT 2007 David Roundy <droundy(a)darcs.net> * code cleanup in Main.

3 2

darcs patch: clear out motion events when processing one motion event.
by David Roundy 20 Aug '07

20 Aug '07

On my laptop anyhow (over six years old) this is completely necesary for adequate performance when something expensive is being done in the drag loop. And it's harmless, so far as I can tell. David Sun Aug 19 17:23:51 PDT 2007 David Roundy <droundy(a)darcs.net> * clear out motion events when processing one motion event. This is important if the hook is slow (e.g. try adding "float w" to the window-dragging hook), as it allows xmonad to keep up with the motion of the mouse.

3 2

darcs patch: don't refresh when setting focus to already focussed w...
by David Roundy 20 Aug '07

20 Aug '07

This fixes the issue that tabs refresh when mouse goes over tabs and then back over the window. But in general, it simply makes xmonad more efficient. David Mon Aug 20 11:02:25 EDT 2007 David Roundy <droundy(a)darcs.net> * don't refresh when setting focus to already focussed window.

2 1

darcs patch: add DragPane.
by David Roundy 20 Aug '07

20 Aug '07

This is basically like TwoPane, except that there's a little gap between the panes which you can grab and drag, so you can have finer-resolution control over the splitting. It also works nicely with Combo, so you can now have almost ion-like control over your layout. David Mon Aug 13 07:40:07 PDT 2007 David Roundy <droundy(a)darcs.net> * add DragPane.

2 1

darcs patch: remove unneeded do.
by David Roundy 20 Aug '07

20 Aug '07

Just a little cleanup... David Mon Aug 13 07:37:21 PDT 2007 David Roundy <droundy(a)darcs.net> * remove unneeded do.

2 1