[openbox] focus follows mouse and keybinding raise/lower window
mangosoft at comhem.se
Tue May 9 04:27:06 EDT 2006
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.
>> 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
More information about the openbox