Re: Removing things from FVWM CVS.
On 16 Mar 2009 00:52:27 +0100, Dominik Vogt wrote: On Sun, Mar 15, 2009 at 07:00:05PM +, Mikhael Goikhman wrote: On 15 Mar 2009 00:34:16 +0100, Dominik Vogt wrote: [snip] 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. It's just a bit of menu handling. These things certainly existed before guis where ever invented. We speak about handling fvwm events while being in this menu, right? FvwmGtkDebug does not miss any event while waiting for the user input. 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 optional. Also you may run fvwm-config that sits in the same bin/ directory where you installed fvwm: fvwm-config --fvwm-moduledir Well, of course I know all this. I do $ configure --prefix=$HOME/foo $ make clean $ make install # restart fvwm from $HOME/foo (no module path in config) -- No such module 'FvwmButtons' in ModulePath '/usr/local/libexec/fvwm/2.5.28' Sorry, I can't reproduce any problem with your commands. Executable fvwm is regenerated on the next make after make clean, so the new dir is built in. Are you sure this is not the case? % strings fvwm/fvwm | grep libexec /home/migo/foo/libexec/fvwm/2.5.28 FVWM_MODULEDIR=/home/migo/foo/libexec/fvwm/2.5.28 % ~/foo/bin/fvwm-config --fvwm-moduledir /home/migo/foo/libexec/fvwm/2.5.28 % strings ~/foo/bin/fvwm | grep libexec /home/migo/foo/libexec/fvwm/2.5.28 FVWM_MODULEDIR=/home/migo/foo/libexec/fvwm/2.5.28 So I issued Restart $HOME/foo/bin/fvwm, got naked fvwm, selected Issue fvwm commands from the root menu, FvwmConsole came without problems, issued Exec xmessage '$[FVWM_MODULEDIR]' just in case, all works. Then returned to my normal fvwm: Restart fvwm-themes-start. However with single make instead of make clean (or if this step is skipped completely) the fvwm executable is not regenerated (if nothing but --prefix is changed). So make clean is the solution here. I may try to hack configure.ac so that make clean is not needed when just --prefix is changed (I guess we may #define FVWM_INSTALL_DIRS with unused value in config.h for this). But I want to hear from you first. * 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
Re: Removing things from FVWM CVS.
On Sun, Mar 15, 2009 at 07:00:05PM +, Mikhael Goikhman wrote: On 15 Mar 2009 00:34:16 +0100, Dominik Vogt wrote: [snip] 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. It's just a bit of menu handling. These things certainly existed before guis where ever invented. 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 Well, of course I know all this. I do $ configure --prefix=$HOME/foo $ make clean $ make install # restart fvwm from $HOME/foo (no module path in config) -- No such module 'FvwmButtons' in ModulePath '/usr/local/libexec/fvwm/2.5.28' * 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. Im just *very* annoyed that gtk is needed to use fvwm with all features. 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). I'd rather discuss this in private. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: Removing things from FVWM CVS.
2009/3/14 Dominik Vogt dominik.v...@gmx.de: [...] As far as I remeber: * deb and rpm: We got bug reports that nobody took care of. * html documentation: It's mostly unusable for me and way too complex. There are be other, simpler ways to achive the same benefits (asciidoc?). i'm trying not to muddy the waters with possible irrelevant conversation here, but I do agree with you on this -- I do find the documentation side of things a little cumbersome and I know for a fact there's much easier ways of handling this. I really *like* the idea behind having HTML documentation, don't get me wrong; the whole idea of it was always to split the documentation up into sections. I spent a long time at work last year putting together asciidoc and git for us devlopers to use for internal documentation with a fair amount of sucess. Whilst I can appreciate why in FVWM we're reliant on pure XML files to keep docbook happy, I wished there had been more discussion. Something like asciidoc would still do the same thing and have the advantage that: * It's all in plaintext. * There's no requirement to understand/learn XML. * The asciidoc markup is quite simple. The original requirement that kicked this change in documentation off was that for a while -- particularly on IRC and on the mailing lists, there was the question of the manpage is too big, etc. Using something like asciidoc for plain-text readability when writing the documentation, the fact that it can be structured on a per-file basis for different sections, and that it can produce documentation in different output formats is all the better --- and note that for me, the main requirement for any documentation writing -- it should be in plain text first and foremost as much as possible. Alas, I do question though how easy it would be to change it now -- and I do know a lot of work went in to making it the way it is now. To undo all of that might seem like a slap in the face to people like Scott who did all the work originally. That said, if this is up for consideration, cool. [...] * html documentation Became a part of fvwm because people spent a lot of work on it. It is *the* top 1 reason why I don't write features anymore: I'm simply unable to write the documentation anymore. I find this really sad. To think that one of core FVWM developers over the years no longer has any gumption to write new features because of the documentation? Well that surely has to change. Dominik, I assume (from my own experiences) that for you: * The overhead in understanding how the documentation fits together is high; * The requirement for using/learning XML is too much; Things like that? If not, I wonder what we might think about doing to help make this easier? * 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. This does bring about an interesting question: How do we handle the situation of maintaining FVWM modules which are in the CVS tree? It's different for the core of FVWM -- that's maintained differently, but a specific module? We can't rely or accept that the person submitting a module is the maintainer thereafter, although it would be nice. But people aren't always around for long, have other interests, real life kicks in, etc., so presumably the maintainership falls to whomever wants to do something with it at the time. Bar one or two, I would think almost all the modules in FVWM aren't maintained in that the original authors aren't here anymore. But that's OK, most of the modules in FVWM only use the FVWM -- Module communication protocol, they're not reliant on anything else --- hence if we (as developers) ever broke anything, that's our problem to fix. Plus it makes understanding a given module much easier. But where you have modules reliant on third-party bits of software (anything written using perllib is a prime example here, although currently GTK is) that becomes a little more tricky. In the case of perl there's: * Looking out for major API changes in perl releases (perl 5.10 is hugely different to perl 5.8 -- and I would hate to see any perl 5.10 idioms ever make it into FVWM; you can't rely on its deployment on an aging SunOS machine for instance.) * Use of CPAN modules (FvwmTabs does this) -- what if a newer version shipped downstream by a distribution breaks due to some new subroutine call for instance? We're still responsible to fix it. * Having these extra CPAN modules is a requirement in order for the module to work. You could argue the last point is true of anything in the core -- i.e., if I wanted libstroke I would need to install it before I could make any mouse gestures --- but for a module this just seems wrong somehow. Plus, and this a bigee, here upstream, we are reponsible for all of this. We have a perllib API -- we are responsible for it, to make sure it
Re: Removing things from FVWM CVS.
On Sat, Mar 14, 2009 at 11:13:21AM +, Thomas Adam wrote: 2009/3/14 Dominik Vogt dominik.v...@gmx.de: But this is almost thrust upon existing developers. Dominik, you obviously fall into this category: could you fix something in perllib or FvwmTabs if it broke? No, I couldn't. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: Removing things from FVWM CVS.
2009/3/14 Mikhael Goikhman m...@homemail.com: [...] One of the examples of a pragmatical asciidoc that may be considered is POD (Plain_Old_Documentation article in Wikipadia). Well, all perl documentation in fvwm is already in POD, and the corresponding html is generated from it. That's one possibility but very inflexible. No, we're talking about the manpage here -- and I wouldn't want to see POD used as a basis for it. I use POD on a daily basis; it's fine for perl and perl-related things, but as a generic markup for plain text for other documentation purposes, forget it. Another example of asciidoc I use in my non-fvwm related projects is wikitext (Text::WikiText on CPAN to be more specific, maintained by me). I'm just wary of (excuse my language here) pissing over the people who put so much effort into the current docbook stuff. Exactly the same feelings. My webshite (sic) uses txt2tags [1] which has some advantages over asciidoc in that the markup is a little simpler, and unlike asciidoc, doesn't impose certain restrictions for templates (which expose limitations in docbook itself). I'm going to bite the bullet and after having finalised fvwm-convert-2.6 (which is all but done for review -- hopefully by the end of this weekend) I will turn my attentions to looking at what we might do about the documentation process [2]. -- Thomas Adam [1] http://txt2tags.sourceforge.net/ [2] I am not suggesting we do anything about it for 2.6.0, but I am sure I can handle stabilising 2.5.X and future work for now, albeit lightly. ;)
Re: Removing things from FVWM CVS.
On 14 Mar 2009 15:34:52 +, Thomas Adam wrote: 2009/3/14 Mikhael Goikhman m...@homemail.com: [...] One of the examples of a pragmatical asciidoc that may be considered is POD (Plain_Old_Documentation article in Wikipadia). Well, all perl documentation in fvwm is already in POD, and the corresponding html is generated from it. That's one possibility but very inflexible. No, we're talking about the manpage here -- and I wouldn't want to see POD used as a basis for it. I use POD on a daily basis; it's fine for perl and perl-related things, but as a generic markup for plain text for other documentation purposes, forget it. I would never force POD myself although some people write whole books in it... My point was just to demonstrate two text-based formats of my choice that are designed to be convertable to HTML and Latex. Another example of asciidoc I use in my non-fvwm related projects is wikitext (Text::WikiText on CPAN to be more specific, maintained by me). I'm just wary of (excuse my language here) pissing over the people who put so much effort into the current docbook stuff. Exactly the same feelings. My webshite (sic) uses txt2tags [1] which has some advantages over asciidoc in that the markup is a little simpler, and unlike asciidoc, doesn't impose certain restrictions for templates (which expose limitations in docbook itself). I'm going to bite the bullet and after having finalised fvwm-convert-2.6 (which is all but done for review -- hopefully by the end of this weekend) I will turn my attentions to looking at what we might do about the documentation process [2]. I suggest you to show the whole specs before you start this work, and to get at least the Dominik's approval, so this work is not lost again. In any case I prefer others to decide on the documentation source format. For some reason I was under impression Dominik approved the docbook thingy before it was implemented or at least had no objection to it... Regards, Mikhael.
