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.
Hm.
> 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
library.
> 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.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
