On Sun, Mar 15, 2009 at 07:00:05PM +0000, 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
