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

[Mikael Magnusson]

On Tue, 9 May 2006, Emile Snyder wrote:

> On Tue, 2006-05-09 at 10:27 +0200, Mikael Magnusson wrote:
>> On Mon, 8 May 2006, Emile Snyder wrote:
>>> 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.
>
> Hmmm.  If I'm beating a dead horse here just tell me to drop it and I
> will.  But, here's my long winded analysis of the two methods (complete
> with ascii art ;)  It seems to me that the thing the current behavior
> ignores is that it's very common that just looking behind the current
> window often doesn't expose enough information.  For instance, this is
> the (very typical, for me) use case I'm talking about:
>
> +-----------------------------------+
> | full screen mozilla               |
> | +----------+----------+---------+ |
> | |xterm 1   | xterm 2  | xterm 3 | |
> | |          |          |         | |
> | +----------+----------+---------+ |
> | |xterm 4   | xterm 5  | xterm 6 | |
> | |          |          |         | |
> | +----------+----------+---------+ |
> | |xterm 7   | xterm 8  | xterm 9 | |
> | |          |          |         | |
> | +----------+----------+---------+ |
> +-----------------------------------+
>
> So my mozilla window is behind all others, I'm working in xterm 4 and I
> want to see whats in the web browser then go back to working in xterm 4.
> I'll walk through what seem to me to be the options for how to do
> this...
>
> With current default openbox:
> I can send xterm 4 to the back easily with a key binding, but if I then
> want to raise mozilla so I can see the whole window I have to either use
> the mouse to move focus to one of the other xterms (since it's sloppy
> and so just jogging it with the pointer already over the unfocused
> mozilla window won't do it) and then back to the mozilla window, or use
> Next/PreviousWindow bindings and potentially cycle through many windows
> before I get to mozilla and can use my RaiseWindow key.  Then, when I'm
> done looking at the mozilla window and send it to the back I have to
> repeat the mouse process to give focus to the xterm.
>
> With refocus-after-lower change:
> hit lower-window key to get mozilla window focused, hit raise-window key
> to see it, hit lower-window key again to send mozilla to the back and be
> back where I started.  So simple, so easy!  How can you hate this?  ;)

This won't work if your mouse pointer isn't over xterm 4, for example if 
you NextWindow:ed to it. Which in your case i guess you didn't, but still.

> Am I missing something that makes this task equivalently easy in
> mainline?

If you switch between xterm 4 and mozilla a lot, NextWindow will always 
select the right one, if you switch between all terms and mozilla i guess 
that doesn't work as well. Having mozilla on another desktop works nicely, 
without depending on the position of the mouse pointer. You may also want 
to look into the DirectionalFocus{West,East,North,South} actions, they 
should give you a deterministic key press pattern from any specific xterm 
to mozilla and back.

>> 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.
>
> Hmm.  Am I right that you're just saying that the refocus-after-lower
> makes sense to you when using the mouse to do the lower?  I agree with
> you, but mostly because I think refocus-after-lower always makes
> sense ;)

heh.

>> (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.)
>
> This makes sense; thanks for providing the motivating context.
>
>> 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.
>
> So, for instance, the rc.xml file might have
>
> <keyboard>
>  <keybind key="C-Down">
>    <action name="Lower"><refocus>yes</refocus></action>
>  </keybind>
> </keyboard>
>
> with the default refocus of no?

Would refocus=yes or keepfocus=no be more logical here? Maybe it doesn't 
matter.

> If I provide such a patch might it be accepted?  Or is it one more
> fiddly little dial that the openbox team would prefer to avoid?

As it probably isn't more than 10 lines of code i'd say it's okay.

> Thanks everyone for your time,
> -emile
>

--
Mikael Magnusson