Re: FVWM: Idea: Improved Window List Menu

2002-11-15 Thread Mikhael Goikhman
On 12 Nov 2002 21:22:21 -0500, Richard Lister wrote:
 
 Mikhael Goikhman [EMAIL PROTECTED] wrote on Sat, 9 Nov 2002 09:44:44 +:
  
I will also reformat it to be more like FvwmPerl.
   
   Fine.
  
  At least here I guessed your answer correctly. :)
 
 I just downloaded the cvs snapshot and found you switched to 8-space
 tab indentation, which was the worst thing I could have imagined :-)
 Ah well, I suppose indentation styles are a bit of a religious war ...

This is not really correct. I don't use 8-spaces, I use one tab. Unlike
our C code that requires TAB to be 8 spaces, our perl code is properly
structured to allow any TAB size. Use 4 spaces for TAB if you like this,
I use 3 or 8. Just please remember to write a properly structured code
(no spaces for indentation, no tabs in the middle of line) not to break
this TAB size freedom. I know, it is difficult with emacs...

  Ok, I did a lot of small changes, every change has its reason, take a look.
 
 I think you broke the drawminiicon option, but I don't know this idiom:
 
 $foo = 0 + !!$1;

It only veryfies that $foo ends up to be a number (you compare this with
numbers later, right?). But I forgot this is not a boolean (may be 2 as
well). I will fix this.

 Otherwise, I like all the changes you made.
 
  The module still misses some configurability like sorting, automatical
  grouping, submenus, configurable format, class/resource/name resolution).
  But it is a good start to test future trackers.
 
 I've added title/icon/class/resource matching with a syntax like:
 
   *FvwmWindowLister: Show resource = Galeon|Navigator|mozilla-bin
 
 You can get the new version at:
 
   http://cns.georgetown.edu/~ric/software/fvwm/FvwmWindowLister
 
 I even added emacs mode settings for your indentation style :-)

I don't think these are the right settings, they insert 4 spaces.
In fact, I think the only way to configure emacs to do anything useful
is to disable auto-indentation and insert real tabs on tab press.

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]


Re: FVWM: Idea: Improved Window List Menu

2002-11-15 Thread Richard Lister

Mikhael Goikhman [EMAIL PROTECTED] wrote on Fri, 15 Nov 2002 09:45:20 +:
 
 This is not really correct. I don't use 8-spaces, I use one tab. Unlike
 our C code that requires TAB to be 8 spaces, our perl code is properly
 structured to allow any TAB size. Use 4 spaces for TAB if you like this,
 I use 3 or 8. Just please remember to write a properly structured code
 (no spaces for indentation, no tabs in the middle of line) not to break
 this TAB size freedom. I know, it is difficult with emacs...

OK, I think I understand what you mean. Use one tab for indentation, then
the programmer can choose to have their editor display tabs as
equivalent to whatever number of spaces they prefer. I agree this
is good and will switch to using this.

I think it ought to be straightforward with emacs once I figure it out.


 It only veryfies that $foo ends up to be a number (you compare this with
 numbers later, right?). But I forgot this is not a boolean (may be 2 as
 well). I will fix this.

Don't worry, that option has gone away, replaced by the choice of
%M or %m in ItemFormat.


  I even added emacs mode settings for your indentation style :-)
 
 I don't think these are the right settings, they insert 4 spaces.
 In fact, I think the only way to configure emacs to do anything useful
 is to disable auto-indentation and insert real tabs on tab press.

I'm confused as to what is happening. I screwed up the mode
settings, but they should have made emacs display the tabs as
equivalent to 8 spaces not 4. The file I put up definitely has
single tabs for indentation. Could it have got corrupted somewhere?

Anyway, I've got some more changes to add after the weekend. I'll
send those as a patch against CVS and it will hopefully be right
this time.

Thanks for the help.
Ric


Richard J Lister
Dept of Neuroscience
Georgetown University Medical Center
http://cns.georgetown.edu/~ric/
--
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]


Re: FVWM: Idea: Improved Window List Menu

2002-11-14 Thread Richard Lister

Mikhael Goikhman [EMAIL PROTECTED] wrote on Thu, 14 Nov 2002 05:19:55 +:

 Subject: Re: FVWM: Idea: Improved Window List Menu

 It is more convenient to get unified patches against FvwmWindowLister.in,
 and not autogenerated FvwmWindowLister. Something like:
 
   cvs diff -u FvwmWindowLister.in FvwmWindowLister.patch
 
 or just (if you have a good .cvsrc):
 
   cvs diff FvwmWindowLister.patch

