albrecht_at_auto.tuwien.ac.at (Albrecht Kadlec) writes:
> how about giving a function name as an argument to FvwmWinlist.
> This Function would then be called with the selected window.
>
> One could then use FvwmWinList as a generic Selection mechanism for any
> kind of operation (focus as well as close, kill, ...)
>
> albrecht
First off, I think that this discussion has migrated from talking about
the builtin WindowList, to the module FvwmWinList. They are two
different things. If people confuse them, it causes confusion to
spread. If I'm confused, then hopefully my confusion will be contained
here.
Before hacking on FvwmWinList for all of this, I'd like to suggest that
interested people check out the latest release of FvwmIconMan
(
ftp://mahler.cs.arizona.edu/pub/FvwmIconMan/FvwmIconMan-0.7.tar.gz, and
in the next fvwm2 release whenever that happens) I've added the ability
to run transiently with this in mind. If you like it, cool. If you
don't, then you've made your job slightly easier by trying and
discarding one possible way to do things (I also wouldn't mind
constructive criticism).
Just so people know, I don't have anything against FvwmWinList. While
similar, the two programs are very different, and while I like the
differences in FvwmIconMan's favor, others may (and surely will) not. If
niftiness gets added to FvwmWinList, then you can be sure I'll be
watching with curiosity how it gets done, and will freely admit to
copying it. But, in this case, I think that you might look towards what
I've been doing. Making a program more configurable is always a slippery
slope, since once you open the door to new features, it sparks ideas for
ways to make them more general, logical, powerful, etc. FvwmWinList will
be no different, and since I've been sliding down that slope for some
time, it would make sense to check out any mistakes I've made. For
example, when adding the ability to bind arbitrary functions to the
selection of a window in FvwmWinList, the logical next step is to want
to be able to bind various functions to various types of events, and
then you may want functions that modify the state of the window list,
and then keeping control over the syntax starts taking some mental
effort.
I think that adding a functional parameter to WindowList makes good
sense though, but I think that extending it much further would lead to
the duplication of work in two other modules, and would violate the
basic priciple of modularity in fvwm.
Here's how I see the world of window lists in fvwm:
WindowList: small, guaranteed to work, lightweight, requires minimal
amount of thought from Chuck Hines.
FvwmWinList: more heavyweight. Mainly useful as a transient module.
FvwmIconMan: highly configurable. No point in using it if you're just
going to configure it to act like WindowList of
FvwmWinList. Until now only usable as a long running
module, but now can run transiently. On my machine at
least, it seems to start up faster than FvwmWinList, but
I wouldn't expect that to be universal.
--
Brady Montz
bradym_at_cs.arizona.edu
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to majordomo_at_hpc.uh.edu.
To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
Received on Tue Aug 13 1996 - 12:40:27 BST