On Fri, Nov 01, 2002 at 10:44:11PM +0000, Mikhael Goikhman wrote:
> On 01 Nov 2002 15:59:54 +0100, Dominik Vogt wrote:
> > 
> > On Fri, Nov 01, 2002 at 12:53:56AM -0500, Chris McCarthy wrote:
> > > 
> > >   Now for my IDEA:  
> > >   
> > > When I click right mouse button, I get a menu of all active windows.
> > > What I would like to do is allow this menu to be sorted according to
> > > the name of the window in 1 or 2 ways:
> > > 
> > > 1.)   All windows with the same file extension or same name (ie xterm, or 
> > >   .c ) would be color-coded the same color.
> > >   
> > > 2.) Even better, the menu would include submenus, ie all windows with file
> > >   extensions ".c", then look under that list, etc.
> > 
> > What we really need is to allow calling an external program that
> > filters and sorts the windows and generates the labels of the menu
> > entries.
> 
> I really don't think this is what we need. Because you will need to pass
> to this external program everything you normally pass to a module for it
> to be flexible. At this point this program should be just a module.
> 
> Scripts are good when they get an input from other places like filesystem.
> Not when they can't be run without fvwm giving them an input.

Right.  All the necessary information must be passed to the
script.  This job is partially done by the module interface
already.

> > > Could these ideas be implemented in future (or present) versions of
> > > FVWM?
> > 
> > I can't promise how long it will take, but a generic soring
> > interface would save us a lot of future work.
> 
> 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".

> You don't need to change any fvwm code to implement what Chris wants.

Except the menu code to allow different item text colours.

> 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.

--

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).
 - /bin/sh and certain unix commands are available on every
   system.
 - The knowledge of writing shell scripts is much more widespread.

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).

The big question is:  how can we provide a powerful do-it-yourself
interface to the intermediate to advanced shell user?

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
--
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]

Reply via email to