On Mon, Nov 04, 2002 at 05:50:34AM +0000, Mikhael Goikhman wrote:
> On 03 Nov 2002 23:28:04 +0100, Dominik Vogt wrote:
> >
> > On Sat, Nov 02, 2002 at 09:04:24PM +0000, Mikhael Goikhman wrote:
> > >
> > > Writting perl is not needed any more than writting C to use FvwmButtons.
> >
> > Then how do I write my own sorting algorithm using perllib without
> > writing perl?
>
> The question is why to require a user to write something non trivial as a
> new window sorting algorithm instead of just implementing it for a user.
In this specific case, because many users want a different sorting
algorithms.
> I.e. you (a user) request a new module option, I (maintainer) add it.
> Or you add it yourself if this is just several perl lines.
>
> I see only 2 good alternatives, adding a new option (easiest for a user)
> and writting a new module (the most powerful).
>
> Options may be configurable, not just boolean flags, see, for example,
> "man FvwmIconMan | grep SortWeight".
>
> > I have to think more about this. It would not be difficult to
> > make up an ad hoc interface that prints the available information
> > into stdin of a shell script, but I wonder how useful it would be.
> > Let's assume we can access every style flag and each member of the
> > window structure with
> >
> > $[windowstruct_flag.is_transient]
> > $[windowstruct_member.layer]
> > $[windowstyle_flag.do_start_iconic]
> > ...
> >
> > (I am still thinking about a good solution to do this). And let
> > us ignore the problems arising by exporting the whole window
> > structure as an external interface.
> >
> > With that, we could add a format string that generates output and
> > a command that processes it to the WindowList command:
> >
> > WindowList CustomSort \
> > Format=`$n $w $[page.nx] $[page.ny]` \
> > Command=`/bin/sh -c 'sort -t . -k 2,2 | \
> > read A B C D; \
> > /bin/echo \"$A\t${C}x${D}\" WindowId $w WindowListFunc'`
> >
> > (Ignore all the portability issues and bugs in the command).
> > Fvwm would print a line according to the format for each window
> > and pass that as input to a script.
>
> I can't stop you from doing this. but for me this is not good. :)
>
> 1) a lot of code is added and little is gained (as compared to modules)
No, it's very little code. Just one additional option with a bit
of inter process communication. And I will extend vcariable
expansion independently of any WindowList features anyway.
> 2) this still does not do grouping (with Nop delimeters or/and submenus)
Not my example, but it's trivial to enhance the script.
> 3) a user should spend an effort for parsing complex input in a language
> not designed for data manipulations
But the unix shell command set is exactly designed for that case:
simple filtering and text manipulation tasks. It's not very
versatile when it comes to multiple line operations, though.
> 4) this is not extendible, you patched WindowList command only
> 5) the format is too bound to the internal structures to give it to
> a user to parse.
Yes, but please see is as an ad hoc example. Once I fugre out how
to process style names via a table, the same name can be used
in various features:
$[Style.Sticky]
$[State.Sticky]
Next (Sticky)
Style foobar Sticky
...
> Note, the module library parses this for a user and
> gives him already meaningfully named structures.
> 6) I think the real working example will be much more complex (even if
> we do not pass hundreds of flags, only window names)
>
> Now, please attention, here is a complete module (will work soon when
> trackers are done) that creates WindowList sorted by window class and
> shows user defined fields. Try to read it like English.
>
> $module = new FVWM::Module;
>
> @windows = $module->grab('WindowList')->windows;
> @windows = sort { $a->res_class cmp $b->res_class } @windows;
>
> $module->send("DestroyMenu MyWindowList");
> $module->send("AddToMenu MyWindowList");
> foreach $window (@windows)
> {
> $w = $window->win_id;
> $i = $window->icon_name;
> $r = $window->res_name;
> $module->send("+ '$r: $i' WindowId $w Iconify")
> }
> $module->send("Menu MyWindowList");
>
> I don't know what may be simplier than this. You don't need to modify any
> fvwm code, because module interface already supplies all the information.
>
> And if you need to create submenus, you just first group windows
> by their class, i.e. add this code after the sort line above:
>
> while (@windows)
> {
> @class_windows = shift @windows;
> $current_class = $class_windows[0]->res_class;
> push @class_windows, shift @windows
> while $current_class eq $windows[0]->res_class;
>
> # create submenu for @class_windows, like shown above
> }
>
> Any chance you just use perl to write custom modules? :)
Maybe you misunderstand my whole point. It's not about if *I* can
write such a module (or shell script) or not. And I do not doubt
that the perllib allows relatively simple access to much of the
internal window information. My point is that very few people
are able and willing to write your example script. So, this is
just something we could write for others but can hardly ask them
to write it themselves. But then it would not help much to reduce
our work spent with maintenance and user support.
Bye
Dominik ^_^ ^_^
--
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]
