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
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.
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
On Sun, Feb 03, 2002 at 03:37:18AM -0500, Jacob Morzinski wrote:
another nuisance is fvwm's readiness to 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.
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.
[...]
> Hm, when I run applications that you call 'main stream' my console
> 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 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]
