Re: REWRITE: Some removed features
Dominik Vogt dominik.v...@gmx.de wrote: 2. Support for xpm, xbm and svg images. While I've no idea whether svg images are really usefull (in title buttons perhaps?), xpm images, and to a lesser extent xbm iamges, are still used a lot in old icon themes. So I vote for reviving support for xpm and xbm format. I can take care of both. In Fvwm-Nightshade I am using mostly svg's because of the flexibility in conjunction with different display resolutions. Also the trend in other DEs/WMs is in direction to svg (icon themes, decorations). It would be a pitty if FVWM(3) loose this support. But to reduce the core to an effective minimum it is ok for me. I suppose that Thomas thought to implement those parts as modules which would be great because then other image formats can plugged to FVWM very easily. Also it would reduce the maintenance ^^ -- Thomas --
Re: REWRITE: Some removed features
On Mon, Aug 18, 2014 at 03:18:13PM +0100, Dominik Vogt wrote: Some features that have been removed in mvwm that I'm not sure about: 1. FvwmCpp and FvwmM4 Heh. In my mind, it came back to maintainability, and from time-to-time we often see problems with people trying to use these modules. but with nonone in the development team really owning them, so most of the problems end up either being ignored or worked around at some higher level. (Some of the problems may be surrounding the whole approach of ModuleSynchronous, etc., but that's tangential to my point.) These preprocessing modules are an important part of fvwm's flexibility. I extensively use FvwmCpp to adapt my fvwm config to the actual machine I'm working on. My .fvwm2rc looks like this: Oh, I understand their use, and I appreciate that the module interface fvwm has allows for these sorts of things to be written. My eventual aim though is to see them naturally fall out of usefulness over time; assuming we have a more robust parser, we shouldn't *need* these kinds of modules to preprocess commands for us. But we're a long way off that, so perhaps reviving FvwmCpp in the interim should happen. I'd be OK with that. But please bear in mind that I am seriously *loathe* to want to keep adding things in; the whole point of trying to clean this up is to also identify easy wins of removal as well. So I'm willing to be flexible on this, of course. And seeing as this is a module, there's perhaps no harm in reviving it. Go for it. :) 2. Support for xpm, xbm and svg images. While I've no idea whether svg images are really usefull (in title buttons perhaps?), xpm images, and to a lesser extent xbm iamges, are still used a lot in old icon themes. So I vote for reviving support for xpm and xbm format. Hmm. I mean, try and convince me otherwise, Dominik, but I'd rather see one image format used. PNG seems to suffice for this, and caters for replacing {X,B}PM files, as they can easily be converted without any hassle to the user. If necessary I could even put a script in contrib/ to facilitate this. It also reduces the code a little. -- Thomas Adam
Re: REWRITE: Some removed features
On Mon, Aug 18, 2014 at 04:06:02PM +0100, Thomas Adam wrote: On Mon, Aug 18, 2014 at 03:18:13PM +0100, Dominik Vogt wrote: Some features that have been removed in mvwm that I'm not sure about: 1. FvwmCpp and FvwmM4 Heh. In my mind, it came back to maintainability, and from time-to-time we often see problems with people trying to use these modules. but with nonone in the development team really owning them, so most of the problems end up either being ignored or worked around at some higher level. (Some of the problems may be surrounding the whole approach of ModuleSynchronous, etc., but that's tangential to my point.) These preprocessing modules are an important part of fvwm's flexibility. I extensively use FvwmCpp to adapt my fvwm config to the actual machine I'm working on. My .fvwm2rc looks like this: Oh, I understand their use, and I appreciate that the module interface fvwm has allows for these sorts of things to be written. My eventual aim though is to see them naturally fall out of usefulness over time; assuming we have a more robust parser, we shouldn't *need* these kinds of modules to preprocess commands for us. But we're a long way off that, so perhaps reviving FvwmCpp in the interim should happen. I'd be OK with that. But please bear in mind that I am seriously *loathe* to want to keep adding things in; the whole point of trying to clean this up is to also identify easy wins of removal as well. So I'm willing to be flexible on this, of course. And seeing as this is a module, there's perhaps no harm in reviving it. I find it really strange to have a configuration input filter implemented as a module. I don't know what to do with it in the long run, but at the moment I find it indispensable. 2. Support for xpm, xbm and svg images. While I've no idea whether svg images are really usefull (in title buttons perhaps?), xpm images, and to a lesser extent xbm iamges, are still used a lot in old icon themes. So I vote for reviving support for xpm and xbm format. Hmm. I mean, try and convince me otherwise, Dominik, but I'd rather see one image format used. PNG seems to suffice for this, and caters for replacing {X,B}PM files, as they can easily be converted without any hassle to the user. If necessary I could even put a script in contrib/ to facilitate this. It also reduces the code a little. I agree that converting them is not a big deal. It's just that there are these old icon distributions in xpm format around. Maybe it's indeed feasible to have a module concept like zsh that would automatically load additional features when they are needed for the first time. If the module concept was less broken, such features could be implemented over the module interface. And xpm images are easy to write as source code. Hm, don't we have some hard coded xpm images somewhere in the sources anyway? Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: REWRITE: Some removed features
Thomas Adam tho...@fvwm.org writes: On Mon, Aug 18, 2014 at 05:23:57PM +0100, Dominik Vogt wrote: I find it really strange to have a configuration input filter implemented as a module. I don't know what to do with it in the long run, but at the moment I find it indispensable. I understand. And xpm images are easy to write as source code. Hm, don't we have some hard coded xpm images somewhere in the sources anyway? We don't have anything in the source, but we do seem to offer these still: http://fvwm.org/download/icons.php Is that what you were thinking of? There are XPM files in the test directory and one XPM file stored with FvwmBanner. -- Dan Espen
Re: REWRITE: Some removed features
The MvwmCpp module is back on the master branch. Ciao Dominik ^_^ ^_^ -- Dominik Vogt