On Mon, Oct 17, 2016 at 12:01:14AM +0100, Dominik Vogt wrote: > On Sun, Oct 16, 2016 at 05:09:57PM +0100, Thomas Adam wrote: > > On Sun, Oct 16, 2016 at 04:48:34PM +0100, Dominik Vogt wrote: > > > Maybe it's a silly question, but *why* does fvwm need mandatory > > > image support at all? Arent's images in a window manager just > > > gimmicks? > > > > It's not a silly question, but I'd hoped the commit message said enough. > > Gimmick is a matter of perspective. I'm trying to stike a balance through > > useability. I don't think it's unreasonable to assume one image library as > > the de facto; others are still available. I'm trying to frame this in terms > > of: > > > > * Making the default config useable and useful (which from what I'm seeing, > > does entail some form of image loading (for icons im menus and elsewhere) > > > > * Integrating with other third-party applications which generate menus > > (which > > use PNG). > > I completely understand that, and PNG seems to be a sensible > choice. The thing I'm unsure about is whether it should be > possible to build fvwm without any libraries and expendable > features to have a lean, minimalistic WM. But I've honestly no > idea whether anybody did that in the recent past or not.
These days you find two camps---those programs which are deliberately minimalistic in some way, and those which want to include a lot of things; size doesn't matter. I suspect when FVWM was in its heyday, the cost of including certain features would have had an impact on resources and memory footprint, etc. This explains why GNOME and KDE at the time had a bad press for resources. It's worth bearing in mind though that keeping things minimal is always worthwhile. But having many options---even if they're things which you can opt in and out of, still carry with them a burden of responsibility on the maintainer(s). For example, we currently still carry around XPM and SVG. Why? XPM is dead, and I am <-> close to removing it. SVG support is much more promising, it's a shame more things don't support it externally to make it more viable. The image rendering code in FVWM is clever---overly complex in trying to abstract away the actual format so that FVWM doesn't care about it for things like menus and buttons, etc. If we went with something modular, but extensible, we'd still be having to maintain these things. It's a lot easier to cut out the chaff, and make a statement about the things we do support. That will be just as minimal and small, IMO, without sacrificing much else, if anything. -- Thomas Adam