OK, I thought that might be the case. I'm not really familiar with
cvs and autoconf but it seems pretty straightforward.

Ric


Richard J Lister
Dept of Neuroscience
Georgetown University Medical Center
http://cns.georgetown.edu/~ric/
--
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]


Re: FVWM: Idea: Improved Window List Menu

2002-11-13 Thread Richard Lister

I've added configurable menu formatting to FvwmWindowLister
and removed the DrawPosition and DrawMiniIcon options.

It's at

  http://cns.georgetown.edu/~ric/software/fvwm/FvwmWindowLister

Let me know if there's a better way to submit this stuff.

Cheers
Ric


Richard J Lister
Dept of Neuroscience
Georgetown University Medical Center
http://cns.georgetown.edu/~ric/
--
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]


Re: FVWM: Idea: Improved Window List Menu

2002-11-13 Thread Mikhael Goikhman
On 13 Nov 2002 20:44:43 -0500, Richard Lister wrote:
 
 I've added configurable menu formatting to FvwmWindowLister
 and removed the DrawPosition and DrawMiniIcon options.
 
 It's at
 
   http://cns.georgetown.edu/~ric/software/fvwm/FvwmWindowLister
 
 Let me know if there's a better way to submit this stuff.

I will comment on your other message later.
It is more convenient to get unified patches against FvwmWindowLister.in,
and not autogenerated FvwmWindowLister. Something like:

  cvs diff -u FvwmWindowLister.in FvwmWindowLister.patch

or just (if you have a good .cvsrc):

  cvs diff FvwmWindowLister.patch

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]


Re: FVWM: Idea: Improved Window List Menu

2002-11-12 Thread Richard Lister

Mikhael Goikhman [EMAIL PROTECTED] wrote on Sat, 9 Nov 2002 09:44:44 +:
 
   I will also reformat it to be more like FvwmPerl.
  
  Fine.
 
 At least here I guessed your answer correctly. :)

I just downloaded the cvs snapshot and found you switched to 8-space
tab indentation, which was the worst thing I could have imagined :-)
Ah well, I suppose indentation styles are a bit of a religious war ...


 Ok, I did a lot of small changes, every change has its reason, take a look.

I think you broke the drawminiicon option, but I don't know this idiom:

$foo = 0 + !!$1;


Otherwise, I like all the changes you made.


 The module still misses some configurability like sorting, automatical
 grouping, submenus, configurable format, class/resource/name resolution).
 But it is a good start to test future trackers.

I've added title/icon/class/resource matching with a syntax like:

  *FvwmWindowLister: Show resource = Galeon|Navigator|mozilla-bin

You can get the new version at:

  http://cns.georgetown.edu/~ric/software/fvwm/FvwmWindowLister

I even added emacs mode settings for your indentation style :-)

Cheers
Ric


Richard J Lister
Dept of Neuroscience
Georgetown University Medical Center
http://cns.georgetown.edu/~ric/
--
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]


Re: FVWM: Idea: Improved Window List Menu

2002-11-09 Thread Mikhael Goikhman
On 06 Nov 2002 17:11:48 -0500, Richard Lister wrote:
 
 Mikhael Goikhman [EMAIL PROTECTED] wrote on Wed, 6 Nov 2002 21:11:44 +:
 
  Subject: Re: FVWM: Idea: Improved Window List Menu
 
  On 05 Nov 2002 19:06:33 -0500, Richard Lister wrote:
   
   I've added optional page and desk-level resolution and some
   documentation to the script. I've attached it here.
  
  Nice, it is already pretty configurable. I see several possible
  enhancements, not urgent though. And it is persistent. I thought
  more about a transient module (yes, slower), this may be an option.
 
 I originally coded it as transient, and that was acceptably
 fast on a 600MHz PIII. I never tried it on a really slow machine.
 Persistent just seemed a neater solution for some reason, maybe because
 I use the menu all the time as an alternative to using up screen
 space on iconman or icons. The nice thing about using a fvwm menu
 is the automatic keybindings, so I do Menu G to find my galeon
 windows, for example.

