Subject: Re: fvwm 2.3.x: How far will FvwmTheme go?

From: Mikhael Goikhman <[email-masked]>
Date: Sun, 18 Feb 2001 06:02:12 -0600

On 23 Jan 2001 10:37:20 +0100, Dominik Vogt wrote:
> 
> On Sun, Jan 21, 2001 at 01:55:19PM -0600, Mikhael Goikhman wrote:
> > 
> > It seems that FvwmTheme will be removed after 2.4 for speed/memory/lock
> > reasons and its functionality will be incorporated into the core.
> 
> Actually, I like the functionality where it is right now.  The
> only drawback is that backgrounds can not be scaled well if only a
> few colours are used (e.g. tetris look of gradient backgorunds) or
> take up a lot of memory if many colours are used.

Here are reasons why removing FvwmTheme after 2.4 is a good idea.
Feel free to argue.

FvwmTheme is not a normal module. You will want exactly one instance,
not two or zero (because colorsets are good, they will be the only method
after 2.4, and there are already things only possible using colorsets).

FvwmTheme's startup and config commands should always be synchronized.
Currently we have 2 processes, fvwm and FvwmTheme, which behave as one
process, when fvwm works FvwmTheme waits and vice versa.

We in fvwm-themes should use tricks because colorsets are not strictly
built-in, and FvwmTheme is not a normal module that can be just respawned.

There are some rare unexpected problems, like FvwmTheme is not started, or
is not synchronized. We try to detect them, but this is hard to reproduce.

There was already a fvwm-FvwmTheme deadlock on 2000-06-14 hanging X Server,
which I solved then. But can someone guarantee we have no more deadlocks or
synchronization problems regarding this module?

FvwmTheme, being a module, shares all module syntax problems, like
not expanding $[fg.cs1], so one colorset can't be defined using other
ones (a very common operation) without spawning a new PipeRead process.

Another module artifact, when FvwmTheme is restarted (KillModule, Module),
the entire previous colorset history is applied (great blinking effect if
some colorset was redefined several times). The colorset philosophy does
not match well the existing module philosophy, only the last value should
be stored, not all history.

FvwmTheme name is already confused with fvwm-themes. And we didn't finally
decide whether to create or not a new "FvwmThemes" module for our needs. :)

So I see no a single benefit for FvwmTheme to be a module, only problems.
I would rather prefer to have 2 commands SetColorset and DeleteColorset.
The same with a possible fontset solution in the future, suggested by Tim.

Regards,
Mikhael.
--
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: Sun, 18 Feb 2001 07:24:07 -0500

> Here are reasons why removing FvwmTheme after 2.4 is a good idea.

You left out:

FvwmTheme running as a separate module takes more memory and
CPU resources than it would if it was in fvwm.

--
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: Dominik Vogt <[email-masked]>
Date: Mon, 19 Feb 2001 02:27:29 +0100

> CPU resources than it would if it was in fvwm.

Hm.  If someone else does all the work ... ;-)

Well, there is still the size argument.

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]