Subject: to do for 2.4 (update 7)

From: Dominik Vogt <[email-masked]>
Date: Sun, 27 Jun 1999 03:58:08 +0200

In progress:

 1) Document the GNOME stuff (man page still missing).
    [in progress; volunteers still needed]
 2) Add screen shots to web page.
    [in progress; Dan]
 9) Set up RPM packages.
    [in progress; Jason]
 15) Get restart straight (sometimes an application vanishes over restarts)
     [in progress; Mikhael, Matthias]
 19) Try to reproduce that KFM windows stay on top of normal fvwm windows.
     [reported by Andrew Morton <[email-masked]> on 16-May-1999]
     [may be the same as 22/bug #290]
     [in progress; Matthias, Dominik]
 22) Investigate bug #290. (windows cannot be raised over others sometimes).
     [mail thread from April; confirmed by me (Dominik)]
     [in progress; Matthias, Dominik]

To do (must):

 7) Create an I18N fvwm package (from 2.2 or so).

To do (optional)

 10) Remove 'PopupAsRootMenu' menu style (?).
     [comments wanted]
 11) Add FvwmKb module?
     [comments wanted]
 12) Set up bzip2 tarballs.

Fixes (high priority):

 14) Figure out what the problem with Amaya is.
     [reported on 3-Jun-1999 by Rob Urban <[email-masked]>]
 16) Try to fix the 'netscape stuck on page' problem.
     [reported on 17-May-1999 by <[email-masked]>]
 17) Fix the bug that causes icons to lose management (bug #352).
 26) Investigate bug #315. (Recapture doesn't work perfectly for changing the
     default decor).
 41) Fix hanging fvwm when moving GNOME menu bars (bug #395).
     [confirmed by me (Dominik)]
 42) Get bitmap icons working again.

Fixes (optional):

 31) 'Maximize grow grow' works only on the current page.
     [reported by me (Dominik)]
 32) Several applications are reported to not resize well under fvwm
     (Datek's "Streamer", CodeWarrior).

Testing:

 33) Test the GNOME patches.
 34) Run the purify script again (and update it).
 35) Test the strokes patch.
 36) Test the new menu styles (ItemFormat!)
 
=====

Done:

 3) Add link to fvwm cats page to web page.
 4) Add link to Mikhael' wm-icons page.
 5) Update the links on our home page.
 6) Remove several configure options.
 8) Add an explanation about the various packages and where to
    discuss them to the web page.
    (stable, unstable (alpha), snapshots, ftp source tree, CVS).
 13) Use a 'busy' pointer during startup.
 18) Check if there are still growing windows as reported for 2.13.
     [bug #184 reported by Michael Hughes <[email-masked]>]
     [no bug; doesn't happen for 2.2 and up]
 20) Check why no icon can be set for Eterm.
     [reported on 8-May-1999 by Amir Chossrow Akhavan <[email-masked]>]
     [no fix? or should we rather break 'xterm +ai'?]
 21) Fix the bug with eterm and transparent background (I think rxvt has
     the same problem.
     [Eterm bug fixed, rxvt doesn't work very well with transparent
     background. I've reported to the rxvt mailing list]
 23) Check if bug #312 is still there.
     [fixed]
 24) Investigate bug #314.
     [fixed]
 25) Investigate dying pager on desk-to-desk transfers (bug #358 et al.)
     [fixed; only in 2.2.2, caused by missing X error handler]
 27) Check if bug #334 is still a problem.
     [fixed]
 28) Investigate FvemEvent core dumps.
     [fixed in 2.2.3, no bug in 2.3.4]
 29) Fix the pager bugs I reported recently.
 30) Fix the broken size hints of FvwmWinList (in fvwm itself).
 37) Fix interaction of moving with autoraising icon titles.
     [fixed]
 38) Investigate bug #389. (StartsOnDesk does not work)
     [configuration problem, added a warning to the code]
 39) Investigate bug #390
     [fixed]
 40) Investigate bug #394. (Overlapping pages)
     [no bug; doesn't happen after a recompile]
 43) Several pager bugs (bug #379).
     [fixed]
 44) Fix TaskBar crash caused by latest patch in RemoveButton().
     [fixed]

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://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]

----- End forwarded message -----

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]

----- End forwarded message -----

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]

----- End forwarded message -----

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]

----- End forwarded message -----

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]

----- End forwarded message -----

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: Mon, 28 Jun 1999 23:53:27 +0200

>  41) Fix hanging fvwm when moving GNOME menu bars (bug #395).

The problem can be reproduced with the following instructions:

 1) Start e.g. gnome-terminal or any other GNOME app with a
    menu bar. If necessary switch the menu bar on first. It
    may or may not start anchored to the app (this seems to
    be caused by the GNOME menu bar design; I have reported
    it to the GNOME folks).
 2) Grab the move button on the left side of the menu bar
    (it may not be drawn properly, but it still works) and
    drag the menu bar out of the app window. (Don't use
    fvwm to drag it).
 3) Drag the menu bar back into its place in the app.

==> X hangs for several seconds before the menu bar snaps into
    place.

Fvwm hangs in one of the calls handling the X input queue. I
have seen it hang in My_XNextEvent, SetupFrame or DoSetFocus.
In DoSetFocus I could narrow it down to the XSync(dpy,0) at
the end of the function. I don't know enough about X event
handling to figure out what happens. Please help.

Bye

Dominik ^_^

---

