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.


-- Thomas Adam

Reply via email to