Subject: to do for 2.4 (update 8)

From: Dominik Vogt <[email-masked]>
Date: Tue, 29 Jun 1999 00:11:48 +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]
 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]
 41) Fix hanging fvwm when moving GNOME menu bars (bug #395).
     [in progress; Dominik]

To do (must):

 7) Create an I18N fvwm package (from 2.2 or so).
 45) Remove the web pages from the distribution.

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).

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).
 46) Titlebars should not inherit the pixmap from the border style.

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.
 15) Get restart straight (sometimes an application vanishes over restarts)
     [fixed]
 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]
 42) Get bitmap icons working again.
     {fixed]
 43) Several pager bugs (bug #379).
     [fixed]
 44) Fix TaskBar crash caused by latest patch in RemoveButton().
     [fixed]

Bye

Dominik ^_^
--
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: [email-masked] (Paul D. Smith)
Date: 29 Jun 1999 01:23:38 -0400

Dominik fixed the problem I had with the Recapture iconify-and-compact
function Tim suggested, where every new window appears iconified once
you use that function the first time.

However, the other strange effects I saw are still there :-/.  I haven't
updated FVWM in a couple of days; I'll do so first thing tomorrow and
let you know if I still see these, but I wanted to raise them here:

First, note that I can reproduce these only with Emacs (I'm using GNU
Emacs 20.3).  I couldn't reproduce it with xterm or rxvt, and it doesn't
seem to happen with Netscape.

 1) Shuffling window :(.  Any Emacs frame with a negative geometry that
    is iconified when the recapture command in that function is invoked,
    will be offset some number of bytes to the left when you de-iconify
    it.  For example, if I say:

      $ emacs -geometry -0+80

    then I see the problem.  If I use +0+80, it doesn't happen.  These
    seems to only happen once, but if you kill the frame and recreated
    it, then iconify, then recapture, it happens for the new frame
    again.

 2) Frames don't deiconify properly.  I have keys in Emacs that
    automatically deiconify and raise frames.  After that function runs,
    if I use one of these keys, I get FvwmAnimate animation of the frame
    opening and the icon disappears.  However, it opens _behind_ all the
    other windows.  If I send the things in front of it to the back, I
    can see the frame but it never will take focus and doesn't contain
    the right contents.

    If I hit the key again, the icon will briefly flash into existence
    and disappear again, then the FvwmAnimate graphics will run again,
    then the frame will appear completely and work properly.  I've never
    had it fail to do this on the second attempt.

    If I use the mouse (click mouse-2) to deiconify, it works every
    time.

    Note I use autoraise, and this might be involved: it seems much more
    likely to happen if there's the possibility of contention beween
    which frame should be raised (e.g., if I iconify a frame then
    de-iconify another one quickly in succession).

    I'll try to quantify this one better tomorrow.

-- 
-------------------------------------------------------------------------------
 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://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: [email-masked] (Paul D. Smith)
Date: 29 Jun 1999 10:04:46 -0400

I can confirm both these behaviors with the very latest CVS stuff :(

Also, I'm doubtful now that the second problem is related to autoraise;
it seems to happen even when you wouldn't expect autoraise to come into
play.

I still haven't been able to get either one to happen except with
Emacs.  I wonder if this is an Emacs bug?  I've also only tried on my
Solaris system (but note I'm using X11R6.3, and not OpenWin or CDE) and
only with Emacs 20.3.

Does anyone else see this?

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 30 Jun 1999 02:27:51 +0200

>     it, then iconify, then recapture, it happens for the new frame

Yes, I see that too (only with Emacs, not XEmacs). But it has nothing to
do with iconifying. What happens is this:

When emacs is mapped first, it sets this normal hints:

 x        408
 width    740
 gravity   NE

And

 border width 2

Let's assume fvwm uses a border width of 9. Then the frame window starts
2 * (9 - 2) = 14 pixels left from the original position, at x = 394 (the
old window border is removed and a new one is drawn within the frame).
But when emacs is mapped, it notices its new position and sets new normal
hints:

 x        401 <--
 width    740
 gravity   NW <--

This truly reflects the current client window location (which is
located at x = 403). Emacs wants to be clever but does not take the
WMs border width into account. Then we recapture the window and
the new frame is placed at 401 as requested (note that the gravity
has changed!). So the client portion of the frame begins at
401 + 9 = 410 which is (9 - 2) = 7 pixels too far right.

At this point I stopped debugging since it's clear now that emacs
is broken. THe is another effect that doubles the mis-placement so
that emacs ends up 14 pixels too far to the right.

I have reported this to the emacs people.

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: [email-masked] (Paul D. Smith)
Date: 30 Jun 1999 13:00:10 -0400

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

  dv> Yes, I see that too (only with Emacs, not XEmacs). But it has
  dv> nothing to do with iconifying. What happens is this:

Well, it appears to only be a problem when iconified Emacs frames are
recaptured... so in that sense it has to do with iconifying :).  But I
take your point.

  dv> At this point I stopped debugging since it's clear now that emacs
  dv> is broken. THe is another effect that doubles the mis-placement so
  dv> that emacs ends up 14 pixels too far to the right.

  dv> I have reported this to the emacs people.

OK, maybe I'll check the latest Emacs 20.4 beta and see if it's fixed.
It's really too bad they don't have anyone who knows much about X,
window managers, ICCCM, etc. on their development team :(.

What about the other problem, with frames not de-iconifying correctly
the first time after a recapture?  Has anyone seen that?  It's pretty
easy to reproduce, for me.

Since it also only happens for Emacs frames it could well be an Emacs
problem, as well, but it's at least more subtle...

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 1 Jul 1999 01:48:03 +0200

> problem, as well, but it's at least more subtle...

You said you would elaborate on this and I was hoping for more
information before trying to reproduce it again.

Bye

Dominik ^_^

---

From: [email-masked] (Paul D. Smith)
Date: 30 Jun 1999 22:32:51 -0400

dv> You said you would elaborate on this and I was hoping for more
  dv> information before trying to reproduce it again.

Sorry; I made another post that elaborated more but maybe I wasn't
clear.

I've done some more testing, this time on my Linux box at home, and it's
trivial for me to reproduce.

Start an Emacs 20.3 in X mode.  Use C-x 5 2 to create a new frame.
Iconify the new frame.

Now run the Iconify-and-Compact function:

  AddToFunc Iconify-and-Compact
  +       "C" Iconify
  +       "C" All (CurrentDesk Iconic) RecaptureWindow

Note!  A normal "Recapture" command works OK!  You need to use (I
suppose) RecaptureWindow.

Now if you deiconify the Emacs frame with the mouse, it works OK.  But,
if you use the Buffers->Frames menu to pick it and have Emacs deiconify
it instead, it doesn't work (the first time).

When I do it, the frame appears (along with FvwmAnimate animation) and
the icon disappears.  However, _only_ the frame appears, the contents of
the frame are never mapped.  Further, I can't give this frame focus or
bring it to the front.  I can, though, resize it and move it via the
border; the interior of the frame is just a copy of whatever was on the
screen when it was created.

If I use the Buffers menu to ask for the frame _again_, the icon briefly
appears, the deiconify animation appears, _then_ the frame contents are
mapped correctly and the frame works fine.  You can iconify this frame
again and again and observe exactly the same behavior.  It's not until
you actually delete the frame (with C-x 5 0 or whatever) that it will
stop.

I just had another odd thing happen; after a recapture I couldn't send
my Emacs frame to the back anymore.  I'll try to clarify this one.