Subject: to do for 2.4 (update 28)

From: Dominik Vogt <[email-masked]>
Date: Mon, 3 Jan 2000 17:18:18 +0100

Items with highest priority / most severe problems:

103

New since last update:

none

Closed since last update:

100, 102

---------- Summary: ----------------------------------------------

 0 to be verified
 5 to do
 5 distribution issues
 9 testing
----------------------
19 open items
87 items done
106 items in total

---------- To be verified: ---------------------------------------

none

---------- To do: ------------------------------------------------

 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).
     [couldn't reproduce this yet; can anybody who has netcool
     event manager try it?]
 32) Several applications are reported to not resize well under fvwm
     (Datek's "Streamer", CodeWarrior).
     [optional]
103) Add recent bug reports to to-do list.

---------- Distribution issues: ----------------------------------

 9)  Set up RPM packages.
     [???; Jason?]
 12) Set up bzip2 tarballs.
     [optional]
 48) Finish Windoze 95 like config file.
     [stalled (90%), Olivier?]
 62) Write a new announcement.
     [in progress]
 90) Icon distribution.

---------- Testing: ----------------------------------------------

 33) Test the GNOME patches.
 34) Update and run the purify script again (and update it).
 35) Test the strokes patch.
 36) Test the new menu styles (ItemFormat!)
 92) Test new session management code.
 94) Test colour set support in modules and fvwm.
 95) Test new panel implementation in FvwmButtons.
105) Test binding code.
106) Test window position code.
 
========== Done: =================================================

 1)  Document the GNOME stuff (man page still missing).
 2)  Add screen shots to web page.
 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.
 7)  Create an I18N fvwm package (from 2.2 or so).
     [see #100]
 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).
 10) Remove 'PopupAsRootMenu' menu style (?).
     [rejected]
 11) Add FvwmKb module?
     [delayed until after 2.4]
 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]
 19) Fix: KFM windows stay on top of normal fvwm windows.
     [done]
 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]
 22) Investigate bug #290. (windows cannot be raised over others sometimes).
     [mail thread from April; confirmed by me (Dominik)]
     [fixed; there is a new style and the behaviour is a bit more intuitive]
 23) Check if bug #312 is still there.
 24) Investigate bug #314.
 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]
 26) Investigate bug #315. (Recapture doesn't work perfectly for changing the
     default decor).
     [mainly a documentation problem; man page was updated]
 27) Check if bug #334 is still a problem.
 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).
 31) 'Maximize grow grow' works only on the current page.
 37) Fix interaction of moving with autoraising icon titles.
 38) Investigate bug #389. (StartsOnDesk does not work)
     [configuration problem, added a warning to the code]
 39) Investigate bug #390
 40) Investigate bug #394. (Overlapping pages)
     [no bug; doesn't happen after a recompile]
 41) Fix hanging fvwm when moving GNOME menu bars (bug #395).
 42) Get bitmap icons working again.
 43) Several pager bugs (bug #379).
 44) Fix TaskBar crash caused by latest patch in RemoveButton().
 45) Remove the web pages from the distribution.
 46) Titlebars should not inherit the pixmap from the border style.
 47) Verify the TaskBar clock update problem.
     [given up; I think I could reproduce the problem - it was a
     configuration mistake, but the reporter didn't care to answer
     if my suggestion helped; Dominik]
 49) Implement a 'H'old trigger for complex functions.
 50) Implement a 'ButtonGeometry' option for FvwmButtons.
 51) Fix constraining the window size when a window is maximized or
     larger than MaxWindowSize when mapped.
 52) Allow to resize in client resize increment steps.
 53) Decide what to do with overlapping moved icons.
     [will be ignored]
 54) Find a better solution for raising/lowering of transients.
 55) FvwmGtk can't be killed with 'KillModule'.
 56) Mini icons may overlap menu titles.
 57) Fix autohiding and TaskBar tips.
 58) DeskTopSize is not honoured upon a restart (the old one is reused).
     [use Restart --dont-preserve-state]
 59) Get Raise/Lower of transients straight.
     [duplicate of item 54]
 60) Make MaxWindowSize a style (don't release a command that will
     change anyway).
 61) Get SidecPics working again.
 63) Fix stacking order in pager.
 64) Install the new web pages.
 65) Fix "maximize true ..." when a window is already maximized.
 66) Fix ddd problems.
     [fixed as far as possible; bug reported to ddd list]
 67) Add a Windoze95 like screenshot to the web page.
 68) Investigate 'Xlib: sequence lost' message.
     [went away with a newer snapshot]
 69) Fix window moving. Several people have reported that moving windows
     is slow or the windows don't follow the pointer well. This is really
     a big problem.
 70) Fix resize. On one hand it's not nice that you can drag the window
     border off screen, on the other hand it doesn't hurt if the shadow
     of the border is not on screen.
 71) Fix drawing of window titles.
 72) Finish implementing colour sets for modules.
     [item split up]
 73) Remove 'panel' feature from FvwmButtons and re-implement it in a
     less disruptive way.
 74) To fix: icons are not preserved over a Quit - Start for fvwm
 75) Implement colour sets in FvwmWharf.
 76) Implement colour sets in FvwmTaskBar.
 77) Implement colour sets in menu styles.
 78) Implement colour sets in window styles.
     [only colours used yet]
 79) Implement colour sets in FvwmConsole?
     [rejected]
 80) Implement colour sets in FvwmScript
 81) Change the way in which fvwm 'posts' menus with a click.
 82) Introduce a 'transient' option for FvwmButtons. This is needed
     to replicate the old panel behaviour.
 83) Fix FvwmIconMan crashes introduced by colour set support(?)
     [doesn't happen anymore]
 84) Implement colour sets in FvwmBacker.
 85) Add 'geometry' panel option in FvwmButtons.
     I think it's not worth the effort because it's similarly
     complicated as the menu position hints if I want to do it right.
     I can't see an easy solution that does something useful fast.
     [future enhancement]
 86) Finish code for setting backgrounds of other applications with
     colour sets.
 87) Describe what to do for colour set support in the module docs.
 88) Investigate 'pager out of sync' problem
     [fixed]
 89) Make FvwmScript use the same visual as fvwm (prerequisite for 80)
 91) Fix Xpm version problem (bug #463).
 93) Finish 'CREATING PANELS' section in FvwmButtons man page.
 96) Make flat titlestyle work again.
 97) Rewrite FvwmTheme 'Colorset' syntax ala MenuStyle.
 98) Allow using colours from colour sets in fvwm commands.
 99) Make HilightColors command colour set aware.
