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. Kindly, -- Thomas Adam
