[Xmonad] getting rid of CrossingEvent

[David Roundy]

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