100) Remove I18N patches since author seems to have lost interest
     in finishing the patch.
     [leave it in, started to rewrite patch in a better way]
101) Finish current work on style changes w/o recapture in a
     consistent way. This doesn't necessarily mean that the
     feature has to be complete before 2.4.
102) Patch 'UseDecor' and 'UseStyle' styles and various ...Style
     commands to apply without a recapture.
     [finished except UseStyle]
104) Fix FvwmCommandS core dumps on X server shutdown.

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: Olivier Chapuis <[email-masked]>
Date: Tue, 04 Jan 2000 07:34:23 +0100

>      [stalled (90%), Olivier?]

Ok, Olivier

---

From: Dan Espen <[email-masked]>
Date: Wed, 05 Jan 2000 14:59:13 -0500

> Items with highest priority / most severe problems:

I  don't know if this problem  ever truly went away,  but if I quit
fvwm, and reenter,   windows  loose their position   and iconification
status.

You should be able to reproduce this by  invoking fvwm in a do forever
loop.  Create some windows, iconify some of them, move some others.
Then quit fvwm.  On reentry, things aren't where you left them.

--
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://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: "Paul D. Smith" <[email-masked]>
Date: 14 Jan 2000 16:10:53 -0500

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

  >> Items with highest priority / most severe problems:

  de> I  don't know if this problem  ever truly went away,  but if I quit
  de> fvwm, and reenter,   windows  loose their position   and iconification
  de> status.

  de> You should be able to reproduce this by  invoking fvwm in a do forever
  de> loop.  Create some windows, iconify some of them, move some others.
  de> Then quit fvwm.  On reentry, things aren't where you left them.