Yes, I find a menu to be very useful too. I usually don't use FvwmIconMan
even though I tried to use it, I find pager to be very useful and if there
are a lot of windows WindowList with SortByClass may help to identify them
quickly if you use good mini icons.

  FvwmLister is a really good name for me, but maybe FvwmWindowLister?
  You would probably prefer FvwmRichardLister, but this is close enough. :)
 
 Yeah, it was just a play on my name :-) It might be nice to name it
 something like FvwmPerlWinList or something very descriptive.
 FvwmWindowLister is too similar to FvwmWinList.

Hmm...

I returned to this message to say that I added the module and discovered
that I somehow missed anything except for the first page of this message.
I had a slow internet connection when I first read this message.

So, what should we do now when I coded it everywhere as FvwmWindowLister?
For me this name hints that it is a transient listing, so it's a good name.

  I will also reformat it to be more like FvwmPerl.
 
 Fine.

At least here I guessed your answer correctly. :)

  There will be a lot of decisions to make for trackers and you may help.
  Just to give you another idea. A user may implement his own trackers.
 
 This seems very cool. I'll take a look at the stuff in CVS in a
 couple of days and see if I have any useful input for you.

Ok, I did a lot of small changes, every change has its reason, take a look.

The module still misses some configurability like sorting, automatical
grouping, submenus, configurable format, class/resource/name resolution).
But it is a good start to test future trackers.

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]


Re: FVWM: Idea: Improved Window List Menu

2002-11-06 Thread Mikhael Goikhman
On 05 Nov 2002 19:06:33 -0500, Richard Lister wrote:
 
 I've added optional page and desk-level resolution and some
 documentation to the script. I've attached it here.

Nice, it is already pretty configurable. I see several possible
enhancements, not urgent though. And it is persistent. I thought
more about a transient module (yes, slower), this may be an option.

FvwmLister is a really good name for me, but maybe FvwmWindowLister?
You would probably prefer FvwmRichardLister, but this is close enough. :)

I will also reformat it to be more like FvwmPerl.

 As far as I understand it the trackers will make most of the stuff
 I've done in handlers redundant. Is that correct?

Yes, in theory your module will not need to handle any of your current 13
fvwm events itself, except for M_STRING commands. It will just load 3
trackers instead. In practive, for now M_ICONIFY/M_DEICONIFY will be
needed too until perllib may reliably parse window flags (Sticky/Iconic)
given in M_CONFIGURE_WINDOW.

There will be a lot of decisions to make for trackers and you may help.
Just to give you another idea. A user may implement his own trackers.
For example, ColorsetForcer, something that verifies that bg of Colorset
5 is always green or synchronizes 2 colorsets when one is changed.
Another example may be VisibleWindows that forces windows to never be
fully off the screen. Then a user may reuse these user defined trackers
in his numerous modules by adding this (only the first line is needed):

  my $tracker = $module-track(VisibleWindows, offset = 10);
  print Recovered old window: $_\n foreach $tracker-recovered;
  $tracker-trap(sub { print Recovered new window: $_[0]\n; });

Or a one time tracker that recovers the lost windows only once:

  my $grabber = $module-grab(VisibleWindows, offset = 10);
  print Recovered old window: $_\n foreach $grabber-recovered;

As you see, this implementation not only recovers windows internally (by
sending Move commands), but also optionally reports about such windows.
The problem is to decide what is the synchronous part (when these calls
return) and what is asynchronous. This is individual for every tracker.
There is no any problem if different trackers or a user himself decide to
listen to the same packets. Trackers are fully transparent for a user,
they just do their work (in your case they automatically collect an info).

 A bug in my script ... sticky windows are only listed on the desk
 where they originated (were made sticky). This is not a problem
 when changing page, as there seems to be a M_CONFIGURE_WINDOW packet
 sent for each window in that case and I set the desk from that handler.
 But these packets are not send for a change desk event. Why is that?
 I could probably get round this by doing a Send_Windowlist when
 M_NEW_DESK is caught, but that seems clunky :-)

I have no debts that M_NEW_PAGE / M_NEW_DESK are inconsistent and pretty
unusable sometimes. The sooner we unite these to one M_NEW_DESK_PAGE the
better. A side note, the PageInfo tracker API will probably not be changed
when such packet change happens, just its internal implementation.

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]


Re: FVWM: Idea: Improved Window List Menu

2002-11-06 Thread Richard Lister

Mikhael Goikhman [EMAIL PROTECTED] wrote on Wed, 6 Nov 2002 21:11:44 +:

 Subject: Re: FVWM: Idea: Improved Window List Menu

 On 05 Nov 2002 19:06:33 -0500, Richard Lister wrote:
  
  I've added optional page and desk-level resolution and some
  documentation to the script. I've attached it here.
 
 Nice, it is already pretty configurable. I see several possible
 enhancements, not urgent though. And it is persistent. I thought
 more about a transient module (yes, slower), this may be an option.