From: Matthias Clasen <[email-masked]>
Date: Tue, 29 Jun 1999 12:11:27 +0200

> handling to figure out what happens. Please help.

I just tried to start gnome-terminal under Xnest and twm to see
if the same problem happens for other wms, but: 

bash$ Xnest :1 &
[1] 6329
bash$ twm -display :1 &
[2] 6330
bash$ gnome-terminal --display :1 &
[3] 6331
bash$ X Error of failed request:  BadDrawable (invalid Pixmap or Window parameter)
  Major opcode of failed request:  62 (X_CopyArea)
  Resource id in failed request:  0x0
  Serial number of failed request:  1175
  Current serial number in output stream:  1183
X connection to :1.0 broken (explicit kill or server shutdown).
xterm:  fatal IO error 32 (Datenübergabe unterbrochen (broken pipe)) or KillClient on X server ":1.

The same happens for gedit. Is this a Xnest limitation or a gtk bug ?
I have repeated the experiment using an X server on a different console
and found that twm doesn't have the problem. 

-- 
Matthias Clasen, 
Tel. 0761/203-5606
Email: [email-masked]
Mathematisches Institut, Albert-Ludwigs-Universitaet Freiburg
--
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, 29 Jun 1999 11:18:05 +0100

> and found that twm doesn't have the problem.

I don't know if this is related but I have had problems with Imlib with
a server with odd visual depths.  I had to edit imrc to tell it what
visual to select in the end.  Does you Xnest have visuals of different
depths?

Cheers,
Tim.

---

From: Matthias Clasen <[email-masked]>
Date: Tue, 29 Jun 1999 12:25:40 +0200

> visual to select in the end.  Does you Xnest have visuals of different

They are the same depth (both 16, TrueColor), but have different id's 
(0x20 vs. 0x22)

Matthias

---

From: Matthias Clasen <[email-masked]>
Date: Tue, 29 Jun 1999 13:16:33 +0200

> handling to figure out what happens. Please help.

I found fvwm hanging in 

(gdb) bt
#0  0x40197861 in __libc_nanosleep ()
#1  0x401b1fc0 in usleep (useconds=1000)
    at ../sysdeps/unix/sysv/linux/usleep.c:30
#2  0x806b7df in GrabEm (cursor=5) at misc.c:584
#3  0x806b9b0 in HandleHardFocus (t=0x80c7a68) at misc.c:687
#4  0x806ae55 in Destroy (Tmp_win=0x80c7d40) at misc.c:142
#5  0x805a22f in HandleUnmapNotify () at events.c:1166
#6  0x8058f1d in DispatchEvent (preserve_Tmp_win=0) at events.c:205
#7  0x8058f5d in HandleEvents () at events.c:239
#8  0x805daed in main (argc=1, argv=0xbffff854) at fvwm.c:650
#9  0x40120cb3 in __libc_start_main (main=0x805cba0 <main>, argc=1,
    argv=0xbffff854, init=0x804ad20 <_init>, fini=0x807b4fc <_fini>,
    rtld_fini=0x4000a350 <_dl_fini>, stack_end=0xbffff84c)
    at ../sysdeps/generic/libc-start.c:78

The reason for the hang seems to be that GnomeDock has the pointer grabbed
(since they are doing the move themselves), and doesn't release it before
the docking is over. fvwm insists on grabbing the pointer in GrabEm:

  while((i<1000)&&(val=XGrabPointer(dpy, Scr.Root, True, mask,
				    GrabModeAsync, GrabModeAsync, Scr.Root,
				    Scr.FvwmCursors[cursor], CurrentTime)!=
		   GrabSuccess))
    {
      i++;
      /* If you go too fast, other windows may not get a change to release
       * any grab that they have. */
      usleep(1000);
    }

but the only reason for using GrabEm in the first place is that
HandleHardFocus has a stupid way of getting a new timestamp. This
should be replaced by something better and it shouldn't use
GrabEm.

Matthias

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 29 Jun 1999 14:30:28 +0200

> should be replaced by something better and it shouldn't use

But I saw it hanging in a plain XSync(dpy,0) too (in the end X hung in
a select() call). That could be caused by the pointer grab too (I
think), but it isn't our fault. Right?

Bye

Dominik ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 29 Jun 1999 14:57:02 +0200

> should be replaced by something better and it shouldn't use

Hm, yes. Commenting out the timestamp stuff in HandleHardFocus solves
the problem. Isn't there a way to simply request the current time from
the X server and patch it into the event structure (no, I don't have
that X books here at work)?

Bye

Dominik ^_^

---

From: Matthias Clasen <[email-masked]>
Date: Tue, 29 Jun 1999 22:12:11 +0200

Look at icccm2.c for a different way to get an up-to-date timestamp.
I think I used a zero-length append to a property.

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 29 Jun 1999 21:30:12 +0200

> should be replaced by something better and it shouldn't use

I wonder what HandleHardFocus() is good for anyway. It doesn't
seem to hurt to replace it with SetFocus(). Does anybody know
the intention behind this function?

Bye

Dominik ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 30 Jun 1999 11:53:11 +0200

> I think I used a zero-length append to a property.

I think HandleHardFocus needs the new timestamp only to ensure that
the focus is set on the new tick. But I can't see a reason why this
cannot be done immediately. I have disabled Handle HardFocus for now,
so if anyone sees a problem with the focus or something related,
please tell me.

HandleHardFocus is called only when destroying or unmapping windows
with ClickToFocus or when destroying transients.

Bye

Dominik ^_^