Subject: fvwm2.4 installation issues

From: Jacob Morzinski <[email-masked]>
Date: Sun, 3 Feb 2002 03:37:18 -0500 (EST)

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

--
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-masked].
To report problems, send mail to [email-masked]

---

From: Dan Espen <[email-masked]>
Date: Sun, 03 Feb 2002 08:28:45 -0500

> (I'm installing v2.4 alongside 2.2.)

At my site, I install every Fvwm release in a directory that includes
the release number.  The only copy of Fvwm in the users path
is a shell that adds Fvwm
to the users path, picks the release to run, and then invokes Fvwm.

For the 2.4 installation, the shell noticed that the user had
no .fvwm/.fvwm2rc, had a .fvwm2rc and ran fvwm24_convert.
fvwm24_convert will take care of those error messages.

I had a few site specific  issues that fvwm24_convert didn't deal with
and slightly modified fvwm24_convert before using it.

Another thing the shell does is detect first use of a new release
and send email to the user about the features.

-- 
Dan Espen
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854                     Phone: (732) 699-5570
--
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-masked].
To report problems, send mail to [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Sun, 3 Feb 2002 13:19:57 +0100

> around the issue by setting $USER to the target email address

Well, it's meant only for bug reports going to us.  Everybody can
edit the sender information in a mail program.

> scream "ERROR!" at users.

That is because it's better to scream "ERROR" than to confront
users with broken config files that no longer work without a clue.
Most of the new error messages address commands or features that
are planned to phase out when fvwm-3.0 is released (whenever this
may be).

> binding's context.

I see.  The man page is incorrect.  'A' matches any context,
including buttons.  I'm sorry if that has lead to 

> In version 2.4, this Key binding has the
> side-effect of *creating* all ten title-bar buttons.

That's not a side effect but exactly what was always intended.
All title buttons that have a binding show up.  By accident,
before 2.4, only mouse bindings activated the buttons.

> I can fix the

Title buttons can be suppressed with the NoButton style:

  Style * Nobutton 6, NoButton 7

etc.  Of course you'd have to change config files too.

> MouseFocusClickDoesntRaise' with 'Style * MouseFocusClickRaisesOff'")

See my comment above.  I fail to see why it should be better to
let users run into these problems without a hint what has gone
wrong.

> really a [Fvwm]<<ERROR>> to use a deprecated line, such as IconPath?

We can't give much more of a hint than this.  GlobalOpts *will*
vanish some day and then the users would have to find out on their
own what to do.  BTW, there is a perl script that does most of the
conversions from 2.2 to 2.4 (utils/fvwm24_convert).

When developing we always have to make decisions about efficiency
vs. compatibility.  Sometimes we make decisions agains the latter
to be able to have progress at all.

> bleeding-edge windowmanager,

If you think that 'main stream' means 'constant feature set and no
bug fixes' then you'd better use a different window manager.
Fvwm is constantly changing, and sometimes its simply necessary
to not be compatible.

> but in order for that to happen,

Hm, when I run applications that you call 'main stream' my console
usually shows dozens or even hundreds of error messages ;-)

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
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-masked].
To report problems, send mail to [email-masked]

---

From: Jacob Morzinski <[email-masked]>
Date: Wed, 06 Feb 2002 18:03:43 -0500

I'll try to break up these issues, to make them more manageable.

Dominik Vogt wrote:

>>configurable.  I don't want personal bug reports
[...]
> edit the sender information in a mail program.

What I was trying to say is that I want bug reports, but I don't want 
the email to be directed to me personally -- I want it to go to 
[email-masked].  How do my users know to edit the sender 
information, to add that to the header when they select the "both" or 
the "local" destination options?  I argue that the fvwmbug script should 
not hardcode username of its installer; it should use a configurable value.

Hardcoding "jmorzins" into the local address is as bad as hardcoding 
"[email-masked]" into the global address -- we might both be 
interested in reading the local/global mail, but we shouldn't be the 
_only_ people reading the local/global mail.  It should go to a list.

  Jacob Morzinski
  [email-masked]

---

From: Mikhael Goikhman <[email-masked]>
Date: Wed, 6 Feb 2002 23:54:28 +0000

> >>configurable.  I don't want personal bug reports

