Dan Espen nawypisowywał(a): >> As an end-user (not fvwm-hacker, so I'm not "tainted") I can say that >> the biggest "misdesign" in current FVWM code is the scripting engine. = >> It >> has this "I'm a never ending hack" look&feel. A true overflowing >> bucket'o'patches. > > Please, constructive comments only.
There was some constructive stuff further down (with an alternative "described" - I guess only a ready-to-apply patch could be more constructive). >> Employing a true scripting language (python maybe?) >> would make fvwm much easier to understand and script. It would also be >> a great opportunity to reduce the number of commands and clean it up. > > Feel free to use any language you want. > > FvwmCPP > FvwmM4 > FvwmPerl > PipeRead > FvwmCommand cpp and m4 are macro expanders, not real scripting languages. FvwmCommand, PipeRead and FvwmPerl are nice extensions, but only extensions, FvwmPerl isn't really easier to use, as it has a visible line separating "native perl" from "native fvwm" (yes, I've tried writing perl extensions and I noticed that it was much like calling FvwmCommand, only that you did it in a perl script). PipeRead/FvwmCommand has huge overhead problems (running a external command isn't really efficient). > Except when playing pysol, I don't have the python interpreter in > memory. I wouldn't be happy with a window manager that pulled an > interpreter into memory. It's just a library. Makes some of fvwm code obsolete, so the costs are reduced a bit. But that isn't that important. If fvwm would be able to do things that you can do in Python (or any other popular language) just as easily, I would be very satisfied. Pulling a external library with an interpreter is only a "possible solution". So is "rewriting the engine". But I believe that the second wouldn't give smaller code and would probably have more bugs (shorter devel-debug-cycle compared to a well-tested libperl or libpython, or lib<whatever>). Fvwm isn't really *that* good at saving memory[1], so I don't think it would brake any "fundamental fvwm rule" here. [1] - take the modules for instance. If saving ram would be such a high priority, then it should be possible to load FvwmButtons and then use it to create more than one container, perhaps in different areas of the screen. But no, if you want two containers you need to load two copies of FvwmButtons, even if 80% of that code could probably be shared (only config-related data is different). And fvwm modules are quite big already. -- \hoppke (Grzegorz Niewęgłowski) http://lubuska.zapto.org/~hoppke/ -- Visit the official FVWM web page at <URL:http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
