About all this rat discussion. I think people are being a bit harsh about
Chuck. I only have one nit about 2.0.45 (after I quit netscape I can't use my
number pad to switch pages like I usually do until I switch pages using
FvwmPager). Other than that, I certainly haven't been inconvienanced at all by
there not being a new fvwm version. I maintain a module for fvwm (FvwmIconMan)
and I've been happily releasing new versions of it over the last few months
that people can use without having to wait for a new fvwm. This is cool. It's
not something that the competitors can claim, since they don't have modules.
Now, as for possible new directions for fvwm, or writing a new window manager,
here are my thoughts. I've been tinkering with this for the last few months,
and if I had the time it's something I would really like to do. But there's
that pesky matter of a thesis ...
To me fvwm has two cool features: modules and ICCCM compliance. It's the only
viable window manager with the first, and it seems heads and shoulders above
most others in the second.
A better window manager (to me) would take the module idea to the logical
extreme:
1. The current fvwm type modules could benefit from a more symmetrical,
tightly coupled interface. If modules had controlled access to fvwm state,
like the window list or the window decorations, they could do cool stuff.
2. Other things could be modularized as well. I envision modules for every way
that fvwm interacts with it's environment: a config module which handles
reading the .fvw2rc (having configurability and choice here would make it
easy for someone to write a module which propogates configuration info from
one login session to the next, for example), a module which handles window
decorations (would remove the whole reason for fvwm95's existance), a
module which handles policy decisions (what's encoded in the Style
commands), a module which interacts with the underlying windowing system
(boy it would be cool to use fvwm on windows, or you could have nested
window managers like plan 9), etc.
3. A major nit for me now is how the cool sexy pixmap code which handles the
new borderstyle stuff is not usable by modules (like FvwmIconMan and
FvwmButtons). My plan is to fix this after fvwm2 is officially released, as
it would require some major code rewriting. In an ideal world it would be
nice if there was some module responsible for how everything looked, and
everything else, fvwm and modules included, could rely on it for such
things.
The obvious fear is "Oh god, it's Mach!" This obviously would be a concern,
but I suspect that's not necessarily the case. If it turns out that everybody
uses all the same modules, and having all these modules doesn't result in
meaningful choice, then it would suck because you pay the penaltly without
getting anything. If however, this supremo modularity allows for lots of
options, then it's a win. People could use what they want and not have to have
the rest. We wouldn't have people running off and creating fvwm95 just because
they want to have different titlebars and a few extra commands. I think the
Winlist/FvwmIconBox/FvwmWinList/FvwmIconMan situation is a good
example. People can use which one they want without the memory penalty of
having all three built in, and I can make changes at will to FvwmIconMan
without asking anybody's permission. BUT, when the pixmap button/titlebar
stuff was being added, it really gummed all sorts of things up trying to
shoehorn it into fvwm.
I don't care about whether this hypothetical window manager looks as good as
Enlightenment. I only care that somebody else could write a few modules that
would make it look as good.
If this manager were to be written, whether as fvwm 3.0 or as a totally new
beast, it's probably unwise to use too much of the current fvwm code. It's
just not up to it.
If anybody sees potential here, and knows how to program and wants to help,
I'd be happy to talk about it more.
--
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 Mon Jul 07 1997 - 16:47:55 BST