Ok, in the next releases the local address will be taken from
$FVWM_BUGADDR if set in the installation time. It seems that you are the
first one not happy with the current default.

Until then, you as a sysadmin should edit this script to suit your
system to the best advantage. Or set $USER instead of $FVWM_BUGADDR.

Regards,
Mikhael.

---

From: Jacob Morzinski <[email-masked]>
Date: Wed, 06 Feb 2002 22:13:18 -0500

> first one not happy with the current default.

Thank you.  It would be lovely if that is specified in the installation 
instructions, but even if it isn't, people will no longer shudder at 
having to set $USER to an email address.

  -Jacob

---

From: Jacob Morzinski <[email-masked]>
Date: Wed, 06 Feb 2002 22:13:01 -0500

My "error message" frustration is a mix of issues.  One aspect, which 
your response primarily addressed, is the issue of introduction of new 
features and deprecation of old features.  Another aspect is the 
decision of when to produce a diagnostic message, and whether to mark 
the diagnostic message as an error, a warning, or something else.  A 
third aspect is that particular things are producing diagnostic messages 
when they absolutely should not be.

First aspect: new features and old features

> Fvwm is constantly changing, and sometimes its simply necessary

I hope that you were merely typing quickly, instead of really thinking 
that I'm that simplistic.  Mainstream does not mean "stasis".  New 
features are good, and bug fixes are very good, and both can happen 
whenever they want to happen.  The crucial thing about good release 
engineering is that deletion of _old_ features needs to careful and 
(hopefully) slow.

GlobalOpts was a minor issue.  In case my point was unclear, I'll 
clarify that my objection is not the removal of GlobalOpts, it's that 
GlobalOpts is *already* removed, without spending a release being 
deprecated.  Anyway, it's not worth arguing about; now that it's 
obsoleted, let it stay obsoleted.

New features are good.  Removal of old features is fine.  But please, 
deprecate things before obsoleting them (and only obsolete them on a 
major release).

Second aspect: diagnostic messages

>>another nuisance is fvwm's readiness to scream "ERROR!" at users.

[...]

> users with broken config files that no longer work without a clue.

A deprecated config file option should produce either no output, or a 
warning.  An obsolete config file option should produce either no 
output, or an error.  My concern is that fvwm is being sloppy about the 
distinction between errors and warnings, with a minor concern that it is 
producing more output than it needs to.  Both of these are judgment 
calls; my point of view follows:

For the distinction between errors and warnings, it is good style for a 
computer to be consistent in its behavior, and errors and warnings have 
traditionally had specific meanings.  An error is issued when a program 
absolutely cannot perform a task, and a warning is issued when the 
program thinks it can do it, but needs to tell the user something. 
Since deprecated config options still work, it is not an error to use 
one.  Use of an obsolete config option is an error.

My personal preference is that deprecated options produce no output and 
obsolete options produce output, just in the interest of keeping the 
user's life simple.  They want the computer to Just Work, so I don't 
want to show them error messages until I have really important ones. 
This is merely personal preference; there are certainly arguments to be 
made in favor of producing diagnostic output for deprecated options.

But please, don't produce ERROR messages for deprecated options, or for 
other non-fatal situations.  It confuses the user, and teaches them that 
fvwm's messages are not worth reading.

 >>fvwm will have to be more careful ... about spewing diagnostic output.
[...]
 > usually shows dozens or even hundreds of error messages ;-)

You haven't named the application, so I can't confirm whether I would 
call it mainstream.  But I question the wisdom of showing hundreds of 
error messages -- the user will either ignore the messages, or dump them 
to /dev/null (as we do for Gnome crap).  Fvwm isn't this bad, of course; 
I'm just trying to apply pressure to hope that it never becomes so.

Third aspect: particular points which SHOULD NOT produce complaints

  Two points are particularly bad: xbm files, and missing keysyms.

Fvwm2.4 will print a complaint each time it loads a xbm file.  As a 
policy issue, does fvwm support xbm files or not?  If it does, it 
shouldn't complain when it loads one (and the complaint certainly 
shouldn't be an ERROR, since the load succeeds).

The complaint is "<<ERROR>> XpmReadFileToXpmImage failed".  There's a 
simple techincal reason for the diagnostic complaint (fvwm tries the xpm 
loader before trying the xbm loader).  But from a policy point of view, 
a program that supports xbm's should not complain when it successfully 
loads an error-free file.

