Subject: to do for 2.4 (update 16)

From: Dominik Vogt <[email-masked]>
Date: Fri, 3 Sep 1999 00:50:09 +0200

Summary:
 4 in progress
 1 to be verified
 8 to do (must)
 7 to do (optional)
 3 fixes (high priority fix)
 2 fixes (optional fix)
 4 testing
----------------------------
29 open items
52 items done
----------------------------
81 items in total

In progress:

 9)  Set up RPM packages.
     [???; 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]
     [confiremd by me (Dominik)]
     [in progress?; Bob W.]
 48) Finish Windoze 95 like config file.
     [in progress (90%)]
 54) Find a better solution for raising/lowering of transients.
     [90%; Dominik]

To be verified:

 55) FvwmGtk can't be killed with 'KillModule'.
     [in progress; Dominik]

=====

To do (must):

 7)  Create an I18N fvwm package (from 2.2 or so).
 62) Write a new announcement.
 64) Install the new web pages.
     [Jason]
 74) To fix: icons are not preserved over a Quit - Start for fvwm
 75) Implement colour sets in FvwmWharf.
 76) Implement colour sets in FvwmWinList.
 77) Implement colour sets in menu styles.
 78) Implement colour sets in window styles.

To do (optional)

 10) Remove 'PopupAsRootMenu' menu style (?).
     [comments wanted]
 11) Add FvwmKb module?
     [comments wanted]
 12) Set up bzip2 tarballs.
 50) Implement a 'ButtonGeometry' option for FvwmButtons.
 79) Implement colour sets in FvwmConsole.
 80) Implement colour sets in FvwmScript?
 81) Change the way in which fvwm 'posts' menus with a click.

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

Fixes (optional):

 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:

 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.
 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]
 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.
     [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]
 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.
     [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).
 31) 'Maximize grow grow' works only on the current page.
     [fixed]
 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]
 41) Fix hanging fvwm when moving GNOME menu bars (bug #395).
     [fixed]
 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]
 45) Remove the web pages from the distribution.
     [fixed]
 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.
 51) Fix constraining the window size when a window is maximized or
     larger than MaxWindowSize when mapped.
     [fixed]
 52) Allow to resize in client resize increment steps.
 53) Decide what to do with overlapping moved icons.
     [will be ignored]
 56) Mini icons may overlap menu titles.
     [fixed]
 57) Fix autohiding and TaskBar tips.
     [fixed]
 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.
     [fixed]
 63) Fix stacking order in pager.
     [fixed]
 65) Fix "maximize true ..." when a window is already maximized.
     [fixed]
 66) Fix ddd problems.
     [fixed ans 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.
     [fixed]
 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.
     [fixed]
 71) Fix drawing of window titles.
     [fixed]
 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.

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: Mikhael Goikhman <[email-masked]>
Date: Fri, 3 Sep 1999 04:07:20 +0300 (IDT)

>  10) Remove 'PopupAsRootMenu' menu style (?).

I think it is a useful option. Probably I would not use it for normal
menus (although I remember one guy does), but I would rather use it for
special autogenerated menus (directory tree as an example), where you can
easily get 40 open menus on the screen. It is nice to be able to leave
only the last one, especially if you can always return to the parent
menu (like in: fvwm-menu-directory --special-dirs).

The problem is that currently PopupAsRootMenu does not work for these
dynamic menus. Because all menus are poped down while there is a line
  + DynamicPopDownAction DestroyMenu "/dir"
and MissingSubmenuFunction is not reexecuted on PopupAsRootMenu,
so fvwm complains: "[FVWM][menu_func]: <<ERROR>> No such menu /dir".
Is it possible not to pop down and then pop up again the last menu if
it is already up?

>    [comments wanted]

I have just tried to compile it and got a compilation error. My g++ is
near to the latest. I think that it would be better not to have any C++
source code, if possible, just to reduce compiler problems.

The idea of FvwmKb is very good, may help anyone using multi-lingua.
Although, since the author optionally wants to add support for other WMs
and there is own configure, maybe it is better not include it?
Personally, I would prefer to rewrite it to C (ufff) and include. :)

>  36) Test the new menu styles (ItemFormat!)

I am unintentionally testing this while working on fvwm-menu scripts.

I think, you should include:
  * Test the new session manager code (appeared only in 2.3.0)

There are many problems with it. Although, I run fvwm in gnome-session
without big problems for several months already. xsm is more problematic.
The most annoying bug is a broken window stack on startups/restarts
(fvwm thinks the window is in the bottom, but it is shown on the top).

Regards,
Mikhael.

---

From: Bob Woodside <[email-masked]>
Date: Thu, 02 Sep 1999 23:39:26 -0400

>      [confiremd by me (Dominik)]

	Erm...yes, but I haven't had time to make much progress lately, what
with other commitments. I'll try to apply a fix to CVS soon for testing,
though I'm not really satisfied with it.

	The problem is that ill-behaved windows like KFM's override_redirect
