Thomas Adam <tho...@fvwm.org> writes: > On Mon, Oct 13, 2014 at 05:53:06PM -0400, Dan Espen wrote: >> >> I don't see the sense in removing xpm, svg, bmp, etc. support. >> How many lines of code does that save? > > Hi Dan, > > It's not about saving lines of code, or even necessarily trying to reduce > the amount of memory that's being used, as it is more an effort to > "standardise" on one or two things (at most), thus reducing the overhead as > a maintainer/programmer.
But I question that there is any savings. There's a tiny amount of XPM code in Fvwm and I can't remember there ever being a problem with it. > I know it's a departure from what we have now, because it's a change, but > that's something that's a little easier to do. It's not necessarily all > about less code either, but having a multitude of different image formats is > nice from a users' perspective, but it's little effort to convert them. So you agree it's better for the users. I've set Fvwm in some work areas where the first thing that goes wrong with Fvwm, those users will move to Windows full time. >> But my real issue is moving the development source >> to another location and not documenting anything about it. > > I don't see this as clandestine---although I assume that's not what you're > implying. Which parts are undocumented, may I ask? The development model > (if I can call it that) is the same as we have now for fvwm---sure, the > sources for mvwm are in a different location now (they're in git, they have > to be), but I'd happily grant you commit privileges, etc., if you wanted so > you could work on mvwm. There are detailed step by step instructions at fvwm.org that explain the entire CVS process: http://fvwm.org/documentation/dev_cvs.php >> That, and changing the name of fvwm to something else. >> >> If you want to fork, say so. > > There's already a separate thread for this; it's already been > discussed---I'm unsure how much of that you've been following? To be fair, > there was quite a flurry of emails. Yes, I remember. > Yes, I changed the name for (at the time) good reasons. If you remember, I mentioned that I've been running versions of fvwm side by side for years. There is no reason to change a name. > You can still take your existing fvwm config, tweak a few things [1] and you > ought not to see any difference. That's the point, we're still trying to > keep compatibility as much as possible before we diverge things away. Sure, > in the case of images, that's already happened a little, but these changes > are expected more and more as time progresses. You won't get there by renaming everything. > It's evolution, Dan, it's not exactly a fork. Were it so, I'd have been > even more brutal in my approach, but that's not what I had in mind _at all_ > when I started this. It doesn't look like evolution. Not with a name change. -- Dan Espen