On thing I notice is that if I do a "make install" of new code, then
restart, a lot of my windows get shrunk to nothing.  Some get shrunk
only vertically (that is, they're still the same width but now have no
vertical dimension) and occasionally they'll not have any width either.

A normal restart doesn't do this.

One possibility, I guess: usually when I make install I don't save the
old binary; I just let the install overwrite it.  I wonder if the
restart breaks somehow if the old binary isn't there; for example, the
kernel tries to page in more of the exe and it's overwritten so it fails
somehow--I dunno, weird.  Seems very unlikely but I don't have a good
explanation.

I'll start mv'ing the old binary out of the way before installing a new
one and see if I still get that problem.

-- 
-------------------------------------------------------------------------------
 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: Dan Espen <[email-masked]>
Date: Fri, 14 Jan 2000 16:44:01 -0500

> one and see if I still get that problem.

Interesting.  The problem I described is not associated
with updating the binary, although I haven't carefully isolated
that factor, and my test just now was under Exceed.

Am I the only one that sees this problem?

---

From: Mikhael Goikhman <[email-masked]>
Date: Sat, 15 Jan 2000 15:36:29 +0200

> vertical dimension) and occasionally they'll not have any width either.

This is a right behaviour. :) I mean, when Dominik changes the window
flag structures or the fvwm state file format (he does this from time to
time), the new binary interprets the state file differently than the old
one (when it wrote it), so depending on what was changed you can get
interesting results with windows. There is no a state format versioning.

> A normal restart doesn't do this.

Just quit fvwm and start it again, you should never see the problem again.
For those who use a session manager the procedure is much more complex,
they should correct the windows themselves (probably by closing them)
and then save-session, quit-session (probably several times).

Let's hope that the flag structures and/or the fvwm state file format are
not changed in the stable releases or the versioning is needed.

Regards,
Mikhael.

---

From: "Paul D. Smith" <[email-masked]>
Date: 15 Jan 2000 16:07:42 -0500

%% Mikhael Goikhman <[email-masked]> writes:

  >> vertical dimension) and occasionally they'll not have any width either.

  mg> This is a right behaviour. :)

OK, no problem, as long as it's not a bug.

---

From: Dominik Vogt <[email-masked]>
Date: Sat, 15 Jan 2000 21:56:21 +0100

> fvwm, and reenter,   windows  loose their position   and iconification

Really?  I'm aware of the xemacs problem you reported a while ago,
but I can see nothing wrong with quit/start.  This all works
perfectly for me.

> Then quit fvwm.  On reentry, things aren't where you left them.

Can you provide more details or try debugging into it?

Bye

Dominik ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Sat, 15 Jan 2000 18:37:25 +0100

> not changed in the stable releases or the versioning is needed.

Why would this break anything?  I thought the state file is only
created when restarting and is deleted immediately after the
restart.  I can't imagine a normal user will reinstall fvwm
from within a running fvwm session.

Bye

Dominik ^_^

---

From: Mikhael Goikhman <[email-masked]>
Date: Sun, 16 Jan 2000 04:20:26 +0200

> from within a running fvwm session.

Huh? How a normal fvwm user is supposed to reinstall fvwm? Using another
wm or from outside X? :) I thought he does this in xterm.

And you forget session manager users (xsm, gnome-session). For them the
state file is permanent.

Regards,
Mikhael.

---

From: Dan Espen <[email-masked]>
Date: Sat, 15 Jan 2000 21:59:21 -0500

> but I can see nothing wrong with quit/start.  This all works

On a test just now, I had 2 xemacs frames, both initially created iconic,
I had one open, one iconic.  On restart, both were iconic.
One of the xemacs frames I moved, it remembered where I moved it to.

I had 2 rxvt windows, one created iconic, one created open.  On restart,
both were iconic.  One of the rxvt windows, I moved from its initial
position.  On restart, after deiconification, it was back in its original
location.

dclock and xbiff which I create open and never move, never give me
a problem.

> Can you provide more details or try debugging into it?

Some details are above.

I must be dumb.  Any hints as to where the code is that detects
the windows previous iconification status?  I'm looking at AddWindow()
and I just don't see it.

---

From: Dominik Vogt <[email-masked]>
Date: Sun, 16 Jan 2000 12:15:11 +0100

