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
On Sat, Aug 18, 2007 at 03:50:48PM +0200, Andrea Rossato wrote:
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.
Actually, the present behavior works as it is supposed to with Tabbed: when focus changes, we *need* to redraw the tabs, so they will properly reflect the focus. It's foolish that every redraw involves first removing the old tabs and then creating new ones... and in fact, I'm now submitting a patch that fixes this. But the issue isn't with the hooks, it's that we're unnecessarily calling refresh. I agree that this should be customizeable, but would prefer to keep focus-follows-mouse as the default. But then again, I've never been a fan of the concept of a keyboard-driven WM. It's just a poor user interface for most WM tasks. e.g. tabs give you O(1) selection of windows, vs mod-tab is O(N) selection of windows, the smaller prefactor on the keyboard approach makes it desireable as an option, but once you've got a dozen or so windows in a workspace, using mod-tab to cycle to the window you want (and potentially swapping in iceweasel in the process) becomes far less appealing. I like the idea of xmonad as a user-driven WM...
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'm not clear as to what this need is. Where is the problem with the existing hook structure?
I need it for my remote controlling stuff. But I'm not the only one.
I think I can see this: you want to insert hooks that are not part of a Layout?
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...
This is quite a different issue. The issue here is just that Lukas has chosen not to properly support either self-modifying layouts or self-modifying transformers. I don't think this is because it couldn't be supported, but rather because he wrote what I would call buggy code (just see how often he ignores the return value of modifyLayout). It's unfortunate that it's so easy to do so, but I haven't come up with a framework that is more bulletproof. -- David Roundy http://www.darcs.net
On Mon, Aug 20, 2007 at 11:22:17AM -0400, David Roundy wrote:
On Sat, Aug 18, 2007 at 03:50:48PM +0200, Andrea Rossato wrote:
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.
Actually, the present behavior works as it is supposed to with Tabbed: when focus changes, we *need* to redraw the tabs, so they will properly reflect the focus.
Sorry, I didn't mean this: what I meant is that mouse focus forces tabs to be redrawn whenever the pointer enters the focused windows coming from tabs (you've just sent a patch to correct that if I read correctly).
I like the idea of xmonad as a user-driven WM...
I was just kidding when talking about mice's power...;-) If your patch will make mouse focus a bit less noticeable, I can live with it.
I need it for my remote controlling stuff. But I'm not the only one.
I think I can see this: you want to insert hooks that are not part of a Layout?
That's it.
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...
This is quite a different issue. The issue here is just that Lukas has chosen not to properly support either self-modifying layouts or self-modifying transformers. I don't think this is because it couldn't be supported, but rather because he wrote what I would call buggy code (just see how often he ignores the return value of modifyLayout). It's unfortunate that it's so easy to do so, but I haven't come up with a framework that is more bulletproof.
I'm quite aware that I seem not to get something about layout modifiers. I thought that adding a hook was just like: layoutModifier :: Layout a -> Layout a layoutModifier cl@(Layout {doLayout = dl , modifyLayout = ml}) = Layout {doLayout = dl , modifyLayout = modLay} where modLay sm | Just e <- fromMessage sm = do handle_event e ml sm | otherwise = ml sm handle_event e@(AnyEvent {ev_event_type = t}) | t == whatEverEvent = do io (putStrLn "Hello World") >> return () -- but focus w ??? handle_event _ = return () But if I change "putStrLn Hello..." with focus w, that is to say, if I change the stack of windows what should I do next? runlayout (with the need of recalculating the screen rectangle), for instance? This is not clear to me and I seem not to be able to get it only by studying the code (your code actually). Self-modifying layouts and layout transformers is precisely what I want to understand. Can you give me some directions, please? Thanks for your kind attention, Andrea
On Saturday 18 August 2007 08:50:48 Andrea Rossato wrote:
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
We might look at making focus layout dependent later on, but I think David's "don't refresh when setting focus to already focussed window." patch is good enough for now. Cheers, Spencer Janssen
participants (3)
-
Andrea Rossato -
David Roundy -
Spencer Janssen