Subject: GFPR Testing - Observations

From: Bob Woodside <[email-masked]>
Date: Sun, 11 Aug 2002 12:57:38 -0400

I've found several bits of weirdness so far:

	1) ClickToFocusPassesClick...doesn't. You have to click a second time to get a
click through to the app.
	2) ClickToFocusRaises...doesn't. (Reported also by Giuseppe Della Ricca.)
	3) If MouseFocusClickRaises is set and ClickToFocus is also in effect, mouse
clicks don't seem to get through to apps at all.
	4) Switching focus options back and forth seems to make some options suddenly
start working that formerly didn't, and others mysteriously to stop working. I'm
wondering if your recent commit with the tantalizing comment "Fixed a typo in
the chain of if conditions" may have something to do with this.
	5) Some apps have a problem such that when a transient dialogue window is
closed focus does not revert to anyone -- not the transient-for target (which it
used to do), not the last focused window (which it used to do even further back
in history), not anyone. I'm seeing this with nedit (e.g., the "Search"
dialogue), and haven't looked too much further; so it may be a Motif-specific
(or even XtLib) thing (I don't see it happening with sylpheed, which is Gtk).

	I see that you've done several commits since my last update, so I'll freshen up
my copy in a bit and see how many of these things may have gone away already.

Cheers,
Bob

--
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: Bob Woodside <[email-masked]>
Date: Sun, 11 Aug 2002 13:59:08 -0400

OK, after updating a few minutes ago, here's what's changed.

> 	1) ClickToFocusPassesClick...doesn't. You have to click a second time to
> 	get a click through to the app.

	Appears to be fixed.

> 	2) ClickToFocusRaises...doesn't. (Reported also by Giuseppe Della

	Still doesn't work. However, I notice that MouseFocusClickRaises causes the
same behaviour expected from ClickToFocusRaises, if you turn on ClickToFocus. In
other words, MouseFocusClickRaises is behaving like a generic "FocusClickRaises"
option, and ClickToFocusRaises has no effect.

> 	3) If MouseFocusClickRaises is set and ClickToFocus is also in
> 	effect, mouse clicks don't seem to get through to apps at all.

	Fixed. But see note on # 2 above.

> 	4) Switching focus options back and forth seems to make some options
> 	suddenly start working that formerly didn't, and others mysteriously to
> 	stop working.

	Haven't had time to test this thoroughly, but I'm not seeing the weird
inconsistencies I was before.

> 	5) Some apps have a problem such that when a transient dialogue window
> 	is closed focus does not revert to anyone -- not the transient-for
> 	target(which it used to do), not the last focused window (which it used
> 	to do even further back in history), not anyone. I'm seeing this with
> 	nedit (e.g., the "Search" dialogue), and haven't looked too much
> 	further; so it may be a Motif-specific (or even XtLib) thing (I don't
> 	see it happening with sylpheed, which is Gtk).

	Still broken.

Cheers,
Bob

---

From: Dominik Vogt <[email-masked]>
Date: Sun, 11 Aug 2002 22:24:53 +0200

On Sun, Aug 11, 2002 at 01:59:08PM -0400, Bob Woodside wrote:
> 	Still doesn't work.

Fixed.

> However, I notice that MouseFocusClickRaises causes the

Yes.  I want to merge the MouseFocusClickRaises and
ClickToFocusRaises options into a single one.  Currently MFCR
activates raising on the client window only and CtFR activates it
on the client window and the decorations.  There is no clean way
to support the old way with separate options easily.  This is
because there is not distinction between all the focus policies
anymore - they are just a set of low level options.

Anyway, should be fixed now.

> > 	suddenly start working that formerly didn't, and others mysteriously to

I have cleaned up this mess.  The four basic focus policies should
override each other completely.

> > 	see it happening with sylpheed, which is Gtk).

Fixed.

Overall, 80% of the bugs are just the wrong default settings.  We
haven't found much problems in the logic itself yet.  By the way,
is the obnoxious xfm/doubleclick problem gone?  I don't have the
proper xfm version to test this.  All the decisions about grabbing
are centralised in focus.c.  So even if it's still there, a fix
will probably be very easy (just calling one of the focus_grab_...
functions at the right place).

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: Bob Woodside <[email-masked]>
Date: Sun, 11 Aug 2002 23:43:52 -0400

On Sun, 11 Aug 2002 22:24:53 +0200
Dominik Vogt <[email-masked]> wrote:

> ClickToFocusRaises options into a single one. 

	This sounds good to me. I think the only reason we had them separate before was
that they predated the GSFR and had to be global options. The new way looks much
cleaner.

> Currently MFCR activates raising on the client window only and CtFR activates
> it on the client window and the decorations.

	I've never really understood why CTF was hard-coded to raise on decoration
clicks (I depend on mouse bindings on the decoration pieces for various
functions, regardless of focus policy) - I suppose the reason's lost in the
mists of prehistory.

>                                                                   By the way,

	No, it's still with us. I'll send you a little test program -- I'd have to
search through some CD archives to find a version of xfm or moxfm that shows the
problem, since my workaround hack was folded into the production releases of
both of them about a year ago.

Cheers,
Bob