> wm or from outside X? :) I thought he does this in xterm.

Well, under Linux you can't overwrite the executable unless
you stop fvwm first.

> And you forget session manager users (xsm, gnome-session). For them the

I didn't know that.

Bye

Dominik ^_^

---

From: Ben Winslow <[email-masked]>
Date: Sun, 16 Jan 2000 08:37:33 -0500

> > > > not changed in the stable releases or the versioning is needed.
Well, versioning would be nice-- on the occasions the format of the file
does change, it's really annoying to resize all the windows...  Moving them
back to their respective desktops would be much easier.  However, perhaps
the versioning can be hacked together to simply determine which fields have
been changed, so only those fields can be ignored.

[snip]
> Well, under Linux you can't overwrite the executable unless
But you can rm the executable and then overwrite it (the file isn't actually
wiped from disk until the inode is no longer in use).  /bin/install does
this.

-- 
Ben Winslow           /   [email-masked]
bluecherry internet   /   http://www.bluecherry.net
|Rain| @ IRC          /   anynet: irc.anynet.org

---

From: Dominik Vogt <[email-masked]>
Date: Sun, 16 Jan 2000 17:28:06 +0100

> the windows previous iconification status?  I'm looking at AddWindow()

It's in event.c and fvwm.c I don't understand it completely
myself.  In the end it's signaled by the global flag
isIconicState that is set under certain circumstances in
fvwm.c.  On the other hand the "start me iconic" hint of
the app. has to be honoured too.  I think the whole trouble
comes from said isIconicState flag.  It's nigh impossible
to have it set correctly under all circumstances.  It has
to work with

 - normal windows
 - windows that asked to start iconic
 - windows that have the StartIconic style
 - windows that iconify themselves
 - windows that iconify their transients
 - restarting fvwm
 - restarting fvwm with session manager
 - recapture
 - quit and then start fvwm

