[openbox] move mous cursor with window when moving to edge

[Stefan Klinger]

On 06 May 2010, Dana Jansens wrote with possible deletions:
> 
> On 2010-05-05, at 4:38 AM, all-lists at stefan-klinger.de wrote:
> >    <focus>
> >      <followMouse>yes</followMouse>
> >      <underMouse>yes</underMouse>
> >      ...
> >    </focus>
> > 
> > When I move a window with the keyboard [W-m Right Right Return], the mouse
> > cursor moves with it, which is fine. Since I rely on
> > <underMouse>yes</underMouse>, leaving the cursor in place would switch the focus
> > to another window when the window-to-be-moved "left" the cursor.
> > 
> > When I move a window with the keyboard to an edge, e.g., [W-Right W-Right], the
> > mouse cursor *dose*not* move with it. That's bad, because I usually want to move
> > the window a couple of edges away, but if the window-to-be-moved "left" the
> > cursor, another (lower) window will recieve the focus and be moved instead.
> 
> I am wondering if you are aware how underMouse works. underMouse means that when you move a window without moving the mouse, the focus stays under the mouse.  If you keep followMouse on and underMouse off, you can move things with the keyboard and focus stays in them since the mouse did not move.
> 
> > 
> > Is there an option to solve this? I was looking for something like
> > 
> >  <keybind key="W-Right">
> >    <action name="MoveToEdgeEast">
> >      <warpMouse>yes</warpMouse>
> >    </action>
> >  </keybind>
> > 
> > but could not find anything alike.
> 
> We haven't had a situation where a combination of underMouse and followMouse didn't work, so this does not exist right now.
> 
> Note also, that just because the mouse moved would _not_ guarantee that it stayed in the moving window, if the window is not the highest in the stacking order.  So underMouse=true could still end up moving the focus away from the moving window in this case.
> 
> To me it seems that underMouse should be off for you, but maybe you can explain further your requirements.

True, setting underMouse off would solve the problem, but I'd rather have the focus where my mouse is, especially when I switch the desktop. I was also thinking about your arument when the moving window is not the highest in the stacking order, and I stumbled over another peculiarity (maybe even a bug):

When I start a move action on a window A, and move it under a window B so that the pointer is in B, then I still move window A which holds the focus (that's good). Now if I end the move action, the (maybe only partially) obscured window A retains the focus, although B should receive it, since the pointer is in B which lies above A. I think that's not ok. If I want B to have the focus, I need to move the mous out and back in again.

More important: With respect to the (Move|Grow)ToEdge* actions I'd suggest that they should be handled more like a move action, i.e., something you can start and end: The pointer should move with the window, and the focus should be reassigned not until I let go *all* keys.

To clarify this a bit more: Assume Super-Right is bound to MoveToEdgeEast, the following should happen:

  1. hold down Super
  2. type Right
     --> window moves east, and takes pointer with it.
         window retains focus, even if another window is now under the pointer.
  3. goto 2 until satisfied
  4. release Super
     --> focus reassigned to whatever window is under the pointer now.

A straight approach would be to never reassign the focus while any modifier key is pressed.

What do you think?


-- 
Stefan Klinger                                      o/klettern
                                                    /\/  bis zum
send plaintext only - max size 32kB - no spam         \   Abfallen
http://stefan-klinger.de