Subject: FvwmWinList still buggy ?

From: Matthias Clasen <[email-masked]>
Date: Fri, 5 Feb 1999 23:47:19 +0100

Sorry, I haven't followed the discussion
about FvwmWinList problems on this list,
but I am experiencing the following problems
with FvwmWinList and fvwm2.1.11: 
FvwmWinList clicking on an item to transfer focus
  does transfer the focus, but doesn't depress the
  item. To be more precise, the button depressing is
  lagging behind the focus change; if the button of
  win1 is depressed, I can press the button of win2
  to transfer the focus to win2 (while the first button
  is still depressed). Pressing the button of win3
  moves the focus to win3, but depresses the button 
  of win2.

  Also, if I have multiple nxterm windows, then moving
  the focus from one to the other (by moving the mouse
  over them) will sometimes not change the depressed
  items. The button of the second nxterm flashes, but
  the depressed state "jumps back" to the first nxterm.
   
This is with a fairly standard RedHat 5.1 setup.

-- 
Matthias Clasen, 
Tel. 0761/203-5606
Email: [email-masked]
Mathematisches Institut, Albert-Ludwigs-Universitaet Freiburg
--
Visit the official FVWM web page at <URL:http://fvwm.math.uh.edu/>.
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: Brad Giaccio <[email-masked]>
Date: Mon, 8 Feb 1999 08:10:43 -0500

> This is with a fairly standard RedHat 5.1 setup.

This looks like it it might be related to my problem as well, It seems
like the current cvs for FvwmWinList is always waiting for focus change
events to update itself.  Did anyone put a change like this in?

Brad
 
-- 
--- There are two kinds of knowledge, you either know the answer or
			you know where to find it
		      -Kane, Johnson, and anonymous
--
Visit the official FVWM web page at <URL:http://fvwm.math.uh.edu/>.
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: Wed, 10 Feb 1999 10:55:00 +0000

> events to update itself.  Did anyone put a change like this in?

