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

[Emile Snyder]

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?  ;)

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

> 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 ;)

> (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?

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?

Thanks everyone for your time,
-emile
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://icculus.org/pipermail/openbox/attachments/20060509/d48fdf91/attachment.pgp>