On 02 Nov 2002 11:26:30 +0100, Dominik Vogt wrote: > > > I am not sure what this means exactly, but this does not help Chris > > McCarthy, he wants grouping not sorting. > > Actually, I see no difference between "sorting" and "grouping".
Different groups may be delimited or placed in submenus. > > You don't need to change any fvwm code to implement what Chris wants. > > Except the menu code to allow different item text colours. He said a better solution would be to use submenus. :) > > Currently a module that does this using perllib should be about 50 lines. > > It will be 30 lines (mostly grouping/sorting entries by class/resource > > and printing the main windowlist menu and its submenus) when automatical > > trackers will be ready. I will write such module as a test case later. > > The thought of moving the WindowList functionality into a simple > script is appealing. But I suspect that we will never be content > with the limited information that goes over the module interface. Actually, the script will not be simple if it should implement all WindowList options. Especially if this is a shell script. I fully agree that the module interface is limited, it should be enhanced and in some cases corrected. Still, it is pretty powerful already. What is the script interface alternative you suggest? Does it use 2 pipes, in and out, just like a module? I know what you want. You want bashlib or maybe zshlib for writting fvwm modules in sh language. Unfortunately, sh is not a programming language. It depends on unix utilities that vary on different unices, even sed/awk. I would like to help writting such library, but it is just impossible. Contrary to this, you may use perl that works equally on all systems, even on non-unix. > Okay, I see one very important issue here. On one hand we have > the wish of the users to have more control over the WindowList (or > other features). On the other hand we have the module interface > and the perl lib. Now, these two do not fit together very well: > > - The module interface is intended for programmers, not users. > - You can not rely on a working perl installation. > - Only few users can program perl scripts (not me). Writting perl is not needed any more than writting C to use FvwmButtons. > - /bin/sh and certain unix commands are available on every > system. Do you agree to start to use an ancient sh instead of zsh, and non GNU utilities (I always miss the most useful options)? > - The knowledge of writing shell scripts is much more widespread. Sorry, I can't agree with this one. I am sure more people program C/C++ and Perl than sh. It is also the most ineffective and the less powerful. I am also sure almost noone can write really portable large shell scripts, maybe except for autoconf developers. And autoconf developers moved to perl themselves, because text manipulation in sh is much more obscure. Automake developers always used perl for processing Makefile.am. > So, in my eyes the "perl module" approach is not for the > typical do-it-yoursef user but for developers and very experienced > users/hackers. In addition, I won't be able to help people > implementing their perl scripts because I never learned perl (and > I don't want to because of its weird syntax). It takes years to become a perl expert, I know. But I am sure every programmer familar with the module interface may learn the basics of Perl and OOP to start to use perllib. I am willing to explain what test modules in tests/perl/module-* do to everyone who wants to learn. > The big question is: how can we provide a powerful do-it-yourself > interface to the intermediate to advanced shell user? A solution may be to maintain a powerful module for every task with all options users may want, so they should just choose the most suitable. Or a user may get the code and tweak it a bit (replace sort order). Another solution may be to enable parts of the configuration to be shell commands (sorting function?). But it still will be a perl or C written module that just passes the relevant input to a shell script and reads and incorporates the output. This may be possible for very simple cases only, and it can't be generic, because the input/output format is very specific. Regards, Mikhael. -- 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]
