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

Reply via email to