I honestly don't know how to make this better. I can't ignore the EnterNotify
events because I get other identical events for other situations where you do
want the focus to change. There's no way to tell the difference between 2
identical EnterNotify events, not that I know of anyhow. If anyone can come up
with something smart for this I'd be pleased to work on it, but I have attempted
to solve this before and just ran into a brick wall.

Well, other window managers get it right, so there must be a way of solving it.

I'm at work right now, so I don't have time to go source-diving, I'll see if
I can do so later in the week.

Anyway, you'd want to ingore the EnterNotify events only if the pointer
position hasn't changed.  I don't know how difficult it would be to add
this check.  I'll take a look.

I don't agree the bug should be tagged as resolved though, as it is a bug,
and a very annoying one too.

That's not all. The case that making this work breaks is:

You middle-click the titlebar - lowers the window, and it hides behind another
window. In every attempt I've made, fixing the case you have described breaks
that one. Making it ignore enter notifies when the mouse hasn't move is another
solution that breaks this case.

Are these other window managers that get it right also broken in this situation?

I dare say that's a broken way of implementing the lower action.  You're then
basing it on the premise that the mouse will hover above the stack when it's
triggered, which is certainly not true in all situations.  For instance,
you might have three windows, two xterms stacked on top of each other, and a XMMS
in a corner corner.  The mouse is hovering over the XMMS window, while the
xterm on top of the stack has keyboard focus.  I call my preset keybinding to
lower the top xterm -- but the xterm that's now on top of the stack do -not- get
focus.

Another case it will break is if you've got two windows like this, and the
lower action bound to some mouse click with the title bar:

 +====+
 |    |=+
 |    | |
 |    | |
 +----+ |     
  +-----+

The newly raised window won't get focus.

On top of my head, I would have solved this not on the basis on where the
pointer reside (it's not unlikely that this position is totally irrelevant
anyway, as the lower function can be bound to keyboard hotkeys), but rather
on seeing if there was any client that got a VisibilityNotify event with
state VisibilityUnobscured as a result of the lowering, and then go on to
activating that client.  Perhaps, if no client got VisibilityUnobscured,
instead do some maths on the Expose events some clients might have got, and 
focus the one that got the largest addition of visible area as a result of
the lowering.

Do you agree with my reasoning?  I'm not familiar with the event handling code
of ob3 but I will look into it if you're agreeing that this would be a better
way.  The current way is a serious hindrance to using ob3 and using the keyboard
as much as possible (I detest the mouse, I believe was really close to getting
RSI before I switched to fvwm which allowed me to use the keyboard for all the
window manipulation).

By the way:  I do not know how the fvwm handles lowering, as I never used that
function -- I prefer keeping windows un-stacked.

Tore

I recently got an email from someone else interested in this. His proposal was
to not handle EnterNotify events, but instead focus a window when a motion event
ocurred over an unfocused window.

I'm not sure if this is an appropriate solution or not... as the case of the
lowering window would instead leave the focus on the lowered window until the
cursor moved.

The motion events option turns out to not be a good one. Many apps, like mozilla
foor example, catch the motion events and don't propogate them, so Openbox
doesn't receive them for much of the mozilla window.

Yes, and I don't think it would've been a very good idea anyway.  A conventional
mouse easily moves a few pixels simply because your your desktop moves a bit
when you shift your arm position, which could cause focus to jump around a
bit erratically.

However, you've yet to comment on my proposal (ignore EnterNotify if pointer
position hasn't changed, and use Visibility*/Expose events in the lower action
instead).  Would that be a feasible way of doing it, or is it too difficult to
implement the transition thing that we'd need?

(I'm sorry I've been more or less oblivious to ob developement lately, I've
been almost drowning in work and have used all the rest of my time for resting.)

Tore

Metacity also exhibits this behaviour with Mozilla.

Oroborus does not exhibit this behaviour with Mozilla, but only because it
centers the mouse pointer on the window whenever you use keys to focus.  (It
also has a somewhat annoying delay for which you have to hold the modifier key
down for in order for focus to stay on the newly focused window, but this is
probably a configuration thingy somewhere I forgot to set.)

As for moving the focused window out from under the mouse with keystrokes, and
focus falling through: in spite of recentering the cursor, Oroborus exhibits the
same bug.  Metacity does not because it recenters the cursor before the move,
and keeps the cursor centered throughout the move.

I think that keeping the pointer centered on the window when certain actions are
taken via keystrokes, in the case of focus follows mouse, is the best solution
(obviously ironing out any bugs that Metacity or Oroborus have).  Such a thing
would make sense, and when I was using FVWM, I think I actually implemented this
solution when I was in my sloppy focus phase.

I just had 2 brilliant thoughts.

1) Remove the move/resize actions that are causing these problems, since there
are already KeyboardMove and KeyboardResize that let you move in all directions
and use the mouse if you want, and won't have this problem.

2) Grab the mouse pointer, move the window, ungrab the mouse pointer. Problem
goes away.

I think 1) is better, as the actions are kind of redundant.

I have implemented 2) in CVS. So moves will no longer cause problems. I think
this resolves all the issues raised here. Please contradict me if I missed
something else.

I'm not sure how your first suggestion would solve the problem I first
described in this bug log (the Mozilla window placed next to the xterm),
as it does not involve any moving or resizing of any windows.  But then
again, I don't see how it would be solved by #2 either.  It is mayhap
a bug in Mozilla?  No, the same thing appear to happen in Konqueror as
well.  :-(

Also, I can't see how the actions are redundant, either -- KeyboardMove
and KeyboardResize seems to me to be interactive, while the MoveToEdge
and GrowToEdge actions just snaps to the nearest edge.  Unless you can
give the KeyboardMove and the KeyboardResize information that you should
go to the nearest edge in a given direction instead of interactively
moving them with the arrow keys, they offer quite different features.

About #2 -- it sounds very very simple.  Would that basically suppress
all pointer-related events while the pointer is grabbed?

Tore

Yes, it works like a charm now, for moving and resizing!  Thanks!  :-)

However the problem with focus warping to the window the mouse hovers over
when a drop-down list in another (previously focused) window closes, still
persists.  Hmm, I've got no idea on how to deal with that at the moment
though.  :-(

Tore

Ah yes, the menus. Reopening the bug. I haven't a good idea on this one either yet.

So I think this is fixed in CVS now. Let me know.

Indeed, it is working flawlessly now!  Thanks!  :-)

Tore