On 15 Mar 2009 00:34:16 +0100, Dominik Vogt wrote: > > On Sat, Mar 14, 2009 at 08:23:57PM +0000, Mikhael Goikhman wrote: > > This is a long post, since I tried to reply to all comments. This is > > pretty important to me. > > > > On 14 Mar 2009 11:22:22 +0100, Dominik Vogt wrote: > [snip] > > > As far as I remeber: > > > > > > * deb and rpm: We got bug reports that nobody took care of. > > > > I remember patches that were sent and applied in one or another way. > > > > Do you know about any real problem with the current code that needs > > fixing? > > No, I never bothered to understand rpm or debs. > > > > * html documentation: It's mostly unusable for me and way too > > > complex. There are be other, simpler ways to achive the same > > > benefits (asciidoc?). > > > > Although I fully share your sentiments here, I would like to hear the > > other side first, to decide whether it is actually unmaintained. > > > > Also I suggest when something critical like this is started next time, > > to warn the developers in advance that you will delete this new stuff > > the moment you feel it is not developed any more. I think this would be > > fair to know in advance. > > I haven't deleted anything in the last seven years. What are you > trying to say?
In my first message on this topic I said exactly this. I.e. I didn't see fvwm developers urging to delete things (especially if there is some opposition to this). But for some reason you disagreed with my words and not only backed up the opposite opinion to remove certain parts from fvwm, but extended this to even never mentioned parts, like generation of rpms or perllib. > > > * perllib: Changes in the module interface that are not > > > reflected in perllib (I really can't remember which). > > > > Sorry, but I prefer to think this is not true without a real evidence. > > > > Of course some cooperation from you would be nice, but not really > > necessary, perllib was transparently adapted to your changes and will > > hopefully be in the future. It is enough that you write cvs messages > > correctly and start a new thread each time you intend to break the > > module interface (potentially affecting all our 36 modules), then your > > changes are eventually noticed by me, Scott or someone else who cares. > > Sorry about the missing cooperation. Nobody bothered to explain > what the perllib is good for in the first place, so my knowledge > about is is close to zero. I think I introduced perllib several times on this list. > I don't know where it is in the source > tree, I don't know how it's installed, how to use it or how it > works. So I really can't judge whether any change affects it or > not. perllib is basically what you often dreamed about on the list in the form of bashlib. The main problem with it is that not everyone likes perl and is expert in it. On the other hand some may think that Perl is perfect for this task, since this is a dynamic multiparadigm language with advanced data types, and with deep unix roots. perllib has API allowing to write a minimal module in several lines. There are some working examples of modules in tests/perl/ directory. The documentation is available either on our web or using fvwm-perllib, like: "fvwm-perllib --man tutorial". It offers basic things any fvwm module needs, i.e. registering native language callbacks with interpreted arguments for any event mask in any quantities and order, and entering the event loop. In addition, many extra things are available to make writting modules convenient. It includes ways (classes) to use different graphical toolkits, i.e. to listen to both fvwm messages and toolkit messages in the same loop. And there is an implementation of higher level abstraction that hides groups of specific fvwm event types and exposes the automatically updated objects. I.e. you may just have variables at any time holding the current page or up-to-date colorset structures, module configs etc. Such implementation is theoretically possible in any dynamical language (some are more suited for this, some are less), even on bash. The issue is perllib is already here for seven years and is well supported. > [snip] > > > > > FvwmGtk is actually useful as a nicely-looking replacement for > > > > FvwmForm or FvwmScript. > > > > > > And all of these are narly useless. Fvwm has the interfaces to > > > allow third party gui toolkits to control fvwm without need for > > > builtin modules. > > > > Clearly we have different meaning of "useful". I guess, had you try to > > write a whole new layer over fvwm. you would not want to declare dialog > > modules communicating with fvwm (FvwmScript, FvwmForm and FvwmGtk) > > useless. :) > > There is no need to couple dialog toolkits directly with fvwm. There is no need to couple any module dirrectly with fvwm. But they make it more useful. It is hard to draw the line. There were no unreasonable dependances added to fvwm, and all these dependancies (even perl) are completely optional (except for X library and such). So the question is really whether someone is willing to maintain the extra things that is not in your definition of the ideal core. If you do not need to worry about these extra things that do not add any mandatory dependency, then I think you should not feel too strong opposing them. > > > > 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. > > > > > > Actually we removed FvwmTalk for this same reason years ago. It's > > > just an FvwmForm now. > > > > FvwmTalk is still available as a wrapper and my point about removing > > FvwmConsole is still valid. > > > > > Depending on xterm is not an artificial dependency. On one hand, every > > > X installation has xterm or some equivalent. > > > > Unfortunately this is not true for the modern systems for at least 5 > > years now. > > > > xterm is distributed separately from the X system, and usually is not > > installed for the default (GNOME or KDE) installation. > > > > > On the other hand, a different terminal can be used. > > > > So this is still another dependancy, just like gtk. > > All I understand is that you want so say "dependency = no > problem". FvwmConsole just needs a terminal to run in that > supports a few options. That isn't a real restriction in an X > installation. And if there really is a system that doesn't have > a terminal, FvwmConsole is useless anyway. It would be very incorrect to state that I say dependency is no problem. Just in other threads I criticized the distributions that (simingly correctly) assigned all dependencies to all users and I claimed that this is against the developers intention. Because the fact is all dependencies are optional. I do care about dependencies and I would not agree to add any mandatory dependency, just like you. > > Will we remove > > FvwmConsole because of this? We have FvwmTalk that does the same > > without a need in additional dependancy. [I know that you and myself > > use FvwmConsole, I think it is a fair suggestion, since you suggest to > > remove modules that others use using exactly the same reasoning.] > > I'm *not* suggesting to remove everything, just bits that are > mostly subsets of more general solutions. I read your plans about fvwm core 3.0 and I think they may be great, but it would be very hard for a single man to (re)implement everything. I kindly suggest you to try to attract people to assist you and not to imediatelly put veto on any ideas that extend your core into something more useful. Different points of view may be refreshing. However we now discuss 2.6. And it would be pity not to release it as soon as possible, because a lot of work was done in the 2.5 series and it is deserved to be released. After that I am all for your idea to start to redesign fvwm. > Actually FvwmConsole could almost be removed in favour of FvwmCommand > if the latter hadn't so many restrictions in usability. Unfortunately, FvwmCommand is not a solution at all if we speak about writting modules using it. The only thing FvwmCommand does is providing a stream of formatted messages from fvwm. But you already have a stream of messages from fvwm by opening pipes directly. You still need to implement the event loop (to listen to fvwm or FvwmCommand stream _and_ the interactive input), you still need to implement the parsing of this stream into some useful data structures, you still need scripting. So in effect, FvwmCommand is a redundant layer that does not by itself provide any solution. > > > > > * 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. > > > > > > I don't understand why you think "non-gui = non-interactive". > > > Assuming that FvwmGtkDebug is really for developers, > > > > To be interactive the module should both listen to fvwm and to the input > > (mouse, keyboard) in the same event loop. Don't you agree? > > Yes. And why does this rule out text based interfaces? Please show how this is possible without adding any real toolkit. (And ncurses toolkit is another dependency, just like gtk. Programming in it is not much different from programming in gtk, it is just much more limited and more annoying.) And as I said there is a half ready support of pseudo toolkit in perllib that uses xterm, but there are serious technical obstacles to interact with xterm tty (even without ncurses, just simple readline). I tried it when started to develop perllib to get user-interactive things done without gtk, it does not work well. > > perllib supports this for at least Gtk and Tk toolkits. It also > > supports a pseudo-toolkit mode using pure xterm, xmessage and similar > > "standard" X things. Also the idea was to be able to write a module > > that uses Gtk if presents and fallbacks to the pseudo-toolkit mode > > otherwise. But I didn't find the real application for this. Usually > > you need real full-featured widgets for a real-life interactive module. > > > > FvwmGtkDebug is really not simple to reimplement without gtk. > > I don't know, I couldn't make it run anyway. Too many dependencies ;-) > It looks like it's impossible to install fvwm anywhere but in > /usr/local. Well, fvwm seems to ignore the > "--prefix=/home/something/foo" option I gave it when it looks for > modules. [Almost wanting to cry...] Of course ./configure --prefix works, followed by make and "make install". My fvwm is always in /opt/fvwm/. Actually I have several installations. Including /usr/bin/fvwm from rpm, that is not used. When you installed another instance of fvwm, you may do "Restart /opt/fvwm/bin/fvwm" and this new instance will find correct modules (it only does not find them on non-standard installations). In any case you may always give full path to a module, even word "Module" is opional. Also you may run fvwm-config that sits in the same bin/ directory where you installed fvwm: fvwm-config --fvwm-moduledir The package needed to run FvwmGtkDebug is perl-Gtk2 (rpm) or libgtk2-perl (deb), depending on the distribution. > > > > And once again, fvwm does not depend on gtk, or xterm for that reason. > > > > > > Fvwm packages in Linux distributions *do* depend on gtk, and > > > that's the whole point. > > > > It also depends on xterm that is arguably less frequent on modern > > systems nowadays than gtk. > > At least the debian packages in 4.1 and 5.0 don't have a > dependency to xterm. The Fedora package has this dependency. Of course I do not say fvwm should depend on xterm, in other threads I expressed exactly this displeasure. Why to force optional things on all users. This is why our own rpm and deb packages do not depend on xterm or Perl/Gtk or perl/Tk, although some modules do not work if a user does not have these. > > > > > > 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. > > > > > > Then let's take a look at the individual items. > > > > > > * rpm and deb > > > > > > There may have been some discussion about the technical details, > > > but definitely no discussion about whether they should be part > > > of fvwm, and definitely no voting. > > > > I am not sure I understand your intend here. Do you want to vote on > > something that is maintained and useful and works correctly? I think we > > will not end this way, we may as well decide on voting on every commit. > > > > I suggested a different thing: voting after 2.6 about all unmaintained > > things to see whether they should be removed or not. > > [snip] > > > > * perllib > > > > > > Definitely no voting about it. > > > > Please reword this. I am not sure I understand your meaning. > > Well, where is the discussion about adding script languages to > export the module interface. If things get into fvwm without > discussion, they may as well be thrown out without discussion (and > no, I'm not suggesting to throw anything out). My position is simple. If someone wants to maintain zshlib or schemelib or smalltalklib for writting modules, I have no problem with this. Of course it may be beneficial to sync these with perllib (and C library). > > > * FvwmGtk > > > > > > Dumped in fvwm without a discussion about the taken approach and > > > was never commented by any developers. A typical case of > > > accepting third party work in fvwm without a maintainer. > > > > Matthias Clasen was an active developer on this list when I came. I > > would not call it a third party work. > > > > But why do you disagree with the idea to discuss and implement all > > grandiose ideas and cleanup after 2.6? A module is here for more than > > 10 years and I don't remember that a goal for 2.6 was removing modules. > > I don't disagree with anything, it just annoys me when people are > bashed because they try to keep fvwm maintainable. It's > ridiculous to imply that I'd not care about backwards > compatibility. If I misread your messages, sorry. But I think you fully supported another opinion that spoke about removing things and breaking backwards compatibility. > Sorry, maybe I am wrong about this, but I really feel that you are > simply saying the opposite of what I say since 2001. I don't even want to ask why 2001. This is just not true. I like most of the people on this list sympaty you and agree on many things, just not all (and even when there is a tactical disagrement it is still far from the opposite). Regards, Mikhael.