abominations are really incompatible with FVWM's new layer architecture.
It's conceptually the same problem as the RaiseOverNativeWindows hack
for Exceed users: to preserve the stacking order, all the windows from
the target of a Raise upward have to be raised over the unmanaged
windows (in this case the override_redirects, not the native Windows
ones).

	This is what I did (in a quick 'n dirty hard-coded hack - I need to add
the GlobalOpts logic and apply it against a more recent CVS). It works,
though I'm not really wild about the result, with all that extra
window-raising, but I don't see any other reasonable way around it.

	I did fantasize a bit about adding a GlobalOpts
Override_RedirectIsEvil, which would be used to consign all
override_redirect windows to a permanent StaysOnBottom status, or maybe
to destroy them as soon as an app tried to create them (I always
resented KFM's forcing little icons on my desktop that I didn't want
there).

	I'll try to put in a fix this weekend.

Cheers,
- Bob

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 3 Sep 1999 11:52:16 +0200

On Fri, Sep 03, 1999 at 12:50:09AM +0200, Dominik Vogt wrote:
>  6 to do (optional)
> 28 open items
> 53 items done
>      [90%; Dominik, Mark Rainford]
> 
> To be verified:
> 

Bye

Dominik ^_^

---

From: Tim Phipps <[email-masked]>
Date: Fri, 03 Sep 1999 11:35:48 +0100

>  76) Implement colour sets in FvwmWinList.

FvwmWinList is done, the missing ones are IconBox, Script, TaskBar,
Wharf and possibly FvwmBacker. I don't think TaskBar, Wharf and Backer
are in the must category. What they do can be replicated with other
modules. If we release 2.4 with them incomplete it may inspire someone
to add colorset support to them. I won't be doing any of them in the
forseeable future, I don't use them so I can't test them properly.

>  78) Implement colour sets in window styles.

Maybe these should be moved to the optional category. MenuStyle already
does everything a colorset would do (apart from shaping).  Adding it to
styles could be very tricky and it might make more sense to do that as
part of a serious rewrite of the style/decor stuff.

>  79) Implement colour sets in FvwmConsole.

This should be in the unlikely category of the enhancement requests. I
just had a quick hack and the xterm from /usr/openwin/bin/xterm on
Solaris draws in a child of the top level window. It sets $WINDOWID but
that window isn't visible.  Using xlswins I found the window to draw in
by guesswork and even though you can set the background as soon as you
type xterm draws characters in a rectangle of it's background color. It
looks a real mess.

I don't know if other term emulators would work better and it might be
possible to patch one to allow FvwmConsoleC to apply colorsets to it
succesfully, but what do we do then? Do we support an FvwmTerm? Do we
support a patch to another term?

Cheers,
Tim.

---

From: Brad Giaccio <[email-masked]>
Date: Tue, 7 Sep 1999 07:33:55 -0400

> forseeable future, I don't use them so I can't test them properly.

IconBox is already done, and I'm not sure how Backer would benefit from 
colorsets

> support a patch to another term?

We could possibly grab the old code from FvwmTalk, that created its own
window instead of using and xterm, then we would know exactlly how the
window is defined.  Thoughts?

-- 
--- 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://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, 07 Sep 1999 13:23:30 +0100

> IconBox is already done, and I'm not sure how Backer would benefit from

I missed FvwmIconBox being done. It looks like FvwmTaskBar and
FvwmScript are the only ones left.  I'm not serious about FvwmBacker but
it could be used to put a colorset into the root window (wouldn't work
with mixed visuals and would take a lot of memory).

> window is defined.  Thoughts?

The reason I use FvwmConsole rather than FvwmTalk is the history line
editing features you get with readline.  I think this means you need a
real terminal emulator with a pseudo terminal interface to the command.

Cheers,
Tim.

---

From: Dan Espen <[email-masked]>
Date: Tue, 07 Sep 1999 08:31:02 -0400

> real terminal emulator with a pseudo terminal interface to the command.

FvwmTalk history editing is a day or 2 from completion.

--
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: Brad Giaccio <[email-masked]>
Date: Tue, 7 Sep 1999 08:34:54 -0400

> with mixed visuals and would take a lot of memory).

Would It really take up any more memory than doing 
xv  -root -max -quit a.gif

> real terminal emulator with a pseudo terminal interface to the command.

I use the history stuff all the time my self, I wasn't suggesting
loosing that.  But I can take a look at the readline stuff and see if it
really needs a terminal or if any window will do.

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 9 Sep 1999 02:22:54 +0200

On Tue, Sep 07, 1999 at 01:23:30PM +0100, Tim Phipps wrote:
> FvwmScript are the only ones left.

> I'm not serious about FvwmBacker but