Fvwm2.4 will also print a complaint message when a config file Key 
binding refers to a keysym that is not present on the current X server.
I can conceive of this having some advantage, as a guard against typos 
in Key bindings in the config file.  This advantage is outweighed by a 
disadvantage: it breaks on cross-platform config files.

Some sites have multiple platforms and also have network filesystems; 
users can use different computers, but have the same home directory 
across all of them.  With one homedir, the user will have one .fvwm2rc 
file wherever they go.  Since different platforms have different sets of 
keysyms, it is best for fvwm to politely ignore keysyms that it can't 
find on the current X server.

For a specific example: I raise windows with Meta-F12.  The "F12" key is 
keysym <F12> on a Linux machine but is <SunF37> on a Solaris machine 
(the "Again" key is keysym <F12>).  The obvious solution is to put both 
a "Key F12" and a "Key SunF37" line in my config file, and this solution 
worked fine with fvwm2.0 and fvwm2.2.  In 2.4, if I sit down at a Linux 
keyboard I receive an error message: "<<ERROR>> No such key: SunF37".

A slew of Sun keys are not present on a PC keyboard; I know that the PC 
WinKey and MenuKey are not present on Sun keyboards, and other keyboards 
out in the wild almost certainly have their own special keys too.

The error message happens *every* time the user starts fvwm, and grows 
old after a few viewings.  If it were the result of a typo, the user 
could fix the typo to stop the warning.   If the user used a deprecated 
command, the user could update the command to stop the warning.  But 
there's no way to unify the keyboards of different hardware.  The better 
option is for fvwm to assume that the user correctly specified Key's 
keysym, and accept the line.

That's about it for my "error message" frustration.  I'm most concerned 
about fvwm producing ERROR messages for simple things like loading xbm 
images or foreign-platform keys, but also wish that it would be more 
conservative about its use of error messages in general.

Sincerely,
  Jacob Morzinski
  [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 7 Feb 2002 10:51:47 +0100

On Wed, Feb 06, 2002 at 10:13:01PM -0500, Jacob Morzinski wrote:
> clarify that my objection is not the removal of GlobalOpts,
> it's that GlobalOpts is *already* removed,

It isn't.  GolbalOpts is still there.  If it were you would simply
get a "No such command" error message without any hint what to do
about it.  Right now GlobalOpts is in the state you call
'deprecated'.  I've never seen a proper definition of 'deprecated' and
'obsolete'.  For me, both have the same meaning.

> without spending a release being 

Of course we do.  One thing we could thing about would be an
option to turn off the warnings about commands that do not work
properly anymore or that will phase out some day.

> one.  Use of an obsolete config option is an error.

Yes, you're right and I'm aware of that issue.  The problem here
is that nobody has ever designed these error messages, so some
commands produce errors and some do not.

> My personal preference is that deprecated options produce no output

I think that's a bit short sighted.  As a user I prefer to get
warnings while the feature still works so I can choose when I fix
them.  When the feature is already gone I have no choice anymore.

> and 

Perhaps we'd be better off with a totally new message class for
these kind of messages.  In my eyes, a warning does not reflect
the gravity of the issue at hand.

> to /dev/null (as we do for Gnome crap).

I meant Gnome and KDE.  I never cared to find out which
applications spew which output :-)

> Fvwm isn't this bad, of course; 

Well, it's much more helpful to apply patches instead of pressure.
There is no monopoly on fvwm - everybody can make patches if she
can convince one of the people with commit privileges to apply
them :-)  Our biggest problem is that people have sooooo many good
ideas and there is so litte time to implement them all :-/

> loads an error-free file.

I'll look into that.  I wasn't aware of that problem.

> disadvantage: it breaks on cross-platform config files.

This message can be suppressed by prefixing the command with the
keyword "Silent":

  Silent Key some_funny_key a n beep

Bye

Dominik ^_^  ^_^

-- 
Dominik Vogt, email: [email-masked]
LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen
fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20
--
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-masked].
To report problems, send mail to [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 7 Feb 2002 11:53:34 +0100

> I'll look into that.  I wasn't aware of that problem.

Fixed.

Bye

Dominik ^_^  ^_^