[openbox] sloppy focus?
corey at streamreel.net
corey at streamreel.net
Sat Nov 15 22:55:35 EST 2003
On Sun, Nov 16, 2003 at 09:53:20PM +0100, Peter Chiocchetti wrote:
> raiseDelay is just a workaround for a bug in ffm, preventing that all
> the windows you move the mouse over permanently pop up; its the same
> bug, that made Ben implement focusDelay :)
I'm afraid I'll have to step out a bit here - with all due respect and
good natured intentions - and say that it is perhaps possible that Ben
may have chose a less than satisfactory way of implementing the focus
follows mouse model in ob3. By trying to avoid what seems to be a peeve
with the very nature of FFM, it looks as though you've introduced an
entirely strange new approach, that works for the specific preferences
for a few, but manages to totally circumvent the long standing habits of
I'll just go ahead and state my case of the matter here, all in one place,
one last time - then I'll put a rest to it; leave it to you guys to do what
you feel is best.
Focus Follows Mouse Behavior In Other Window Managers:
Gnome/Metacity - implements raiseDelay
KDE/Kwin - implements raiseDelay
XFCE - implements raiseDelay
BlackBox - implements raiseDelay
OpenBox2 - implements raiseDelay
WindowMaker - implements raiseDelay
OpenBox3 - implements... "focusDelay"???
This does not compute.
The existing standard behavior used by _every_other_window_manager_ I know
of implements FFM as follows:
#1 Implicit immediate focus on mouse-over
#2 Optional raise on mouse-over
#3 Configurable raise delay throttle, available when #2 is enabled
The immediate focus on mouse-over not only allows you to immediately begin
working in a window - regardless of your raise setting(s) - but it also
serves as an extremely useful and important visual clue, indicating that
the window under the mouse has gone "live". Whether it raises immediately,
after a delay, or not at all, is entirely up to the user.
Not strictly focusing with the mouse when "focus follows mouse" has been
enabled is completely backward, unintuitive and unhelpful. Why is it called
"focus follows mouse" in the first place? Because the _focus_ ... follows ...
the mouse. What the current ob3 does, is it essentialy forces the focus to
be constrained until the raise event.
The tried-and-true FFM model utilized in all those other wm's generaly
facilitates for the personal preferences of everyone:
Those who don't like ffm, can keep that option disabled
Those who _do_ like ffm, can enable it
Those who enable ffm, can choose to enable windows raise-on-mouse-over
Those who enable raise-on-mouse-over, can specify the raise delay timing
The only thing that the above fails to provide for - are those people
who prefer FFM ( with or without auto-raise ), but do not like it when
they move the mouse across the screen and have the last window _touched_
to gain focus rather than the window _last_focused_ to have focus. If
such behavior is desired by one or more of the ob3 developers, then
shouldn't it be added as an option, while keeping the standard mode of
operandi in place?
With all of ob3's claims of standards compliancy, it seems strange to me
that it would single out one particular de-facto standard (ffm) and tweak
it just enough to feel "strange" to anyone used to the normal behavior.
I feel kinda silly going into so much effort describing the whole thing, but
at least now I feel like my points have been made distinctly clear. blah
blah blah - when it gets down it, I got my patch, so no reason for me to
get uptight over the whole thing. You guys have done a great job on ob3,
thanks for the great work - it's definitely my favorite wm.
More information about the openbox