Configuration Information [Automatically generated, do not change]:
uname output: SunOS coleco-sidewinder.mit.edu 5.8 Generic_108528-12 sun4u sparc
SUNW,Sun-Blade-100 Compiler: /usr/gcc/bin/gcc Compilation CFLAGS: -g -O2
prefix: /mit/windowmanagers
FVWM Version: 2.4.5
FVWM_MODULEDIR: /mit/windowmanagers/arch/sun4x_58/lib/X11/fvwm/2.4.5/fvwm
FVWM_DATADIR: /mit/windowmanagers/arch/sun4x_58/lib/X11/fvwm/2.4.5/fvwm
FVWM_USERDIR: unset
Hello,
I've just installed fvwm2.4 at my site, and wanted to send you a
report on my experience. The report has turned out to be rather
long -- you can read it or not, as you please. By the end I
explain why I think I can't afford to replace v2.2 with v2.4.
(I'm installing v2.4 alongside 2.2.)
I'm glad that there are people working on fvwm. I like using the
windowmanager. But I had some frustrations with this latest
version, and wish that I hadn't had them.
Broadly speaking, my frustration falls in two categories:
sysadmin's frustration with the build system, and end-user's
frustration with trying to upgrade to fvwm2.4.
My sysadmin frustration is relatively minor. Two points of the
build system were responsible for most of it. One was the fvwmbug
shell script, and the other was the awkwardness of trying to install
the program with the --program-suffix option to configure.
The fvwmbug shell script hardcodes the username of the user who
compiled fvwm2 into the script. This really should be
configurable. I don't want personal bug reports any more than
you want personal bug reports, and I should have the ability to
configure which address "local" bug reports go to. (I worked
around the issue by setting $USER to the target email address
during the build. Ick.)
The --program-suffix option would have been useful, because I wanted
to install this fvwm as "fvwm2.4" to prevent users from running it
accidentally. I couldn't use --program-suffix, though, because
it transforms the names of all of fvwm's modules in addition to
transforming the name of the fvwm2 binary. A module named
"FvwmPager.4" doesn't work, when the config file is trying to
run "FvwmPager". (I worked around this issue by hand-editing
fvwm/Makefile after running "configure" but before running
"make install". The "transform" variable I added worked, but I
wish I could have specified at the configure stage.)
On the bright side, I definitely appreciated the INSTALL.fvwm file.
It gave useful information about where components would end up when
installed, and saved me a lot of time that might otherwise have been
spent crawling through the Makefiles trying to divine how they
worked.
My end-user style of frustration came when I tried testing the new
fvwm2, to see how it would work for our users (who have been using
version 2.2.2 before now). I'm sad to say that most of them will
continue using 2.2.2 for the near future, because I don't have time
to handle the cost of upgrading them. The most problematic issue is
the config file changes, but another nuisance is fvwm's readiness to
scream "ERROR!" at users.
One backwards-incompatible change in the config files that bit me
is the change in how titlebar buttons are defined. My current
system.fvwm2rc file, used with fvwm 2.0 and 2.2, has lines of the form:
Key F6 WTSFI1357924680 M Move
I wanted M-F6 to always invoke Move, and the manpage explicitly
claimed that a context of "A" stood for "any context except for
title-bar buttons", so I included title-bar buttons in the Key
binding's context. In version 2.4, this Key binding has the
side-effect of *creating* all ten title-bar buttons. I can fix the
global system.fvwm2rc file by using a context of "A", but this won't
help users who have personal files based on modifications to the
system one. They will suddenly be faced with titlebars with too
many buttons.
They will also be faced with another nuisance: screaming <<ERROR>>
messages. Fvwm will yell ERROR at users who use xbm images.
("<<ERROR>> XpmReadFileToXpmImage failed"), at users who have Key
bindings for foreign-platform keys ("<<ERROR>> No such key: SunF37"),
or at users who use v2.2-style config files ("<<ERROR>> IconPath is
deprecated", and "<<ERROR>> Please replace 'GlobalOpts
MouseFocusClickDoesntRaise' with 'Style * MouseFocusClickRaisesOff'")
There's nothing wrong with config file changes, as long as
backwards-compatibility is maintained for a reasonable number of
release versions. Given that GlobalOpts hasn't spent any time in the
deprecated state, I'm irked to see it marked as obsolete. And is it
really a [Fvwm]<<ERROR>> to use a deprecated line, such as IconPath?
If I just drop this new version of fvwm on top of the old
installation, users will send email complaining of how the new
one is broken, and of how it keeps telling them about ERRORs.
I won't let someone sit at their computer one morning only to
discover that they'll need to spend their morning fixing their
dotfiles for today's new version of fvwm.
I have had requests to install the new version, so I've done so, but
it's sitting off to the side of the old version, named "fvwm2.4"
instead of "fvwm2". That way people won't be able to accidentally
run it, and when they do explicitly run it, they'll be able to
put off upgrading their v2.2 config until they have time to do so.
In closing, thanks for working on fvwm. I've been using it as
my main windowmanager for the past four years. I'd love to see
it become more of a mainstream windowmanager and less of a
bleeding-edge windowmanager, but in order for that to happen,
fvwm will have to be more careful about backwards compatibility,
and about spewing diagnostic output.
Sincerely,
Jacob Morzinski [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]
