[openbox] focus follows mouse and keybinding raise/lower window

[Mikael Magnusson]

On Mon, 8 May 2006, Emile Snyder wrote:

>
>>>> And with the mouse, it's possible Emile doesn't have a button to spare.
>
> This is in fact the case.
>
>>>> I'm not saying it should be a mainline change, but I do see why an
>>>> individual change would be warrented.
>>>
>>> Something still seems wrong to me about using the keyboard to lower a
>>> window because you "do not use the mouse much" and still depend on the
>>> location of the mouse pointer to determine focus. Maybe you want to use
>>> virtual desktops?
>
> I use 4 desktops layed out in a line with keybindings for next/prev
> desktop, and for raise/lower window.  Typically 2 or 3 of the desktops
> have 3x3 tilings of xterms plus a full desktop window of some stripe
> (emacs, web browser, mail client, etc.).
>
> Perhaps it's just a character flaw on my part of a lack of understanding
> of my options, but when I try to use next/prev window keybinding focus
> it takes me an average of 5 hits of the NextWindow key, each time
> spending mental energy on seeing whether the window I want to focus was
> next in line or not, every time I want to switch.  It's much much easier
> to just point at it; mice are good for that, I'm not trying to hit a
> small target, and I don't have to position my hand correctly on the
> mouse or anything to hit the right button (using focus follows mouse).
>
> For my usage pattern I am constantly wanting to flip windows up and down
> and have the thereby exposed window receive focus.  I am frankly
> surprised that more people don't have this desire, but the evidence of
> the respondents seems to be against me.  Can someone explain to me again
> what bad situation the existing behavior is protecting me from?

The one you want. Maybe i want to lower a window to look behind it, and 
then raise it again. That's hard to do if it loses focus just because the 
mouse pointer happened to be over it. On the other hand if i lowered it 
with a mouse binding i probably don't want it again, because if i use the 
mouse and want to look under a window i probably move it out of the way 
instead, or just shade it by scrolling on the titlebar in which case focus 
won't change because the cursor is still in the window. (I believe the 
original reason for adding the no-focus-change-on-keyboard-actions support 
was for moving windows with the keyboard, which originally only let you 
move a window within the reaches of the mouse pointer which was probably 
not what anyone wanted.)

With that said, I think it should be possible to add a flag to keyboard 
actions that let you specify if that particular action should let focus 
change or not, by checking for that flag in client_action_start/end.

> Thanks,
> -emile
>
>> That's what I do, but there are advantages (they are admittedly small,
>> though) to having two dimensions of stacks, one across desktops and one
>> within.  Sure you need *lots* of apps, or a need for strong grouping
>> to require such a paradigm, but, hey, to each is own, right?
>>> That way you know exactly where every window is and can
>>> have direct keybinds to them.
>>>
>>> --
>>> Mikael Magnusson
>>
>

--
Mikael Magnusson