[openbox] sloppy focus?

[corey at streamreel.net]

On Sun, Nov 16, 2003 at 09:53:20PM +0100, Peter Chiocchetti wrote:
<snippity-snip-snip> 
> 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 
  many others.

  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.


Beers,

Corey