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
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 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 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: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 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 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 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 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 07:53:17AM +0100, Thomas Adam wrote: > 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, Keeping it small always was a design goal, although of course having a lot of functionality counteracts this somewhat. Maybe not aiming at embedded systems. > 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. And the logical consequence of this statement is to hard code image formats and remove the library code, no? > 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. 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 and possibly annoy more people at once? While it may be possible to convert the configuration files mostly automatically, converting system installed XPM icon libraries during is certainly not. 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. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: [fvwmorg/fvwm] d30479: Make PNG support mandatory
On Mon, Oct 17, 2016 at 02:04:54AM +0100, Dominik Vogt wrote: > 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. $ cd fvwm $ ls -s -S --si *.o 58k style.oC, S, P! 54k menus.oC, P 50k move_resize.o C, P 50k builtins.o P! 41k events.o C 41k fvwm.o C 37k add_window.o C 37k borders.o C, D 29k virtual.o C 25k icons.oD 25k ewmh.o I 21k conditional.o C 21k menustyle.oC, P, S 21k placement.oC 21k colorset.o D 17k stack.oC 17k module_list.o C 17k functable.oC 17k frame.oC, D 17k windowlist.o C 17k functions.oC 17k session.o I 13k ewmh_events.o I 13k expand.o C 13k geometry.o C 13k focus.oC 13k module_interface.o C 13k menuitem.o C 13k menubindings.o C 13k update.o C 13k gnome.oI 8.2k bindings.o C 8.2k ewmh_icons.o I 8.2k misc.o ? 8.2k cursor.o D 8.2k decorations.o D 8.2k read.o C 8.2k colormaps.o<--- candidate for removal 8.2k menucmd.o C 8.2k ewmh_conf.oI 4.1k modconf.o C 4.1k icccm2.o I 4.1k schedule.o C 4.1k windowshade.o D 4.1k infostore.o? 4.1k execcontext.o C 4.1k focus_policy.o C 4.1k repeat.o <--- candidate for removal, never really worked 4.1k menugeometry.o C 4.1k ewmh_names.o I 4.1k menudim.o C 4.1k condrc.o C C = important core functionality D = decorations related core code I = Interfacing code (external standards) P! = lots of parsing code P = considerable amount of parsing code S = lots of hard coded strings Really not a lot of potential for removing code from the core. The colourmap code is probably unnecessary nowadays, and the "repeat" feature is mostly a source of hard to debug crashes. Personally I'm very unhappy about the interfaces which traditionally cause more trouble than anything, but I guess people want them as long as there are applications around using them. $ cd fvwm $ ls -s -S --si *.o 46k PictureUtils.o 25k Flocale.o 17k Graphics.o 17k CombineChars.o 17k PictureGraphics.o 13k FScreen.o 13k FEvent.o 13k FlocaleCharset.o 13k Colorset.o 8.2k FTips.o 8.2k Parse.o 8.2k ColorUtils.o 8.2k Bindings.o 8.2k XError.o 8.2k PictureImageLoader.o 8.2k gravity.o 8.2k Module.o 8.2k PictureBase.o 4.1k Picture.o 4.1k XResource.o 4.1k Cursor.o 4.1k envvar.o 4.1k Target.o 4.1k System.o 4.1k WinMagic.o 4.1k Strings.o 4.1k queue.o 4.1k Grab.o 4.1k safemalloc.o 4.1k FImage.o 4.1k charmap.o 4.1k FRenderInit.o 4.1k Fft.o 4.1k fvwmrect.o 4.1k flist.o 4.1k wcontext.o 4.1k fvwmsignal.o 4.1k timeout.o 4.1k Rectangles.o 4.1k modifiers.o 4.1k FGettext.o 4.1k Ficonv.o 4.1k wild.o 4.1k ClientMsg.o 4.1k fio.o 4.1k fsm.o 4.1k Event.o 4.1k fvwmlib.o 4.1k FRender.o 4.1k setpgrp.o 4.1k BidiJoin.o 4.1k FShape.o 4.1k FBidi.o Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: [fvwmorg/fvwm] d30479: Make PNG support mandatory
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
Re: [fvwmorg/fvwm] d30479: Make PNG support mandatory
On Mon, Oct 17, 2016 at 07:36:28PM +0100, Thomas Adam wrote: > On Mon, Oct 17, 2016 at 07:01:52PM +0100, Dominik Vogt wrote: > 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. Only if you ever want to remove it, which you said you wouldn't do. > > 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. Then what is the gain of making it mandatory if every distro has it anyway? With that line of argumwnt the only effect of making it mandatory is making fvwm harder to build for some people. > 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. In what way does it help fvwm, or us developers or the users if PNG support is now guaranteed to be there while it just happened to be there unless the user compiled fvwm herself? > 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. Modules are optional. That's the only point of the module concept (everything they do could be done easier in the core). If you don't want them, you don't have to install them (which is a bit of manual work with the current Makefiles). No vital functionality is or should ever be in a module. So, let's forget about embedded systems, but people do use it in environments where simplicity and small installation size counts (e.g. a buddy of mine who uses it as the interface of his home grown media/entertainment setup, and he is explicitly happy that he did now have to have any image support but could do with simple menus and vector buttons). Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: [fvwmorg/fvwm] d30479: Make PNG support mandatory
On Mon, Oct 17, 2016 at 08:10:00PM +0100, Dominik Vogt wrote: > Then what is the gain of making it mandatory if every distro has > it anyway? With that line of argumwnt the only effect of making > it mandatory is making fvwm harder to build for some people. Harder to build, how? We've just ruled out embedded systems. Even the most esoteric Linux distributions fare well, as would any of the BSDs too. Again, if this were a problem, it's going to be with a platform which most other people are maintaining themselves. > In what way does it help fvwm, or us developers or the users if > PNG support is now guaranteed to be there while it just happened > to be there unless the user compiled fvwm herself? Run-time functionality never helps developers. It will help users with the default config which is being worked on which will use images, and I think it's important to show that off. Having *some* consistency out-of-the-box is important, and I am utterly convinced supporting images is a good thing here. > So, let's forget about embedded systems, but people do use it in > environments where simplicity and small installation size counts > (e.g. a buddy of mine who uses it as the interface of his home > grown media/entertainment setup, and he is explicitly happy that > he did now have to have any image support but could do with simple > menus and vector buttons). And he's still able to do that with an extra library his fvwm configuration likely never uses. This is now all theoretical. I am not hearing anything which says this breaks things for any one, other that it offends peoples' sense of being forced into something they might not use. That's fine, since this is a small thing, IMO. -- Thomas Adam
Re: [fvwmorg/fvwm] d30479: Make PNG support mandatory
On Mon, Oct 17, 2016 at 08:19:20PM +0100, Thomas Adam wrote: > On Mon, Oct 17, 2016 at 08:10:00PM +0100, Dominik Vogt wrote: > > Then what is the gain of making it mandatory if every distro has > > it anyway? With that line of argumwnt the only effect of making > > it mandatory is making fvwm harder to build for some people. > > Harder to build, how? Examples: 1) User wants to compile himself; libpng-devel is not installed => could still compile without having to install if he wanted to. Now he's forced to figure out the package name and install it. Sure, no much harder, but still a little. This will definitely me after the next distro upgrade. 2) For some reason, libpng is incompatible on the system => you can't compile fvwm until you fix that distro problem. We've just ruled out embedded systems. Even the most > esoteric Linux distributions fare well, as would any of the BSDs too. Again, > if this were a problem, it's going to be with a platform which most other > people are maintaining themselves. > > > In what way does it help fvwm, or us developers or the users if > > PNG support is now guaranteed to be there while it just happened > > to be there unless the user compiled fvwm herself? > Run-time functionality never helps developers. It will help users with the > default config which is being worked on which will use images, and I think > it's important to show that off. Having *some* consistency out-of-the-box is > important, and I am utterly convinced supporting images is a good thing here. Agreed. > > So, let's forget about embedded systems, but people do use it in > > environments where simplicity and small installation size counts > > (e.g. a buddy of mine who uses it as the interface of his home > > grown media/entertainment setup, and he is explicitly happy that > > he did now have to have any image support but could do with simple > > menus and vector buttons). > > And he's still able to do that with an extra library his fvwm configuration > likely never uses. > > This is now all theoretical. I am not hearing anything which says this breaks > things for any one, other that it offends peoples' sense of being forced into > something they might not use. In my eyes, relying on third party software being available and not broken is always bad. One can do it if there are good reasons, but I don't see any here. You *can* use PNG in any configs coming with fvwm and still allow people who don't want them do their own thing. There's no conflict between these two. > That's fine, since this is a small thing, IMO. So, I see we won't find a common point of view. In my eyes, taking away the choice without any benefit (because every distro compiles fvwm with PNG support anyway) is bad. People may want to use it on tiny systems like a Raspberry Pi and this may make life more difficult for them. The intention of having a show off or default config using PNG is a good idea, but one can still have an option "--disable-png" and tell people: Warning: You have disabled PNG image support. While fvwm works fine without it, the sample configurations coming with fvwm (or configurations provided by other people) use PNG images that cannot be displayed without PNG support. Other than that, these configurations should work fine. And if the system does not have a useable libpng-devel installed: Error: No useable version of libpng found. PNG image support is required for the sample configurations coming with fvwm, but may be disabled with the --disable-png configure option. It is strongly recommended to not switch off PNG support unless the system where fvwm is intended to run has critical size limitations. there are critical size limitations on the target system. system (A default configuration may as well require additional libraries or tools that are otherwise optional.) Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: [fvwmorg/fvwm] d30479: Make PNG support mandatory
On Mon, Oct 17, 2016 at 10:05:04PM +0100, Dominik Vogt wrote: > The intention of having a show off or default config using PNG is > a good idea, but one can still have an option "--disable-png" and > tell people: [...] OK -- so what if we do that, but it defaults to using PNG if it's on the system? Would that make things easier for everyone? If so, I'm happy to do that. -- Thomas Adam
Re: [fvwmorg/fvwm] d30479: Make PNG support mandatory
On Mon, Oct 17, 2016 at 10:30:37PM +0100, Thomas Adam wrote: > On Mon, Oct 17, 2016 at 10:05:04PM +0100, Dominik Vogt wrote: > > The intention of having a show off or default config using PNG is > > a good idea, but one can still have an option "--disable-png" and > > tell people: > > [...] > > OK -- so what if we do that, but it defaults to using PNG if it's on the > system? Fine with me, even if it produces an error message if libpng-devel is not found and --disable-png is not explicitly used. > Would that make things easier for everyone? If so, I'm happy to do that. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
