On Mon, Oct 17, 2016 at 07:01:52PM +0100, Dominik Vogt wrote: > And the logical consequence of this statement is to hard code > image formats and remove the library code, no?
No. The logic stops in saying that out-of-the-box, PNG image support is available. At a minimum. Other renderers are available, and from what I can tell, pretty much every single FVWM installation which is packaged includes all image renderes FVWM supports. That's telling in and of itself. Perhaps the only exception to this is Gentoo. > 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 No. I'm saying that as an image format used in the wild, all of the projects I can see don't support XPMs. I'm not saying it's being removed at all. It's an example showing that FVWM is carrying around optional support for it. *That's* a maintainer burden in that the cost of removing it is high because someone out there (presumably with a long beard, I couldn't say), is still using it. > 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. You mean making it optional? I disagree there. We already _support_ it. Go look at all the Linux distros which package FVWM. You'll quickly see what they chose to compile in. You'll have to prove to me there's a negative impact on FVWM. You'll have to prove to me the size increase is hampering something important, and you'll definitely have to tell me how this is a problem for maintainability, when we already support PNG image loading. No additional code is being added or taken away here, it's just a compile-time change. This change is additive, and helps FVWM out-of-the-box. And sorry, embedded systems don't count because as you've also seen, FVWM is too large anyway, even with all the optional libraries taken out and the binary stripped. That's also not taking into account modules as well---which, by the way, you also have with FVWM as a consequence. Kindly, -- Thomas Adam
