Re: Fvwm project
On 20 October 2014 10:19, Michael Treibton mtreib...@googlemail.com wrote: On 15 October 2014 20:15, Michael Treibton mtreib...@googlemail.com wrote: On 13 October 2014 22:53, Dan Espen des...@verizon.net wrote: I don't see the sense in removing xpm, svg, bmp, etc. support. How many lines of code does that save? I've often wondered - but also i dont care what format my files are in as long as they just work. that said, i dont like this change much either because its too disuptive to other people. can we not do this? so can we get an official answer? i know Thomas is active because i see code changes - so is this a fork proper or not? i suppose we all have our answer. Thanks for the conversation, i look forward to the time when mvwm merges with fvwm but even converting my config over is a lot of effort now. annoyed, Michael
Re: Fvwm project
On 15 October 2014 20:15, Michael Treibton mtreib...@googlemail.com wrote: On 13 October 2014 22:53, Dan Espen des...@verizon.net wrote: I don't see the sense in removing xpm, svg, bmp, etc. support. How many lines of code does that save? I've often wondered - but also i dont care what format my files are in as long as they just work. that said, i dont like this change much either because its too disuptive to other people. can we not do this? so can we get an official answer? i know Thomas is active because i see code changes - so is this a fork proper or not? Michael
Re: Fvwm project
On 13 October 2014 22:53, Dan Espen des...@verizon.net wrote: I don't see the sense in removing xpm, svg, bmp, etc. support. How many lines of code does that save? I've often wondered - but also i dont care what format my files are in as long as they just work. that said, i dont like this change much either because its too disuptive to other people. can we not do this? I can imagine it saves some amount of non-resident memory, but if you don't have xpms, libxpm should not be using any significant real memory. Otherwise, it just causes issues for users. agree. But my real issue is moving the development source to another location and not documenting anything about it. That, and changing the name of fvwm to something else. If you want to fork, say so. i dont know how official it is but i consider mvwm a fork - and why not? what difference is it making either way? i know that if i want to use mvwm i have to update my config - and that's ok - is it not? Michael
Re: Fvwm project
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.
Re: Fvwm project
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