I originally coded it as transient, and that was acceptably
fast on a 600MHz PIII. I never tried it on a really slow machine.
Persistent just seemed a neater solution for some reason, maybe because
I use the menu all the time as an alternative to using up screen
space on iconman or icons. The nice thing about using a fvwm menu
is the automatic keybindings, so I do Menu G to find my galeon
windows, for example.



 FvwmLister is a really good name for me, but maybe FvwmWindowLister?
 You would probably prefer FvwmRichardLister, but this is close enough. :)

Yeah, it was just a play on my name :-) It might be nice to name it
something like FvwmPerlWinList or something very descriptive.
FvwmWindowLister is too similar to FvwmWinList.


 I will also reformat it to be more like FvwmPerl.

Fine.


 There will be a lot of decisions to make for trackers and you may help.
 Just to give you another idea. A user may implement his own trackers.

This seems very cool. I'll take a look at the stuff in CVS in a
couple of days and see if I have any useful input for you.


Cheers
Ric


Richard J Lister
Dept of Neuroscience
Georgetown University Medical Center
http://cns.georgetown.edu/~ric/
--
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]


Re: FVWM: Idea: Improved Window List Menu

2002-11-05 Thread Richard Lister

Mikhael Goikhman [EMAIL PROTECTED] wrote on Sat, 2 Nov 2002 03:08:09 +:

 Subject: Re: FVWM: Idea: Improved Window List Menu

 On 01 Nov 2002 18:04:38 -0500, Richard Lister wrote:
  
  As I mentioned in another thread, I've already implemented this.
  I ported it to the 2.5.4 perllib, which was very straightforward.
  
  Let me know if you want me to post it. I've included a screenshot
  of the menu generated.
 
 Actually, I will need to write a lot of small modules in addition to the
 current 6 in cvs to test trackers, I may use your module as a test case.


Hi Mikhael

I've added optional page and desk-level resolution and some
documentation to the script. I've attached it here.


  Is there any info online about the automatic trackers you are
  implementing? 
 
 Such info is not even in my head yet. I only know that this should be
 somewhat powerful and easy to use and extend. :)

As far as I understand it the trackers will make most of the stuff
I've done in handlers redundant. Is that correct?


 Take a look at TrackerFactory.pm in cvs or ftp.fvwm.org to get some ideas.

Will do this later.


 My plan is to get some module and see how trackers may help it.
 For example, your module may use 3 trackers, WindowList (with wininfo
 and probably icons options), ConfigInfo and PageInfo. Other trackers
 may be: Colorsets, GlobalInfo and stack option to the WindowList.
 Nothing is final at all, even the names tracker and grabber.
 
 You are as the library user may help with ideas and design.
 If you want to participate, install cvs.
 Just please keep in mind that this is not my first priority for November.

Ditto on November :-)  But I'll take a look when I get a bit of time.


A bug in my script ... sticky windows are only listed on the desk
where they originated (were made sticky). This is not a problem
when changing page, as there seems to be a M_CONFIGURE_WINDOW packet
sent for each window in that case and I set the desk from that handler.
But these packets are not send for a change desk event. Why is that?
I could probably get round this by doing a Send_Windowlist when
M_NEW_DESK is caught, but that seems clunky :-)

Cheers
Ric


Richard J Lister
Dept of Neuroscience
Georgetown University Medical Center
http://cns.georgetown.edu/~ric/

#!/usr/bin/perl -w

=head1 VERSION

  $Id: FvwmLister.pl,v 2.2 2002/11/05 23:57:10 ric Exp $

=head1 AUTHOR

  Ric Lister http://cns.georgetown.edu/~ric/

=head1 DESCRIPTION

  Substitute for fvwm builtin WindowList, but written in Perl
  and easy to customize. Unlike FvwmIconMan or FvwmWinlist the
  module does not draw its own window, but instead creates a
  fvwm menu and asks fvwm to pop it up.

  By defining a set of regular expressions in @show, windows may
  be sorted into sections based on the regexp matching their
  title.

  Similarly, matches in @dontshow will be excluded from the list.

  Any windows not matching an element of @show or @dontshow will
  be placed in the last section of the menu.

=head1 USAGE

  Place this in e.g. your .fvwm2rc StartFunction

