-
Notifications
You must be signed in to change notification settings - Fork 246
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Better wording in user messages about keyboard issues #2520
Conversation
Inform the user about possible issues with keyboard usage in the recovery system but use neutral wording for those user messages to avoid false alarm except when it fails to include the current keyboard mapping (which is no fatal Error because the US keyboard mapping is included as fallback) cf. #2519
Thanks for picking this up. I'm now getting these messages on Ubuntu:
The wording is certainly better, but it still gives the impression that something might be wrong here (in particular, as these are the only messages appearing). More importantly:
Now I try to put myself into two different user's shoes:
So of course, your mileage may vary, but you get the idea. ReaR's Coding Style says:
Schlomo says in WARNING is a waste of my time:
Note: It does not really matter if the word To summarize:
My conclusions:
Consider my suggestion in #2519 (comment):
With a message like this, you could put in additional commentary in |
@OliverO2 Unless usr/sbin/rear was launched with '-v' or '-d' or '-D' I may consider your suggestion if at least the
because personally I hate it when computers give me (unsolicited) tips |
Only when 'dumpkeys' failed show subsequent messages on the user's terminal in any case, cf. #2520 (comment)
Via @OliverO2 I don't like it so much now because now the code looks somewhat oversophisticated. |
@jsmeix I would not call it over-sophisticated, but user-friendly: ReaR now follows what Linux distributions have decided (and what their users now are used to). If the distro includes console-multi-keyboard support, ReaR has it (without asking). If the distro has decided that this is not necessary, ReaR aligns with that decision. If a user has decided to install multi-keyboard support, ReaR again will pick it up. Looks just right. I ran the new code on my Ubuntu system and now there is no output appearing. Ideal from my point of view. ReaR does the right thing, I can relax. ;-) This is what a had just written before your new commit came in: Take your time! Now I see that you consider "TIP" as some imperative from a machine pretending to know better. I have never thought of it that way. For me "TIP" is just a friendly reminder because the machine does not know what you might want to do and you might not know what the machine has in store for you. ;-) I stuck with "TIP" because there are many places in ReaR where this is used and I wanted to be consistent. I usually get upset if software starts to throw nonsense at me or if its programmer was too lazy to figure out what is going on, back-delegates the decision to me and fails to provide me with necessary information. |
@OliverO2 Regarding the wording I perceive the wording "TIP" as some kind of patronizing behaviour from a machine. For the fun of it a side note: Regarding your
I only find it in your code:
;-) |
@jsmeix
Oh, really! It must be because ReaR has become too smart over time. In the past there was: (Some other TIPs are present in the documentation.) And I was so convinced that the "TIP" prefix was not my idea at all... ;-) |
Guess who removed that Good evolution: When there is a
;-) |
Added explanatory comments that explain the actual reason behind why the changes in #2520 are needed because it seems newer Debian-based systems (including Ubuntu) no longer contain any keymaps directory as part of the base system so those distros do no longer provide console-multi-keyboard support by default. In such cases ReaR aligns with what there is without being needlessly verbose.
I tested it with artificial errors and (at least for me) things behave well Artificial error in rescue/GNU/Linux/500_clone_keyboard_mappings.sh
to let that fail. Artificial error on openSUSE Leap 15.1:
|
Type: Enhancement
Impact: Low
Reference to related issue (URL):
Misleading warnings about keyboard mappings (LogPrintError) #2519
How was this pull request tested?
Works well for me.
On my openSUSE Laep 15.1 system I get during "rear -D mkrescue"
But I did not test the various failure cases.
Inform the user about possible issues with keyboard usage in the recovery system
but use neutral wording for those user messages to avoid false alarm
except when it fails to include the current keyboard mapping
(which is no fatal Error because the US keyboard mapping is included as fallback).
The actual reason behind why the changes here are needed is
that it seems newer Debian-based systems (including Ubuntu)
no longer contain any keymaps directory as part of the base system, cf.
#2519 (comment)
so those distros do no longer provide console-multi-keyboard support by default.
In such cases ReaR aligns with what there is without being needlessly verbose.
If the distro provides console-multi-keyboard support, ReaR includes it (without being verbose).
If the distro has decided that this is not necessary, ReaR aligns with it (without being verbose).
If the user has installed multi-keyboard support, ReaR aligns with it (without being verbose).
Cf. #2520 (comment)
Only when including the current keyboard mapping failed (i.e. when 'dumpkeys' failed)
it shows subsequent messages on the user's terminal in any case (via LogPrint and LogPrintError)
but normally it shows subsequent messages only in debug mode (via DebugPrint).