The change went in for 2.1.9.  The event loop was rewritten and it needs
an XPending() before the select call.  There was a discussion (see
http://www.hpc.uh.edu/fvwm/archive/9901/msg00972.html and follow-ups) I
don't think the patch Chris posted ever got committed.

Cheers,
Tim.

---

From: [email-masked] (Paul D. Smith)
Date: 10 Feb 1999 08:44:59 -0500

%% Tim Phipps <[email-masked]> writes:

  >> events to update itself.  Did anyone put a change like this in?

  tp> The change went in for 2.1.9.  The event loop was rewritten and it
  tp> needs an XPending() before the select call.  There was a
  tp> discussion (see
  tp> http://www.hpc.uh.edu/fvwm/archive/9901/msg00972.html and
  tp> follow-ups) I don't think the patch Chris posted ever got
  tp> committed.

!?!?

I thought the main point of the 2.1.11 respin was to include the winlist
fixes; we had a 3-4 day window where important bugs were supposed to be
committed; did we drop the ball and forget one?  Did we forget more than
one (*cringe*)?  Am I out-to-lunch?

At any rate, it looks like there's no avoiding a 2.1.12, if we can
figure out these problems.  I vote that _if_ we're making a 2.1.12
anyway, Bob's icontitle fix goes in, and the fix for mono displays (at
least the change we've got now, which doesn't seem to do exactly what
the old code did but it's better than nothing).  We should probably wait
and see if we can't crush the @#$%&* keybinding issue once and for all;
if Lee and Dominik (and anyone else) can work out what's going on.

The other option is to spin 2.2.0 essentially as-is, and dedicate
ourselves to a 2.2.1 followup with these bugs fixed.

Thoughts?

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <[email-masked]>         Network Management Development
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.
--
Visit the official FVWM web page at <URL:http://fvwm.math.uh.edu/>.
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: Wed, 10 Feb 1999 15:01:56 +0100

On Wed, Feb 10, 1999 at 08:44:59AM -0500, Paul Smith wrote:
> the old code did but it's better than nothing).

I agree.

>  We should probably wait

Please, I need help on this key binding problem. I can't see where the
bug lies. Could anybody else have a look at the changes in bindings.c
betweed 2.1.5 and 2.1.6?

> ourselves to a 2.2.1 followup with these bugs fixed.

I'm no friend of this one. If we have critical problems we should
do them right the first time.

Bye

Dominik

-- 
Dominik Vogt, Hewlett-Packard GmbH, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/14-4596, fax: 07031/14-3883, [email-masked]
--
Visit the official FVWM web page at <URL:http://fvwm.math.uh.edu/>.
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: Wed, 10 Feb 1999 14:03:56 +0000

> one (*cringe*)?  Am I out-to-lunch?

I think there were two bugs And we only fixed the core dump, I'm a
guilty as anyone of not checking, I thought we had done both.

> ourselves to a 2.2.1 followup with these bugs fixed.
I'd vote for doing 2.2 now. It's never going to be bug free and the
longer we wait the more bug fixes and patches back up.  Fvwm itself is
looking pretty stable.

Cheers,
Tim.

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 10 Feb 1999 15:23:00 +0100

> longer we wait the more bug fixes and patches back up.  Fvwm itself is

I'd vote for a 2.1.12. There is one problem with 2.2.0/2.2.1: It wouldn't
help to reduce the queued up patches. When we do 2.2 we'll be in the
same situation as we are now. Nobody can work on 2.3.x until the patches
that have to go into 2.2.1 are in. Or would anybody want to work on
2.2.1 and 2.3.x in parallel (I wouldn't)?

Thoughts?

Bye

Dominik

---

From: Dan Espen <[email-masked]>
Date: Wed, 10 Feb 1999 11:08:31 -0500

> 2.2.1 and 2.3.x in parallel (I wouldn't)?

I thought we should ignore the icons on top problem for 2.2, but
the WindowList stuff is pretty bad.  I don't normally use the window
list, but after having it up for a while, it just doesn't seem to know
which window has focus.  If I was using it, I wouldn't be happy.

Anyone like this idea:

Fix the black and white problem, fix the window list problem,
and fix the icons on top problem, test this from CVS and if OK,
release as 2.2?  (In other words, do our final testing just
within the workers list?)

--
Dan Espen
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854                     Phone: (732) 699-5570
--
Visit the official FVWM web page at <URL:http://fvwm.math.uh.edu/>.
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: Wed, 10 Feb 1999 18:41:49 +0100

> within the workers list?)

Drats, I just noticed that my fix for the Direction coredump
didn't make it to the list. This one is really serious too.
I'll repost it when I'm back home. It fixes a number of
actual and possible coredumps.

Bye

Dominik

---

From: [email-masked] (Paul D. Smith)
Date: 10 Feb 1999 13:11:18 -0500

%% Dan Espen <[email-masked]> writes:

  de> I thought we should ignore the icons on top problem for 2.2, but
  de> the WindowList stuff is pretty bad.  I don't normally use the
  de> window list, but after having it up for a while, it just doesn't
  de> seem to know which window has focus.  If I was using it, I
  de> wouldn't be happy.

I agree: I don't use it either but from what I've seen _many_ people do,
and this is a very serious problem.

  de> Fix the black and white problem, fix the window list problem,
  de> and fix the icons on top problem, test this from CVS and if OK,
  de> release as 2.2?  (In other words, do our final testing just
  de> within the workers list?)

I'd agree with this.

I'm still concerned about the keybinding issue; I'd say hold out for
that except we don't seem to have any good ideas and we can't even
reliably reproduce it (although at least now someone can who's willing
to work with us on it--thanks Lee! :).

Can someone enter a bug or pick an existing bug (surely there is one?)
to be the "master bug" for these keybinding problems, and add notes
describing what we know so far?

E.g., a change to builtins.c between 2.1.5 and 2.1.6 caused the problem.
A precise description of the problem, and any odd things about it (does
restart cure it, etc.?)  Can we come up with a very, very minimal
.fvwm2rc that exhibits the problem on at least someone's (Lee's) system
and attach that?

If we don't come up with something soon, since it's not reliably
reproducible, I say don't bother with this one; we'll work on it
post-2.2.0.  Surely there will more bugs to be fixed necessitating a
2.2.1 anyway :)

---

From: Brad Giaccio <[email-masked]>
Date: Wed, 10 Feb 1999 14:18:08 -0500

Dominik,
I took a look at bindings.c and nothing jumps out at me. The
real difference to the file between 2.1.5 and 2.1.6 is in
ParseBindEntry. Maybe you could try explaining to us the rational for
the changes and maybe that would help us spot the problem.

Brad

2.1.5
   if (fKey)
   {
     button = XKeysymToKeycode(dpy, keysym);
     if (button == 0)
       return;
   }
 
   temp = Scr.AllBindings;
   Scr.AllBindings = (Binding *)safemalloc(sizeof(Binding));
   Scr.AllBindings->IsMouse = (fKey)? 0 : 1;
   Scr.AllBindings->Button_Key = button;
   Scr.AllBindings->key_name = (fKey) ? stripcpy(key) : NULL;
   Scr.AllBindings->Context = contexts;
   Scr.AllBindings->Modifier = mods;
   Scr.AllBindings->Action = stripcpy(action);
   Scr.AllBindings->NextBinding = temp;
 