Module FvwmLister

  Invoke the menu from .fvwmrc like this, for example:

Key Menu A N SendToModule FvwmLister Root c c

  The arguments are any valid Menu arguments.

  Set module options, e.g.:

*FvwmLister: Show ^Galeon|^Netscape
*FvwmLister: Show ^emacs

  will define two sections containing respectively browsers, and emacs.
  Number of sections is unlimited. The strings are perl regular
  expressions that will be evaluated in m// context. See perlre(1).

  Similarly:

*FvwmLister: DontShow ^Fvwm
*FvwmLister: DontShow ^gkrellm

  will cause the menu to ignore windows with title beginning Fvwm or
  gkrellm.

  Other options:

*FvwmLister: OnlyIconic {on|off}## show only iconified windows
*FvwmLister: MiniIcon {0|1|2}   ## show mini icon: 0=never,
## 1=always, 2=icon windows only
*FvwmLister: AllDesks {on|off}  ## show windows from all desks
*FvwmLister: AllPages {on|off}  ## show windows from all pages
*FvwmLister: ShowPosition {on|off}  ## show window position in ()
*FvwmLister: Maxlen 32  ## max length in chars of entry
*FvwmLister: Menu foobar## name of menu to popup
*FvwmLister: MenuStyle foobarstyle  ## name of MenuStyle to apply
*FvwmLister: Debug {-1,0,1,...} ## level of debug info output

=cut

## default user options
my $opt = {
  onlyiconic   = 0,## only list iconified windows
  mini_icon= 2,## 0=never, 1=always, 2=iconic windows only
  alldesks = 0,## list windows on all desks
  allpages = 0,## list windows on all pages
  showposition = 1,## show window position
  maxlen   = 32,   ## max chars for window name in menu
  menu = Lister, ## name of fvwm menu to create
  menustyle= Lister, ## name of fvwm menu style to use
};

## get size of your screen
my $screen

Re: FVWM: Idea: Improved Window List Menu

2002-11-05 Thread Richard Lister

  You don't need to change any fvwm code to implement what Chris wants.
 
 Except the menu code to allow different item text colours.


This, by the way, would be a really nice feature :-)

Ric

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


Re: FVWM: Idea: Improved Window List Menu

2002-11-02 Thread Dominik Vogt
On Fri, Nov 01, 2002 at 10:44:11PM +, 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]


Re: FVWM: Idea: Improved Window List Menu

2002-11-01 Thread Mikhael Goikhman
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.

  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.

You don't need to change any fvwm code to implement what Chris wants.
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.

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]


Re: FVWM: Idea: Improved Window List Menu

2002-11-01 Thread Richard Lister

 I am not sure what this means exactly, but this does not help Chris
 McCarthy, he wants grouping not sorting.
 
 You don't need to change any fvwm code to implement what Chris wants.
 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.

Mikhael

As I mentioned in another thread, I've already implemented this.
I ported it to the 2.5.4 perllib, which was very straightforward.

Let me know if you want me to post it. I've included a screenshot
of the menu generated.

Is there any info online about the automatic trackers you are
implementing? 

Ric


Cheers
Ric

Richard J Lister
Dept of Neuroscience
Georgetown University Medical Center
http://cns.georgetown.edu/~ric/



Re: FVWM: Idea: Improved Window List Menu

2002-11-01 Thread Mikhael Goikhman
On 01 Nov 2002 18:04:38 -0500, Richard Lister wrote:
 
 As I mentioned in another thread, I've already implemented this.
 I ported it to the 2.5.4 perllib, which was very straightforward.
 
 Let me know if you want me to post it. I've included a screenshot
 of the menu generated.

Actually, I will need to write a lot of small modules in addition to the
current 6 in cvs to test trackers, I may use your module as a test case.

 Is there any info online about the automatic trackers you are
 implementing? 

Such info is not even in my head yet. I only know that this should be
somewhat powerful and easy to use and extend. :)

Take a look at TrackerFactory.pm in cvs or ftp.fvwm.org to get some ideas.

My plan is to get some module and see how trackers may help it.
For example, your module may use 3 trackers, WindowList (with wininfo
and probably icons options), ConfigInfo and PageInfo. Other trackers
may be: Colorsets, GlobalInfo and stack option to the WindowList.
Nothing is final at all, even the names tracker and grabber.

You are as the library user may help with ideas and design.
If you want to participate, install cvs.
Just please keep in mind that this is not my first priority for November.

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]