On 14 Mar 2009 00:15:03 +0100, Dominik Vogt wrote: > > On Tue, Mar 10, 2009 at 10:34:38PM +0000, Mikhael Goikhman wrote: > > [Start of friendly mode.] > > 5) To make Thomas focus more on constructive things and less on > > destructive. :-) Really, I didn't see an fvwm developer who wanted to > > remove or break so many things in fvwm in so short period. :-) It > > should not be this way. > > I'm really with Thomas here and on all the other issues.
[Dominik, I suggest we stick our discussion to "here", because if we were to talk about "all the other issues", then I happen to believe I have much more in common with Thomas. :) Starting from the fact he is also the fvwm-themes developer, and we both have no problem with the acronym "FVWM" that you recently changed to "Fvwm" everywhere, and that he also favours perl and so on. :-) But let's return to the topic.] I clarified to Thomas in private that this was an unfortunate choice of words to express a simple idea that we were supposed to be in a freeze for 2.6. After that release, many things may (and should) be decided. > We have loads of unnecessary dependencies and features that nobody is > willing to maintain: > > * deb generation: unmaintained > * rpm generation: unmaintained > * html documentation: unmaintained > * perllib: unmaintained Someone else should answer about "html documentation", but the other things here work as intended without unexpected problems. I don't commit things without serious testing and thoughts forward. And they are not supposed to be broken if we just stick to our plan to release 2.6, i.e. not to make incompatible changes. What was your reason to say they are unmaintained and how do you define this? These are one of the relatively best maintained and documented parts in fvwm (given our total sorry state and compared to many actually forgotten parts). I just released the rpm package, so this part obviously works. And when yesterday FvwmGtkDebug was ported to a new toolkit I didn't need to change a bit in perllib. It is ready for writting fvwm modules, including ones that use event loops of popular toolkits. And since currently 5 of our fvwm modules by 3 different authors depend on, there is a very good chance it will always stay updated in the future. > * FvwmProxy: unfinished and unmaintained > * FvwmRearrage: not used by anybody I know I think there are many more old modules (from our list of more than 30) that possibly almost nobody uses. Still, I am not convinced this is the right time to remove them. Because removing now when things were mostly prepared for 2.6 means more work. We didn't damage the module protocol, there is no reason for the old modules to stop to work. This may only upset the users who will discover tomorrow that they are left without an alternative. > * FvwmGtk: mostly useless because it has nothing to offer that > fvwm can not do in a different way; artificial dependency on > gtk FvwmGtk is actually useful as a nicely-looking replacement for FvwmForm or FvwmScript. Anyone who wants to create a form interacting with fvwm is basically limited to these 3 modules with different set of widgets, syntax and features. But hey, I am not the author of this module, maybe the author agrees with you about the module uselessness. I am not the biggest fun of it, just a user. And as such I don't really understand the problem here. fvwm does not depend on gtk in any way. This module is not built if one has no gtk. For me, this looks like wanting to remove FvwmConsole, just because it is useless without xterm and someone dislikes dependence on xterm, and since we already have FvwmTalk (or even FvwmGtkDebug) doing this task. Am I the only one who thinks it is good to have FvwmGtk (ported to GTK2), so removing it now would add redundant work and no value? > * FvwmGtkDebug: useful, but the dependency on gtk really annoys > me. It should never have been part of the distribution with > that dependency: it's simply not cost efficient. Could have > been written without gtk and without a gui. FvwmDebug is the simple version without a gui, however it is not interactive for the obvious reasons. Can you suggest any other solution for implementing what FvwmGtkDebug does without the real toolkit like gtk? It requires advanced widgets (and scripting of course). BTW, running FvwmGtkDebug helps to see the redundant M_FOCUS_CHANGE and M_RAISE packets sent, as well as some other glitches. I would rather concentrate on solving this instead of discussing the aiding tool. And once again, fvwm does not depend on gtk, or xterm for that reason. The distributed modules that use them are optional. It should not be a problem to run an equivalent of "yum install package" when needed. > In my eyes all of this should be removed from the core > distribution unless someone shows up who is willing to maintain > this stuff for a long time. If need be, they can be put in a > supporting distribution. You listed several items. I may only speak about the things I created and still maintain. BTW, I noticed some entries in todo file that I will close soon. > > going to be removed without even slight doubts makes me too nervous > > for no reason. I think there is a place for many options for everyone. > > Let's try to increase the options, not to decrease them. > > I think we should do quite the opposite. Possibly. But please in the next unstable branch, and preferably after discussion and voting. Regards, Mikhael.