2.1.6
  if (fKey)
    {
      XDisplayKeycodes(dpy, &min, &max);
    }
  else
    {
      min = button;
      max = button;
    }
  for (i=min; i<=max; i++)
    if (!fKey || XKeycodeToKeysym(dpy, i, 0) == keysym)
    {
      temp = Scr.AllBindings;
      Scr.AllBindings  = (Binding *)safemalloc(sizeof(Binding));
      Scr.AllBindings->IsMouse = !fKey;
      Scr.AllBindings->Button_Key = i;
      Scr.AllBindings->key_name = fKey ? stripcpy(key) : NULL;
      Scr.AllBindings->Context = contexts;
      Scr.AllBindings->Modifier = mods;
      Scr.AllBindings->Action = stripcpy(action);
      Scr.AllBindings->NextBinding = temp;
    }
--
Visit the official FVWM web page at <URL:http://fvwm.math.uh.edu/>.
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: Wed, 10 Feb 1999 19:43:47 +0100

> describing what we know so far?

I'll take charge of that (but probably not today).

> E.g., a change to builtins.c between 2.1.5 and 2.1.6 caused the problem.
                    ^^^^^^^^^^

Nope, it was bindings.c.

> .fvwm2rc that exhibits the problem on at least someone's (Lee's) system

I'm almost convinced that Lee is working with a Solaris/SunOS machine
(without asking him). These have always been the machines causing
trouble.

Bye

Dominik

--
Dominik Vogt, [email-masked]
Reply-To: [email-masked]

---

From: [email-masked] (Paul D. Smith)
Date: 10 Feb 1999 16:01:53 -0500

%% Dominik Vogt <[email-masked]> writes:

  dv> I'm almost convinced that Lee is working with a Solaris/SunOS
  dv> machine (without asking him). These have always been the machines
  dv> causing trouble.

I have access to both of these (in spades :), and with both Sun's
Openwindows version of X and TOG's "vanilla" version of X.

With a suitable description of the problem I can try to recreate it.

---

From: Dan Espen <[email-masked]>
Date: Wed, 10 Feb 1999 16:21:52 -0500

>       Scr.AllBindings->IsMouse = !fKey;

This used to be zero or one, it now has all kinds of interesting
values.  There are places where it is specifically tested for being
equal to 1.

>       Scr.AllBindings->NextBinding = temp;

I added this debug statement:

      fprintf(stderr,"IsMouse %d Button_key %d key_name %s Context %d Modifier %d Action %s\n",
              (Scr.AllBindings->IsMouse ? 0 : 1),
              Scr.AllBindings->Button_Key,
              (Scr.AllBindings->key_name
               ? Scr.AllBindings->key_name : "Noname"),
              Scr.AllBindings->Context,
              Scr.AllBindings->Modifier,
              Scr.AllBindings->Action);

There is a comment at the start of this:

  /*
  ** why wasn't XKeysymToKeycode used instead of this for loop?
  ** domivogt (18-Dec-1998): because multiple key can be bound to the same
  ** key symbol?
  */

I couldn't find any instance where one keysym was on more than 1 key.
Which key should I try?

---

From: [email-masked] (Paul D. Smith)
Date: 10 Feb 1999 16:47:40 -0500

>>    Scr.AllBindings->IsMouse = (fKey)? 0 : 1;

vs.

  >>    Scr.AllBindings->IsMouse = !fKey;

  de> This used to be zero or one, it now has all kinds of interesting
  de> values.

Why?  ! is a boolean operator in C, and boolean expressions always
evaluate to 0 or 1.

This looks the same as the previous code to me.

---

From: Dan Espen <[email-masked]>
Date: Wed, 10 Feb 1999 16:58:14 -0500

> This looks the same as the previous code to me.

Sorry, my brain slipped out of gear.  You are right of course.

> -- 
>  Paul D. Smith <[email-masked]>         Network Management Developmen

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 10 Feb 1999 23:41:19 +0100

> I couldn't find any instance where one keysym was on more than 1 key.

The first line of the comment was there before I touched the code.
I saw no reason not to use XKeysymToKeycode either so I rewrote this
part to use it (this was before 2.1.5). Then the bug reports about
key bindings not working started and finally I changed it back hoping
it would fix the problems. We didn't hear about that again. Then with
2.1.6 we got this new report that pinned it down to the diffs between
2.1.5 and 2.1.6. The situation described in the comment isn't very
likely I think.

Bye

Dominik