Subject: FVWM: Re: FVWM-2 WindowList

From: Scary Guy <[email-masked]>
Date: Tue, 11 Jun 1996 23:20:52 -0400 (EDT)

> Hi,
> On Fri, 7 Jun 1996 [email-masked] wrote:
>>>>>>> "Scary" == Scary Guy <[email-masked]> writes:
>>> Well, the funny thing I noticed is that when you actually 
>>> click on the windows, they get reordered in the WindowList, 
>>> whereas if you just select the window in the WindowList itself, they
>>> don't.  I myself am not a programmer extraordinaire, but it
>>> seems as if this could be changed relatively easily.  (That's
>>> why I posted this question in the first place.)

>> I just tried that, and observed that behavior as well.  It is a bug 
>> by my way of thinking, although I'll have to look a little harder to
>> figure out what's really wrong.  It probably won't be fixed in the
>> next beta or the first offical release, but I'll see what I can do
>> (i.e. it'll make it to the TO-DO list as a bug).

> That behaviour seems to be caused by the SetFocus() call with the 3rd 
> parameter as zero in FocusOn(), builtins.c.

> The SetFocus function moves the focused window to the top of the list
> only if the 3rd parameter is set to True, apparently for click-to-
> focus operations only (is not very clear to me why only in that case, 
> do we really need that 3rd parameter?). 
 
> The following patch corrects the problem, for both the WindowList menu
> and SloppyFocus prev/next.
 
> --- builtins.c.orig     Sat Jun  8 11:15:06 1996
> +++ builtins.c  Sat Jun  8 11:15:28 1996
> @@ -211,7 +211,7 @@
>        XWarpPointer(dpy, None, Scr.Root, 0, 0, 0, 0, 2,2);
>    }
>    UngrabEm();
> -  SetFocus(t->w,t,0);
> +  SetFocus(t->w,t,1);
>  }

I just tried making the necessary changes to builtins.c in the fvwm-95
source code (2.0.42) and this did not fix the problem.

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

---

From: Hector Peraza <[email-masked]>
Date: Wed, 12 Jun 1996 10:39:25 +0200 (MET DST)

> source code (2.0.42) and this did not fix the problem.

Strange, because I tested the changes in fvwm-95 first, then in fvwm-2.0.42
and they work exactly the same way. I'll mail you the patch for fvwm-95.

I have noticed, however, a problem with the above patch while using the
'Prev [*] Focus' command, as a result of moving the focused window to the
top of the list. For example, if you focused on A, B and C windows (in
that order), the first time you use Prev will move you to B, the next time
to C, then B, then C... Of course, that is not the desired behaviour (even
when 'Prev [*] Focus' means exactly that!!). 

Cheers,
Hector.

---

From: James Elson <[email-masked]>
Date: Wed, 12 Jun 1996 13:09:24 +0100

> when 'Prev [*] Focus' means exactly that!!).

When I am using Prev, I expect it to go backwards through the "focus 
history". However, if I've used it to go from C to B (as in your example), 
and worked in B for a while, I would then expect to go back to C. If I'd 
used Prev twice in quick succession (e.g. less than half a second between 
uses), I'd expect to end up at A.

Perhaps fvwm should have some sort of FocusTimeDelay field to implement this 
behaviour. This delay would be the length of time a window must have focus 
before it's raised to the top of the "focus history". This would also cover 
the problem of moving your mouse accross from one side of your window to the 
other in MouseFocus mode. Alternatively, applications only get raised in the 
history when they receive input (either via mouse click or key press).

What do you think?

		James