On Mon, Oct 17, 2016 at 01:58:10AM +0100, Dominik Vogt wrote:
> But keep small and/or embedded systems in mind.  It's still
> possible to use just the core without any libraries and modules
> and have a very small WM that can even draw basic window
> decoration and some graphical effects.

Of course, but that was never FVWM's design goal, and it's a little unsuaul to
suddenly make it one, given that it's not currently possible.  I'm all for
making things smaller (I already am), but I am not going to sacrifice anything
else in FVWM to the point where the goals of giving something to the user are
from the point of view of an arbitrary embedded system.  That's not happening.

> I'd be very much against removing the plug-in image format and
> hard coding PNG instead.  While there definitely is some
> unpleasant to maintain bloat in fvwm, it's certainly not the image
> library.

I wasn't saying that.  I was pointing out that in order to support many image
formats (why?), it meant that this abstraction layer had to be written, for no
real purpose other than to give people as much flexibility as possible, but
putting a slight burden on the maintainer(s) of the code.

The same example can be used in many other places in FVWM, and that's the
trade-off between functionality and letting the design of FVWM grow
organically through many different people, over a long period of time.  Trying
to reign that back, whilst still providing the same or similar functionality
is important.

> > It's a lot easier to cut out the chaff, and make a statement about the 
> > things
> > we do support.
> Sure, but I suspect in this specifice case we're going to regret
> it in the future.

Well, we'll see, but given everything else in FVWM, I suspect this  won't even
be a blip on the radar.


-- Thomas Adam

Reply via email to