Re: [fvwmorg/fvwm] d30479: Make PNG support mandatory
On Mon, Oct 17, 2016 at 01:58:10AM +0100, Dominik Vogt wrote: > 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. Of course, but that was never FVWM's design goal, and it's a little unsuaul to suddenly make it one, given that it's not currently possible. I'm all for making things smaller (I already am), but I am not going to sacrifice anything else in FVWM to the point where the goals of giving something to the user are from the point of view of an arbitrary embedded system. That's not happening. > 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. I wasn't saying that. I was pointing out that in order to support many image formats (why?), it meant that this abstraction layer had to be written, for no real purpose other than to give people as much flexibility as possible, but putting a slight burden on the maintainer(s) of the code. The same example can be used in many other places in FVWM, and that's the trade-off between functionality and letting the design of FVWM grow organically through many different people, over a long period of time. Trying to reign that back, whilst still providing the same or similar functionality is important. > > 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. Well, we'll see, but given everything else in FVWM, I suspect this won't even be a blip on the radar. Kindly, -- Thomas Adam
Re: [fvwmorg/fvwm] d30479: Make PNG support mandatory
On Mon, Oct 17, 2016 at 01:58:10AM +0100, Dominik Vogt wrote: > 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" Sorry ... $ make CFLAGS="-Os" $ cd fvwm $ ls -s --si fvwm 697k fvwm* $ strip fvwm $ ls -s --si fvwm 623k fvwm Still too big for small systems. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: [fvwmorg/fvwm] d30479: Make PNG support mandatory
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 (0xb74b) 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
Re: [fvwmorg/fvwm] d30479: Make PNG support mandatory
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
Re: [fvwmorg/fvwm] d30479: Make PNG support mandatory
On Sun, Oct 16, 2016 at 05:36:51PM -0600, Jaimos Skriletz wrote: > What about having libpng be default but having a --disable-libpng > ./configure option to disable? Have it set up to error out if libpng and > that option are not present with an error that says building without libpng > may affect the default config and other applications. If you want to build > without libpng use --disable-libpng. I think having it compiled in is fine---that it might not be used in all cases is also fine. That's still down to the user. -- Thomas Adam
Re: [fvwmorg/fvwm] d30479: Make PNG support mandatory
On Sun, Oct 16, 2016 at 5:01 PM, 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. > Perosnally, if I weren't too lazy to change the config, I could > perfectly do without image support: The menu logo is just > decoration, icons work as well when done as text, and the > FvwmButtons images could be replaced by thext or just menu > entries. > > What about having libpng be default but having a --disable-libpng ./configure option to disable? Have it set up to error out if libpng and that option are not present with an error that says building without libpng may affect the default config and other applications. If you want to build without libpng use --disable-libpng. This way if someone really wants to build without image support they can without having to edit the configure script. Though the answer to having such an option may be on what happens when fvwm hits the .png images in the default config without support. I'm hoping it just throws a warning and leaves a blank place where the image should be. jaimos​
Re: [fvwmorg/fvwm] d30479: Make PNG support mandatory
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. Perosnally, if I weren't too lazy to change the config, I could perfectly do without image support: The menu logo is just decoration, icons work as well when done as text, and the FvwmButtons images could be replaced by thext or just menu entries. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: [fvwmorg/fvwm] d30479: Make PNG support mandatory
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). XPMs are dead. SVGs aren't as supported. PNGs feel like the right thing to support. HTH, Thomas Adam
Re: [fvwmorg/fvwm] d30479: Make PNG support mandatory
On Sun, Oct 16, 2016 at 08:19:59AM -0700, GitHub wrote: > Make PNG support mandatory > > Traditionally, FVWM has always had the option of not linking to any image > renderer at all. > > But, the entire world has moved on, and support for images is becoming more > important, especially with third-party applications. Indeed, FVWM itself will > have a new default configuration soon which will make use of PNGs. It's a > good idea to support this out of the box. > > Choosing the default image library is not easy -- and although there's a sway > towards SVGs (which FVWM supports), PNGs are quite common still, so use that. 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? Ciao Dominik ^_^ ^_^ -- Dominik Vogt
[fvwmorg/fvwm] 9703d6: Make PNG support mandatory
Branch: refs/heads/master Home: https://github.com/fvwmorg/fvwm Commit: 9703d649aa91c74dde1ac92caedc3145fa1d6f53 https://github.com/fvwmorg/fvwm/commit/9703d649aa91c74dde1ac92caedc3145fa1d6f53 Author: Thomas Adam Date: 2016-10-16 (Sun, 16 Oct 2016) Changed paths: M configure.ac M fvwm/fvwm.c Log Message: --- Make PNG support mandatory Traditionally, FVWM has always had the option of not linking to any image renderer at all. But, the entire world has moved on, and support for images is becoming more important, especially with third-party applications. Indeed, FVWM itself will have a new default configuration soon which will make use of PNGs. It's a good idea to support this out of the box. Choosing the default image library is not easy -- and although there's a sway towards SVGs (which FVWM supports), PNGs are quite common still, so use that.
[fvwmorg/fvwm] 9703d6: Make PNG support mandatory
Branch: refs/heads/ta/png-default Home: https://github.com/fvwmorg/fvwm Commit: 9703d649aa91c74dde1ac92caedc3145fa1d6f53 https://github.com/fvwmorg/fvwm/commit/9703d649aa91c74dde1ac92caedc3145fa1d6f53 Author: Thomas Adam Date: 2016-10-16 (Sun, 16 Oct 2016) Changed paths: M configure.ac M fvwm/fvwm.c Log Message: --- Make PNG support mandatory Traditionally, FVWM has always had the option of not linking to any image renderer at all. But, the entire world has moved on, and support for images is becoming more important, especially with third-party applications. Indeed, FVWM itself will have a new default configuration soon which will make use of PNGs. It's a good idea to support this out of the box. Choosing the default image library is not easy -- and although there's a sway towards SVGs (which FVWM supports), PNGs are quite common still, so use that.
[fvwmorg/fvwm] d30479: Make PNG support mandatory
Branch: refs/heads/ta/png-default Home: https://github.com/fvwmorg/fvwm Commit: d304791e3600e3180c22418356dcd9bc45bb3a22 https://github.com/fvwmorg/fvwm/commit/d304791e3600e3180c22418356dcd9bc45bb3a22 Author: Thomas Adam Date: 2016-10-16 (Sun, 16 Oct 2016) Changed paths: M bin/Makefile.am M configure.ac M fvwm/Makefile.am M fvwm/fvwm.c M libs/Makefile.am M modules/FvwmAnimate/Makefile.am M modules/FvwmBanner/Makefile.am M modules/FvwmButtons/Makefile.am M modules/FvwmIdent/Makefile.am M modules/FvwmPager/Makefile.am M modules/FvwmProxy/Makefile.am M modules/FvwmScript/Makefile.am Log Message: --- Make PNG support mandatory Traditionally, FVWM has always had the option of not linking to any image renderer at all. But, the entire world has moved on, and support for images is becoming more important, especially with third-party applications. Indeed, FVWM itself will have a new default configuration soon which will make use of PNGs. It's a good idea to support this out of the box. Choosing the default image library is not easy -- and although there's a sway towards SVGs (which FVWM supports), PNGs are quite common still, so use that.
[fvwmorg/fvwm] 199f0b: Make PNG support mandatory
Branch: refs/heads/ta/png-default Home: https://github.com/fvwmorg/fvwm Commit: 199f0b23156a3bf9c9d44d4b91c962b6f853247f https://github.com/fvwmorg/fvwm/commit/199f0b23156a3bf9c9d44d4b91c962b6f853247f Author: Thomas Adam Date: 2016-10-16 (Sun, 16 Oct 2016) Changed paths: M bin/Makefile.am M configure.ac M fvwm/Makefile.am M fvwm/fvwm.c M libs/Makefile.am M modules/FvwmAnimate/Makefile.am M modules/FvwmBanner/Makefile.am M modules/FvwmButtons/Makefile.am M modules/FvwmIdent/Makefile.am M modules/FvwmPager/Makefile.am M modules/FvwmProxy/Makefile.am M modules/FvwmScript/Makefile.am Log Message: --- Make PNG support mandatory Traditionally, FVWM has always had the option of not linking to any image renderer at all. But, the entire world has moved on, and support for images is becoming more important, especially with third-party applications. Indeed, FVWM itself will have a new default configuration soon which will make use of PNGs. It's a good idea to support this out of the box. Choosing the default image library is not easy -- and although there's a sway towards SVGs (which FVWM supports), PNGs are quite common still, so use that.
[fvwmorg/fvwm]
Branch: refs/heads/ta/png-default Home: https://github.com/fvwmorg/fvwm
[fvwmorg/fvwm] 22d79e: Make PNG support mandatory
Branch: refs/heads/ta/png-default Home: https://github.com/fvwmorg/fvwm Commit: 22d79eb923fb3ae4489a57f26f688e58c6c09446 https://github.com/fvwmorg/fvwm/commit/22d79eb923fb3ae4489a57f26f688e58c6c09446 Author: Thomas Adam Date: 2016-10-16 (Sun, 16 Oct 2016) Changed paths: M bin/Makefile.am M configure.ac M fvwm/Makefile.am M fvwm/fvwm.c M libs/Makefile.am M modules/FvwmAnimate/Makefile.am M modules/FvwmBanner/Makefile.am M modules/FvwmButtons/Makefile.am M modules/FvwmIdent/Makefile.am M modules/FvwmPager/Makefile.am M modules/FvwmProxy/Makefile.am M modules/FvwmScript/Makefile.am Log Message: --- Make PNG support mandatory Traditionally, FVWM has always had the option of not linking to any image renderer at all. But, the entire world has moved on, and support for images is becoming more important, especially with third-party applications. Indeed, FVWM itself will have a new default configuration soon which will make use of PNGs. It's a good idea to support this out of the box. Choosing the default image library is not easy -- and although there's a sway towards SVGs (which FVWM supports), PNGs are quite common still, so use that. Commit: c1471bcb0ef40534b7689ad08ce2099910c47b23 https://github.com/fvwmorg/fvwm/commit/c1471bcb0ef40534b7689ad08ce2099910c47b23 Author: Thomas Adam Date: 2016-10-16 (Sun, 16 Oct 2016) Changed paths: M .travis.yml Log Message: --- Test travis build Compare: https://github.com/fvwmorg/fvwm/compare/1cd5594d7555...c1471bcb0ef4
[fvwmorg/fvwm] 1cd559: Test travis build
Branch: refs/heads/ta/png-default Home: https://github.com/fvwmorg/fvwm Commit: 1cd5594d75556ef4961f95157cb71b67c9904fde https://github.com/fvwmorg/fvwm/commit/1cd5594d75556ef4961f95157cb71b67c9904fde Author: Thomas Adam Date: 2016-10-16 (Sun, 16 Oct 2016) Changed paths: M .travis.yml Log Message: --- Test travis build
