Subject: to do for 2.4 (update 23)

From: Dominik Vogt <[email-masked]>
Date: Mon, 27 Sep 1999 00:07:57 +0200

FvwmTheme/colour set support is nearing completion. Only
FvwmScript has still to be done (I guess we can skip
FvwmConsole). I don't know how much work it is to
support colour sets in the Style command.

Items with highest priority / most severe problems:

78, 79, 80, 83, 91

New since last update:

96

Closed since last update:

76

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

 4 in progress
 1 to be verified
 7 to do (must)
 4 to do (optional)
 4 fixes (high priority fix)
 1 fixes (optional fix)
 7 testing
----------------------------
28 open items
68 items done
96 items in total

---------- In progress: ------------------------------------------

 9)  Set up RPM packages.
     [???; Jason?]
 11) Add FvwmKb module?
     [in progress; Mikhael?]
 48) Finish Windoze 95 like config file.
     [in progress (90%)]
 91) Fix Xpm version problem (bug #463).
     [Tim]

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

 55) FvwmGtk can't be killed with 'KillModule'.
     [???]

---------- To do (must): -----------------------------------------

 7)  Create an I18N fvwm package (from 2.2 or so).
     [since the author seems to have lost interest I will disable
     the code if necessary]
 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
 78) Implement colour sets in window styles.
 83) Fix FvwmIconMan crashes introduced by colour set support(?)
 90) Icon distribution.

---------- To do (optional) --------------------------------------

 12) Set up bzip2 tarballs.
 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).
     [couldn't reproduce this yet; can anybody who has netcool
     event manager try it?]
 96) Make flat titlestyle work again.
     [reported by Pekka Marjola, bug #469]

---------- Fixes (optional): -------------------------------------

 32) Several applications are reported to not resize well under fvwm
     (Datek's "Streamer", CodeWarrior).

---------- 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.
 
========== 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).
 10) Remove 'PopupAsRootMenu' menu style (?).
     [rejected]
 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.
     [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.
 50) Implement a 'ButtonGeometry' option for FvwmButtons.
 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]
 54) Find a better solution for raising/lowering of transients.
     [done]
 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.
 75) Implement colour sets in FvwmWharf.
 76) Implement colour sets in FvwmTaskBar.
 77) Implement colour sets in menu styles.
 82) Introduce a 'transient' option for FvwmButtons. This is needed
     to replicate the old panel behaviour.
 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)
 93) Finish 'CREATING PANELS' section in FvwmButtons man page.
     [Dominik]

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: Tim Phipps <[email-masked]>
Date: Tue, 28 Sep 1999 15:32:08 +0100

Dominik Vogt wrote:
> 
> FvwmTheme/colour set support is nearing completion.

I'm thinking that the syntax for setting colorsets needs redoing, the
fixed position of arguments makes it difficult to add new features.
Would it be difficult to rewrite it like the MenuStyle command? If it's
going to happen it should happen before 2.4 or we'll be stuck with the
old way.

The reason I'm asking is that I'm considering putting in a Transparency
pixmap option as well as a Tint option and maybe getting the foreground
color to understand "blink" as well as "contrast" (only with read/write
pixels).

Cheers,
Tim.

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 28 Sep 1999 17:13:30 +0200

On Tue, Sep 28, 1999 at 03:32:08PM +0100, Tim Phipps wrote:
> Would it be difficult to rewrite it like the MenuStyle command?

No, not at all.  There are powerful service functions in libs/Parse.c
that do all of the work for you.

> If it's going to happen it should happen before 2.4 or we'll be stuck
> with the old way.

Yup, you're right.

> color to understand "blink" as well as "contrast" (only with read/write

How could that transparency option work? I still had no idea how
you can do this except by using shapes.

I have another enhancement suggestion, but I'm not sure if it
can be done easily.  I want to specify certain colour names that
are taken from colour sets.  So you could say

  *FvwmButtonsFore $foreground_cs3
  *FvwmButtonsBack $shadow_cs3
  Exec exec xterm -bg $background_cs0

and so on. Hm, doesn't sound too difficult.

BTW, I have a question about shapes that someone may be able to
answer:  When I add combine shape masks for a window and finally
want to turn off the shape of a window, how do I do this? I don't
have a description of the shape commands.  The only way I could
figure out was to 'or' a filled rectangle of the size of the window
into the shape mask with XShapeCombineMask, but this is too slow to
be acceptable.  Is there a way to simply turn shapes off?

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]

---

From: Tim Phipps <[email-masked]>
Date: Wed, 29 Sep 1999 11:16:58 +0100

> you can do this except by using shapes.

Just like all those terminal emulators - you fake it.  What you need to
do it to shift the background pixmap so its origin is at the absoloute
coordinates (0,0).  I think you can do this by:

