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. 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. > 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. > 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 changed the name for (at the time) good reasons. 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. 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. -- Thomas Adam [1] I could even write a temporary script to do this, if it becomes more common.
