On Mon, Oct 17, 2016 at 07:53:17AM +0100, Thomas Adam wrote:
> 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,
Keeping it small always was a design goal, although of course
having a lot of functionality counteracts this somewhat. Maybe
not aiming at embedded systems.
> 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.
And the logical consequence of this statement is to hard code
image formats and remove the library code, no?
> 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.
When you say that XPM is dead, does this mean XPM support is on
the remove list in favour of PNG? What other change could affect
and possibly annoy more people at once? While it may be possible
to convert the configuration files mostly automatically,
converting system installed XPM icon libraries during is certainly
Making PNG support mandatory is not going to have any positive
effect on code size or maintainability unless something else is
removed in favour of PNG.
Dominik ^_^ ^_^