Subject: The "great focus policy rewrite"

From: Dominik Vogt <[email-masked]>
Date: Tue, 23 Jul 2002 15:21:39 +0200

In the best tradition of the "great style flag rewrite" I'm now
planning the "great focus policy rewrite" (GFPR) :-)  I'd like to
introduce a whole lot of new options to fine tune focus policies.
These may become sub options of a new "FocusPolicy" style instead
of independent styles:

Acquiring and releasing focus:

 1) Focus when pointer enters window
 2) Unfocus when pointer leaves window
 3) Focus when unfocused and client window clicked
 4) Focus when unfocused and decorations clicked
 5) Focus programmatically (with Focus or FlipFocus command)
 6) Focus when application graps the focus.

Overriding application specified focus model:

 7) Lenience

Raising windows:

 8a) Raise when client window is clicked
 8b) Raise when client window is clicked and window is unfocused
 9a) Raise when decorations are clicked
 9b) Raise when decorations are clicked and window is unfocused

Recyclicng raise/focus clicks:

 10) Pass focus clicks to application
 11) Pass raise clicks to application
 12) Allow bindings on focus clicks
 13) Allow bindings on raise clicks

Configuring the buttons to use:

 14) Buttons to use for raise/focus clicks
 15) Modifiers to use for raise/focus clicks

Currently,

  MouseFocus   = 1 + 2 + 5 + 6 + 12 + 13
  SloppyFocus  = 1 + 5 + 6 + 12 + 13
  ClickToFocus = 3 + 4 + 5 + 6 + 12 + 13
  NeverFocus   = (forbid all)
  Lenience     = 7

  ClickToFocusClickRaises = 8b + 9b
  <other>FocusClickRaises = 8a + 9a
  ...PassesClick = 10 + 11

The old styles can be translated to sets of other options.  New
proposed focus policies:

  ManualFocus  = 5 + 6 + ...
  ClickClientFocus = ClickToFocus - 4

Also, I suppose to add 3 and 4 to MouseFocus and Sloppy focus for
the (unavoidable) situations where you end up with the pointer
over and unfocused window.

All this not only allows a lot more flexibility for specific
windows.  It also simplifies the code in HandeButtonPress()
because we don't have to distinguish between abstract focus
policies anymore.  Instead the switches can be made on a
per-feature basis.

Do you have additional suggestions?  Did I miss anything that
could be added (I left out auto raising when the pointer enters a
window on purpose).

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, mail: [email-masked], phone: 0721/91374-382
Schlund + Partner AG, Erbprinzenstr. 4-12, D-76133 Karlsruhe
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Tim Phipps <[email-masked]>
Date: Tue, 23 Jul 2002 14:58:18 +0100

>could be added (I left out auto raising when the pointer enters a
What about when windows are created, mapped or generally change state or 
do you think FvwmEvent is the way to handle this?

Cheers,
Tim.

---

From: Bob Woodside <[email-masked]>
Date: Tue, 23 Jul 2002 11:18:05 -0400

On Tue, 23 Jul 2002 15:21:39 +0200
Dominik Vogt <[email-masked]> wrote:

> planning the "great focus policy rewrite" (GFPR) :-)

	Whew! I sense another round of grab code rewriting in the offing. Maybe this'll
make the code a bit easier to follow and debug, and we can finally squash the
old MouseFocus - MouseFocusClickRaises - doubleclick bug that I had to give up
on last year. (It still exists, by the way, but the current versions of xfm and
moxfm have my patches to work around it, and I don't know of any other common
apps that have the problem. But I still have my old test programs.)

Cheers,
Bob

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 23 Jul 2002 21:17:40 +0200

> These may become sub options of a new "FocusPolicy" style instead

[snip]

I forgot one important 'feature':  maintenance of the window list 
when a window is created or destroyed.  This depends on the focus
policy right now, but I don't know exactly how it works.  What
options do we need?

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 23 Jul 2002 21:12:21 +0200

Tim Phipps wrote:

> What about when windows are created,

GrabFocus and GrabFocusTransient handle this case at the moment.

> mapped

i.e. de-iconified

> or generally change state or do you think FvwmEvent is the way
> to handle this?

No, I don't think FvwmEvent is the way to handle anything.  It's
just plain buggy.  Well, not really, but it's so slow that it
regularly freezes fvwm itself or other modules if it's really
used.  In the long term, it should go into the fvwm core.  But for
now, it should suffice.

In general, we may not want to make a specific solution for state
changes in regard to focus policy.  As you proposed for the
"Style" rewrite, removing the distinction between window style and
state already requires triggering arbitrary actions on state
changes.  If this is ever implemented we'll get the focus policy
part for free.

On Tue, Jul 23, 2002 at 11:18:05AM -0400, Bob Woodside wrote:
> 	Whew! I sense another round of grab code rewriting in the
> offing. Maybe this'll make the code a bit easier to follow and
> debug,

Sure :-)  I still sometimes end up with windows that don't have
the grab as they should.  Just give me a chance to rewrite the
focus code - then we can take a close look at grabbing again.

> and we can finally squash the
> on last year.

> (It still exists, by the way, but the current versions of xfm and

Yes, I know.  We had a discussion about some problem your last fix
introduced right before your wife was in the hospital.  I disabled
that patch later because I saw no immediate fix.  It's still in
the code, though (focus.c, focus_grab_buttons() and MoveFocus()).

Bye

Dominik ^_^  ^_^

---

From: Mikhael Goikhman <[email-masked]>
Date: Wed, 24 Jul 2002 05:21:00 +0000

>  15) Modifiers to use for raise/focus clicks

Why not just replace 14 and 15 with 8=off, 9=off, 12=on, 13=on and real
Mouse bindings that do Focus or Raise or both?

I already do this. I.e. my Alt-Mouse2 RaiseLowers. Mouse6 Raises, Mouse7
slowly RaiseLowers (6 and 7 is the second wheel).

I don't think many people will benefit the new mixed possibilities.
But the code will be more clean after you touch it, I am sure.

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 24 Jul 2002 08:05:58 +0200

> Mouse bindings that do Focus or Raise or both?

Yes, that is very desirable.  How about this:

  FocusClick 1 w m raise-and-focus

FocusClick is roughly doing the same as Mouse, but kept separately
for the special treatment it needs.  We'd have to grab the mouse/
modifier combination from the binding only so that other clicks
get passed to the client without interference from fvwm.  I'm not
sure about the function that is triggered.  Raising and focusing
can't just be run from a complex function (or as a built in
command) because the client gets confused.

Bye

Dominik ^_^  ^_^