Re: REWRITE: Some removed features
Dominik Vogt dominik.v...@gmx.de wrote: 2. Support for xpm, xbm and svg images. While I've no idea whether svg images are really usefull (in title buttons perhaps?), xpm images, and to a lesser extent xbm iamges, are still used a lot in old icon themes. So I vote for reviving support for xpm and xbm format. I can take care of both. In Fvwm-Nightshade I am using mostly svg's because of the flexibility in conjunction with different display resolutions. Also the trend in other DEs/WMs is in direction to svg (icon themes, decorations). It would be a pitty if FVWM(3) loose this support. But to reduce the core to an effective minimum it is ok for me. I suppose that Thomas thought to implement those parts as modules which would be great because then other image formats can plugged to FVWM very easily. Also it would reduce the maintenance ^^ -- Thomas --
Re: REWRITE: Some removed features
On Mon, Aug 18, 2014 at 03:18:13PM +0100, Dominik Vogt wrote:
Some features that have been removed in mvwm that I'm not sure
about:
1. FvwmCpp and FvwmM4
Heh. In my mind, it came back to maintainability, and from time-to-time we
often see problems with people trying to use these modules. but with nonone
in the development team really owning them, so most of the problems end up
either being ignored or worked around at some higher level. (Some of the
problems may be surrounding the whole approach of ModuleSynchronous, etc.,
but that's tangential to my point.)
These preprocessing modules are an important part of fvwm's
flexibility. I extensively use FvwmCpp to adapt my fvwm config
to the actual machine I'm working on. My .fvwm2rc looks like
this:
Oh, I understand their use, and I appreciate that the module interface fvwm
has allows for these sorts of things to be written. My eventual aim though
is to see them naturally fall out of usefulness over time; assuming we have
a more robust parser, we shouldn't *need* these kinds of modules to
preprocess commands for us.
But we're a long way off that, so perhaps reviving FvwmCpp in the interim
should happen. I'd be OK with that.
But please bear in mind that I am seriously *loathe* to want to keep adding
things in; the whole point of trying to clean this up is to also identify
easy wins of removal as well. So I'm willing to be flexible on this, of
course. And seeing as this is a module, there's perhaps no harm in reviving
it.
Go for it. :)
2. Support for xpm, xbm and svg images.
While I've no idea whether svg images are really usefull (in
title buttons perhaps?), xpm images, and to a lesser extent xbm
iamges, are still used a lot in old icon themes. So I vote for
reviving support for xpm and xbm format.
Hmm. I mean, try and convince me otherwise, Dominik, but I'd rather see one
image format used. PNG seems to suffice for this, and caters for replacing
{X,B}PM files, as they can easily be converted without any hassle to the
user. If necessary I could even put a script in contrib/ to facilitate
this. It also reduces the code a little.
-- Thomas Adam
Re: REWRITE: Some removed features
On Mon, Aug 18, 2014 at 04:06:02PM +0100, Thomas Adam wrote:
On Mon, Aug 18, 2014 at 03:18:13PM +0100, Dominik Vogt wrote:
Some features that have been removed in mvwm that I'm not sure
about:
1. FvwmCpp and FvwmM4
Heh. In my mind, it came back to maintainability, and from time-to-time we
often see problems with people trying to use these modules. but with nonone
in the development team really owning them, so most of the problems end up
either being ignored or worked around at some higher level. (Some of the
problems may be surrounding the whole approach of ModuleSynchronous, etc.,
but that's tangential to my point.)
These preprocessing modules are an important part of fvwm's
flexibility. I extensively use FvwmCpp to adapt my fvwm config
to the actual machine I'm working on. My .fvwm2rc looks like
this:
Oh, I understand their use, and I appreciate that the module interface fvwm
has allows for these sorts of things to be written. My eventual aim though
is to see them naturally fall out of usefulness over time; assuming we have
a more robust parser, we shouldn't *need* these kinds of modules to
preprocess commands for us.
But we're a long way off that, so perhaps reviving FvwmCpp in the interim
should happen. I'd be OK with that.
But please bear in mind that I am seriously *loathe* to want to keep adding
things in; the whole point of trying to clean this up is to also identify
easy wins of removal as well. So I'm willing to be flexible on this, of
course. And seeing as this is a module, there's perhaps no harm in reviving
it.
I find it really strange to have a configuration input filter
implemented as a module. I don't know what to do with it in the
long run, but at the moment I find it indispensable.
2. Support for xpm, xbm and svg images.
While I've no idea whether svg images are really usefull (in
title buttons perhaps?), xpm images, and to a lesser extent xbm
iamges, are still used a lot in old icon themes. So I vote for
reviving support for xpm and xbm format.
Hmm. I mean, try and convince me otherwise, Dominik, but I'd rather see one
image format used. PNG seems to suffice for this, and caters for replacing
{X,B}PM files, as they can easily be converted without any hassle to the
user. If necessary I could even put a script in contrib/ to facilitate
this. It also reduces the code a little.
I agree that converting them is not a big deal. It's just that
there are these old icon distributions in xpm format around. Maybe
it's indeed feasible to have a module concept like zsh that would
automatically load additional features when they are needed for the
first time. If the module concept was less broken, such features
could be implemented over the module interface.
And xpm images are easy to write as source code. Hm, don't we
have some hard coded xpm images somewhere in the sources anyway?
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
Re: REWRITE: Some removed features
Thomas Adam tho...@fvwm.org writes: On Mon, Aug 18, 2014 at 05:23:57PM +0100, Dominik Vogt wrote: I find it really strange to have a configuration input filter implemented as a module. I don't know what to do with it in the long run, but at the moment I find it indispensable. I understand. And xpm images are easy to write as source code. Hm, don't we have some hard coded xpm images somewhere in the sources anyway? We don't have anything in the source, but we do seem to offer these still: http://fvwm.org/download/icons.php Is that what you were thinking of? There are XPM files in the test directory and one XPM file stored with FvwmBanner. -- Dan Espen
Re: REWRITE: Some removed features
The MvwmCpp module is back on the master branch. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
