On Wed, Feb 06, 2002 at 10:13:01PM -0500, Jacob Morzinski wrote: > > 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,
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 > 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). 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. > 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. 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 > 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. 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. > >>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). I meant Gnome and KDE. I never cared to find out which applications spew which output :-) > Fvwm isn't this bad, of course; > I'm just trying to apply pressure to hope that it never becomes so. 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 :-/ > 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. I'll look into that. I wasn't aware of that problem. > 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. This message can be suppressed by prefixing the command with the keyword "Silent": Silent Key some_funny_key a n beep > 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. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] 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 PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
