On Mon, Oct 17, 2016 at 12:50:53AM +0100, Thomas Adam wrote:
> 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 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.


This may have gotten a bit out of hand (fvwm-2.6.7):

  $ ./configure --disable-nls --disable-mandoc --disable-sm --disable-shape 
--disable-shm --disable-xrender --disable-xinerama --disable-iconv 
--disable-xft --disable-bidi --disable-perllib --disable-gtk --disable-gtktest 
--disable-imlibtest --with-png-library=no --with-stroke-library=no 
--with-xpm-library=no --with-rplay-library=no --with-readline-library=no

  (everything turned off)

  $ make CFLAGS="-O3"
  $ cd fvwm
  $ ls -s --si fvwm
  979k fvwm
  $ ldd fvwm
        linux-gate.so.1 =>  (0xb77d7000)
        libSM.so.6 => /usr/lib/i386-linux-gnu/libSM.so.6 (0xb77bd000)
        libICE.so.6 => /usr/lib/i386-linux-gnu/libICE.so.6 (0xb77a4000)
        libXext.so.6 => /usr/lib/i386-linux-gnu/libXext.so.6 (0xb7791000)
        libX11.so.6 => /usr/lib/i386-linux-gnu/libX11.so.6 (0xb7659000)
        libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xb7633000)
        libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb74e1000)
        libuuid.so.1 => /lib/i386-linux-gnu/libuuid.so.1 (0xb74db000)
        libxcb.so.1 => /usr/lib/i386-linux-gnu/libxcb.so.1 (0xb74b7000)
        libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xb74b3000)
        /lib/ld-linux.so.2 (0xb77d9000)
        libXau.so.6 => /usr/lib/i386-linux-gnu/libXau.so.6 (0xb74b0000)
        libXdmcp.so.6 => /usr/lib/i386-linux-gnu/libXdmcp.so.6 (0xb74aa000)

Not exactly what I'd call small and with few dependencies.  libSM
linked although explicitly disabled.  This looks actually like a bug.

> 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.

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

> 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.

> That will be just as minimal and small, IMO, without
> sacrificing much else, if anything.


Dominik ^_^  ^_^


Dominik Vogt

Reply via email to