*) take the background pixmap supplied by FvwmTheme
*) use it as the tile in a GC (XSetTile(), XSetFillStyle())
*) XSetTSOrigin(GC, -(window absolute x), -(window absolute y))
*) XFillArea a new pixmap with the GC
*) Apply the new pixmap as the window background
*) free the new pixmap

Getting the absolute coordinates require a round trip to the server so
it could be quite slow. Using big pixmaps could also slow things down.

The other major problem is that it won't look transparent if fvwm puts a
border around the window which shifts the location. To fix this you have
to add StructureNotifyMask to the event mask and handle ConfigureNotify
events like FvwmWinList. You also have to recompute the background
pixmap every time the window moves. Actually, on thinking about this, it
looks like an awful lot of work.

> and so on. Hm, doesn't sound too difficult.

I thought about doing this in the library function GetColor().  I think
all the modules use the library GetColor() and they all have the
colorset stuff linked in so it should be possible to just modify the
library.

>   Exec exec xterm -bg $background_cs0

Not sure about this one though as it wants the color value not the
pixel.

Cheers,
Tim.

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 29 Sep 1999 15:59:03 +0200

> colorset stuff linked in so it should be possible to just modify the

That was my first idea too.  But that won't help for applications
that use XAllocColor or XAllocNamedColor.  If the fvwm command
line parser replaces the pixels values with the corresponding
rgb values this can be passed to any application.  The only problem
would be to find out the rgb values.  THe benefit is that all
applications on the desktopn can share the same colour set (well,
at least as long as you do not change it).

Bye

Dominik ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 30 Sep 1999 02:39:35 +0200

> going to happen it should happen before 2.4 or we'll be stuck with the

Alright, the new parsing is in place.  The 'Colorset' command for
FvwmTheme now takes a comma separated list of options:

  Colorset <n> option [, option] ...

The Shape, TiledShape, AspectShape, Pixmap, TiledPixmap, 
AspectPixmap and ?Gradient options work exactly as they did
before.  There are new options Foreground/Fore/fg and
Background/Back/bg that do the same as the former position
dependent fore and back colours.  The options Hilight/Hilite/hi
and Shadow/Shade/sh are completely new.  Since parsing is
completely position independent there is no need for any
'-' specifiers anymore.  All options can be used independently
at any time.

Tim, would you update the man page for the new syntax?
I am so very tired of writing man pages :-/

---
There are two more issues that I did not resolve, and I
would be grateful if I don't have to do it.  First, since
all options are optional, we need to supply some default
colours if the user doesn't specify one.  All that is left
to do is to put the appropriate pixel values in the
structure - the logic is already there.  I have marked the
placed where to put the code with three exclamation marks.

The second open issue are the hilight and shadow colours.
These used to be initialised with a colour based on the bg
colour (with 'average' background).  I don't understand why
we can't simply use GetShadow() and GetHilite() here.  I have
ifdef'ed two occurences of this logic.  If it's okay to use
Get...() these two paragraphs can be deleted.

---
There was a bug in the calculation of 'average' background
colours with transparent pixmaps.  The pixmap first filled
the transparent part with the yet undefined background
colour, then the bg code calculated the average colour on
the random pixels :-) I guess I have fixed this.  I didn't
test the 'contrast' bit.

---
I had to put back the mask bit in colour sets. I need
them to draw the transparent part of xpm backgrounds in the
background colour. Tim, please have a look at the current
colorset_struct. I had to put some FvwmTheme internal
members in there that are not communicated to the modules
but take up some space. Do you have a better idea how to
handle this?

Bye

Dominik ^_^

---

From: Tim Phipps <[email-masked]>
Date: Thu, 30 Sep 1999 18:05:35 +0100

> FvwmTheme now takes a comma separated list of options:

Great stuff, I've done a man page, it needs reviewing.
> placed where to put the code with three exclamation marks.

I couldn't think of anything better than copying the colors from
colorset 0. Colorset 0 is initially created by fvwm and contains the
DefaultColors colors which default to black/gray.

> Get...() these two paragraphs can be deleted.

These colors are calculated when FvwmTheme is using read/write colors.
In this case the pixel values never changed (they are
XAllocColorCells()'d when the colorset is created).  You can't use
GetHilite() since it uses XAllocColor and returns a pixel.
> the random pixels :-) I guess I have fixed this.  I didn't
Contrast is just calculated from the background color so this shouldn't
need changing.
> but take up some space. Do you have a better idea how to

I've put an ifdef in the structure definition so that only FvwmTheme.c
can see the private parts. I don't know if this is the best way but it
compiles.

Cheers,
Tim.

PS I'm off until Wednesday.