And in theory (but I think that can't be done)

 - quit fvwm, run a different WM, start fvwm

I think the way to fix that is to throw away isIconicState
and come up with a solution that doesn't use global variables
but sets properties or hints on the window instead.

Bye

Dominik ^_^

---

From: Dan Espen <[email-masked]>
Date: Sun, 16 Jan 2000 11:58:00 -0500

> but sets properties or hints on the window instead.

Thanks, I'll see what I can see.

I believe all of this has been working fine, including exiting into
another window manager and coming back, up until sometime during
2.3.x.  The only new piece is the session manager.

I don't understand your comment about global variables,  I'm quitting
fvwm and then reentering it.  I really thought there must have been
some property set somewhere, but I've never been able to find it.

Maybe I'd better  check again,  and make sure  that  older versions of
fvwm work the way I think  they do.  (That  will probably have to wait
til Monday.)

---

From: Dominik Vogt <[email-masked]>
Date: Sun, 16 Jan 2000 18:54:49 +0100

> 2.3.x.  The only new piece is the session manager.

Perhaps you can remember there were several bugs with iconic
state in the past (e.g. ddd iconifying all windows on a recapture).
Every bugfix I made broke something else.  The current style of
code won't bring it to a point where everything works.

> some property set somewhere, but I've never been able to find it.

The global flag is initialised from the _XA_WM_STATE property,
but not always (e.g. not during a recapture). It's in
MappedNotOverride() in fvwm.c.  Start grep'ing for
isIconicState to get a feel of how tricky the current code is.

> fvwm work the way I think  they do.  (That  will probably have to wait

We're in no particular hurry.

Bye

Dominik ^_^

---

From: Dan Espen <[email-masked]>
Date: Tue, 18 Jan 2000 10:42:21 -0500

> but sets properties or hints on the window instead.

What I've found so far is that fvwm.c:MappedNotOverride() picks up the
correct iconic state, but when it gets to
events.c:HandleMapRequestKeepRaised()
it reads Tmp_win->wmhints->initial_state which contains IconicState
and iconifies the window.

And thats exactly the problem.  I created the window iconic,
then deiconified the window, and quit and restarted.

The deiconify sets the XA_WM_STATE to NormalState and saves it,
and MappedNotOverride reads it, but HandleMapRequestKeepRaised
goes after the initial state, not the last state.

HandleMapRequestKeepRaised appears to be unchanged from 2.2,
so I think something else has been removed or changed.

I wonder if 2.2 iconified the window and then proceeded to deiconify
the window during startup.  I remember I complained about all the
window painting an repainting during startup.

Anyway, still searching...

---

From: Dan Espen <[email-masked]>
Date: Sun, 23 Jan 2000 11:22:25 -0500

> Anyway, still searching...

In events.c around line 1073, this:

      if(isIconicState != DontCareState)
	state = isIconicState;

was changed to this:

      if(isIconicState == IconicState)
        state = IconicState;

changing    it back  fixes  the  problem   with windows loosing  their
iconification status.  (Note that both lines are different, its easy
to miss.)

I'm guessing this series of 4 fixes led to this change:

1999-11-22  Dominik Vogt  <[email-masked]>

	* fvwm/events.c (HandleMapRequestKeepRaised):
	* fvwm/fvwm.c (CaptureOneWindow):
	fixed fvwm forgetting iconic state over a restart; I must have been
	really confused when I wrote the 'bugfix' that caused this :)

1999-10-16  Dominik Vogt  <[email-masked]>

	* fvwm/fvwm.c (CaptureOneWindow):
	* fvwm/events.c (HandleMapRequestKeepRaised):
	* fvwm/icons.c (Iconify):
	Remember IS_ICONIFIED_BY_PARENT over a recapture

1999-07-08  Dominik Vogt  <[email-masked]>

	* fvwm/events.c (HandleMapRequestKeepRaised): fixed another problem
	with recapture/iconified emacs frames. Emacs sends two MapRequest
	events. The second iconifies the emacs frame again without removing
	the fvwm frame.

1999-06-24  Dominik Vogt  <[email-masked]>

	* fvwm/events.c (HandleMapRequestKeepRaised): fixed bug causing
	windows to always start iconic in conjunction with RecaptureWindow

I admit, I found the cause of the problem without understanding
the logic involved.  (Well OK, I know more now, than before.)

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 24 Jan 2000 14:24:59 +0100

> I'm guessing this series of 4 fixes led to this change:

...

Definitely.  But I didn't change anything for fun.  We need a
set of tests to make sure that iconification/restart/recapture
works properly.  Let's see ...

Yup, just as I suspected.  Try this:

  1) Start "ddd fvwm2"
  2) Go to "Edit" "Prferences" and select "Iconify all windows at once"
  3) Go to "Edit" "Prferences" "Startup" and select "Separate windows"
  4) Restart ddd if necessary
  5) Iconify ddd; all windows are iconified
  6) Deiconify ddd
  7) Restart fvwm

==>  All ddd windows start iconified.

I think this was the reason why I changed said code line.

Bye

Dominik ^_^

-- 
Dominik Vogt, Agilent Technologies, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/464-4596, fax: 07031/464-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]

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 24 Jan 2000 17:39:33 +0100

> I think this was the reason why I changed said code line.

Arg, ignore me!  Ddd is doing strange things:

  1) Set up ddd as described above.
  2) Start ddd. You whould have multiple windows now, e.g.
     the source and the command window.
  3) Use RecaptureWindow on the source window ==> the command
     window is iconified.
  4) Use RecaptureWindow on the command window ==> the source
     window is iconified.

Ddd must be requesting that the other windows are iconified
explicitly.  Strange.  

Bye

Dominik ^_^

---

From: Dan Espen <[email-masked]>
Date: Mon, 24 Jan 2000 12:49:27 -0500

> Ddd must be requesting that the other windows are iconified

I think I've seen other applications do that...not so strange.

BTW, looks like I missed a bunch of mail over the weekend, I never saw
the above mail.   Our admins were fooling   with our file  systems.  I
wonder what else I missed...

I think I understand the logic of the line of  code in question.  That
isIconicState global only  has the DontCareState  when we haven't  set
the XA_WM_STATE.   Once we set it, WM_STATE  records  the windows last
status and overrides anything else.

Lastly, I   agree with your previous  comment  about the  global being
pretty ugly, but for now, I think its OK.