An excellent idea. Now I can even use gradients as a background. This
is indeed a useful option and a perfect replacement for xsetroot.
Whatever mixed visuals are (I'm completely ignorant :-) ), I see no
reason why this should work any worse than when I use xsetroot to
set the background.

> real terminal emulator with a pseudo terminal interface to the command.

And you can hit ctrl-d to close it.

Bye

Dominik ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 9 Sep 1999 02:18:29 +0200

On Fri, Sep 03, 1999 at 11:35:48AM +0100, Tim Phipps wrote:
> FvwmWinList is done,

Oops, i meant FvwmTaskBar.

> the missing ones are IconBox, Script, TaskBar,
> Wharf and possibly FvwmBacker.

Wharf, Backer and IconBox are completed.

> I don't think TaskBar, Wharf and Backer are in the must category.

I agree with Wharf and Backer, but TaskBar is used by many people
who wouldn't like to be forced to use IconMan instead. Writing a new
config can be quite a pain.

> part of a serious rewrite of the style/decor stuff.

I don't know. I'll think about menu styles, but I'm no expert with
styles.

Bye

Dominik ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 9 Sep 1999 02:11:22 +0200

> menu (like in: fvwm-menu-directory --special-dirs).

Okay, I'll leave it in.

> Is it possible not to pop down and then pop up again the last menu if

Not easily. But there is a solution for your problem. If you use
MissingSubmenuFunction only to create an empty menu and instead
place the code to build it in the DynamicPopupAction you can use
"DestroyMenu recreate ..." to create a fresh menu right after
deleting it. When you pop down the menu, the DynamicPopdownAction
is executed. After it has deleted the menu it must rebuild the
DynamicPopupAction. Now when the menu is finally posted it runs
the popup action again and is properly rebuilt. I guess it's as
complicated as it sounds, and it will leave you with an empty menu
for each popup you ever use. What do you think about this?
(If you do make the effort to get this working, could you please
add something in the FAQ?)

> Personally, I would prefer to rewrite it to C (ufff) and include. :)

Mikhael, can you talk with the Author of the module about his future
plans? I don't like the idea of adding a C++ module now that we finally
got rid of the last one we had.

> (fvwm thinks the window is in the bottom, but it is shown on the top).

'k, I've put it on the task list.

Bye

Dominik ^_^

---

From: Tim Phipps <[email-masked]>
Date: Thu, 09 Sep 1999 12:45:55 +0100

> reason why this should work any worse than when I use xsetroot to

It's the -visual option for fvwm. It means that colorset pixmaps won't
work with the root window.  You get a BadMatch error I think.

Cheers,
Tim.

---

From: Olivier Chapuis <[email-masked]>
Date: Fri, 10 Sep 1999 07:05:49 +0200

> config can be quite a pain.

Hello,
Here two very humble suggestions:

If someone do the TaskBar can he take the occasion to add a
*FvwmTaskBarIconBack  Option (there is an IconFore option) ?

Also I will be very happy if IconMan had the options: 
*FvwmIconMan*[id*]icon style [forecolor backcolor ]
*FvwmIconMan*[id*]iconcolorset colorset
Seems to be natural for an Icons manager ?

Olivier

---

From: Mikhael Goikhman <[email-masked]>
Date: Thu, 16 Sep 1999 07:42:24 +0300 (IDT)

> > >10) Remove 'PopupAsRootMenu' menu style (?).

[...]

> for each popup you ever use. What do you think about this?

I am still trying to get this working. Not easily. Maybe I will add an
option to fvwm-menu-directory, but I am not sure.

This solution (even it works somehow) applying to fvwm-menu-directory
can potencially produce memory leaks (menu (empty) is stored in memory,
but will never be accessed, because the directory is deleted). This is
usually the case for /proc process subdirectories. So if user visits
/proc or other similar subdirectories often, it collects memory leaks.

The only benefit is that 'MenuStyle * PopupAsRootMenu' will work, AFAIU.
This affects all menus, not what one may want. It is still impossible to
define a menu style for dynamic menus (say for menu names starting with
some prefix).

> add something in the FAQ?)

I was planned to write auto_menu.html with some initial examples and
explanations about static and dynamic menu generation. I hope you will
add your notes to it too. :)

> got rid of the last one we had.

I am forwarding the Author's response.
Maybe the initial solution is to add this module, but make it optional?
Anyway we wait until FvwmKb-0.3 is out.

Regards,
Mikhael.

---

From: Olivier Chapuis <[email-masked]>
Date: Thu, 16 Sep 1999 11:00:49 +0200

> add your notes to it too. :)
 
Hello,
Note that there are some examples of auto-menu with comments
in the fvwm-menu-desktop man page :o)
Olivier
--
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, 27 Sep 1999 00:12:20 +0200

> *FvwmTaskBarIconBack  Option (there is an IconFore option) ?

I have written an IconBack option today.

> Seems to be natural for an Icons manager ?

You're right, but this is one of the requests we will never
find the time to do unles someone provides a patch :-(

Bye

Dominik ^_^