Wizard of 3 (beta) should not ask keyboard layout
Users have the keyboard setting already set at operating level, what's the sense to ask a user (possibly new to MuseScore) his keyboard layout except to let him think the MuseScore is unable to use the keyboard as all the other applications do?
I understand that "cheating" in the application indicating another keyboard setting than the OS could be useful for advanced users in some special cases and that this option is provided by MuseScore.
But in the first wizard being the first contact of newcomer??
Comments
A valid question…
I think the point is to customize shortcuts (eg, on some keyboards "+" is the same as Shift+"=" but others it isn't, on some you need Shift to reach numbers, others you don't, etc. Otherwise you have situations like we have now, where some of the default shortcuts simply don't work for large numbers of people, or where we have to disable certain shortcuts for everyone because they cause conflicts for some.
In reply to I think the point is to… by Marc Sabatella
How can a newcomer to MuseScore understand that?
And how is he supposed to guess the keyboard layout to select if it is not the normal one for him already selected at OS level ?
In reply to How can a newcomer to… by frfancha
Normally user doesn't need to know why he is being asked. but sure, we could add that information if you thought it might comfort someone.
For all I know the default is already determined correctly in most cases; I have no way of testing that. But in my experience here on the forum when the subejct of keybaord leyouts comes up, most people do seem to know what theirs is.
In reply to Normally user doesn't need… by Marc Sabatella
I’d tell the user, but continue asking, due to the differences in the shortcuts.
Something like “To preconfigure shortcuts correctly, we would like to know what sort of keyboard layout you use.”
But make the list smaller. Almost all use the QWERTY shortcuts, so something like "QWERTY (English, …) or QWERTZ (German)”, “AZERTY (French, …)” and don’t list multiple German keyboards (and the average user would never have heard of T1 vs T2), or multiple Korean ones, if they’re handled the same.
In reply to I’d tell the user, but… by mirabilos
"But make the list smaller" :
May be, but not so easy, for example, for French language, we have 3 or four keayboard:
- French
- French Belgian
- French Swiss
- French Canadian
All slightly different, I can understand people would not be happy to not see their keyboard in the list.
In reply to I think the point is to… by Marc Sabatella
Seems like a less common use case to me. I agree with frfancha that the average user shouldn't have to bother with selecting a keyboard in the setup wizard.
If we do keep asking the keyboard layout, then perhaps it might be possible to auto-select the one known to the OS (if we can detect that?). It seems to work for language selection…
In reply to If we do keep asking the… by jeetee
Seems to work for the keyboard selection too, at least for me
In reply to Seems to work for the… by Jojo-Schmitz
Still, I can't understand why you take care of new user by designing a basic workspace to avoid frightening him with too many options, and at the same time you ask him to select his keyboard layout as first contact with MuseScore, that no other application asks for and that the OS already knows.
In reply to Still, I can't understand… by frfancha
Frighten me once, shame on you, frighten me twice, shame on me? :-) I don't know what the tradeoffs really are here as far as removing this screen - how often will the defaults be wrong and thus lead to hard-to-diagnose problems later. but I can say that a moment of fear on first startup doesn't concern me as much as constant fear every time someone tries to use the palette. So I'd still fine with erring on the side of caution and asking for confirmation (maybe adding text to clarify this is just confirmation, the default is probably fine).
In reply to Frighten me once, shame on… by Marc Sabatella
<< how often will the defaults be wrong and thus lead to hard-to-diagnose problems later. >>
Does this mean that MuseScore ignores OS keyboard handling and translates itself key codes to characters ?
If yes:
Means that connecting a different keyboard requires to change the setting at OS level, fixing the layout for all applications but MuseScore, and then once again change the setting in MuseScore ?? Bad experience.
If no:
Then why does MuseScore ask the keyboard layout ??
In reply to << how often will the… by frfancha
It means we're at the mercy of what Qt reports to us, and not having experience with any keyboards other than US-QWERTY, I have no idea how reliable that information is. We certainly would like to be able to do keyboard-specific mappings, like making it so kebaord that require Shift to access numbers don't actually require numbers for note input, etc. If we were absolutely guaranteed that every system with an AZERTY keyboard attached reported it correctly to us via Qt, then there should be no need to ask indeed. Otherwise, it remains a harmless two seconds out of your life to confirm.
In reply to It means we're at the mercy… by Marc Sabatella
That doesn't really answer to this simple yes/no question: Does tMuseScore ignores OS keyboard handling and translates itself key codes to characters ?
In reply to That doesn't really answer… by frfancha
The answer is just as trivial: MuseScore does not talk with the OS directly, it uses Qt library functions to get input.
So it’s at the mercy of whatever Qt does.
I’ve been having problems with MuseScore (and other Qt5 applications) over VNC on x32 but not on amd64, even with the same Qt version, so “whatever Qt does” is not even consistent on the same Linux distro and version… this means you will not get a “better” answer as this is literally what it is and nobody can say more for sure.
In reply to The answer is just as… by mirabilos
<< MuseScore does not talk with the OS directly, it uses Qt library functions to get input >>
Yes and?
Does MuseScore use "low level" API giving key code to translate in characters (and modifiers CTRL/ALT/...) or does MuseScore use "high level" API delivering fully baked characters and modifiers?
In reply to << MuseScore does not talk… by frfancha
MuseScore uses whatever API Qt provides.
From personal experience on Unix, I can say it’s a middle ground. Scancodes aren’t used, because they differ between X.org with evdev and without evdev (e.g. with xorgxrdp), but not all keysyms work, either. I’d guess more of a high-level API, in your terms.
On other OSes, this may differ. Qt may even translate itself internally (which is why some platform-specific things don’t work).
In reply to << MuseScore does not talk… by frfancha
To be clear: MuseScore pretty much never talks to the OS directly; it would be almost impossible to maintain cross-platform compatibility if we did. Anything we know about devices, harwarde, input, or output, comes through Qt. If Qt says the user pressed "+" (using Qt's own platform-independent constants for this), then that's what we go on. If Qt says the user press Shift+"=" or whatever you need to press on your keyboard to get "+", then that's what we go on. This is in part why it's important to have different shortcut sets for different keyboard layouts, to remove some of that variability from the equation. If you want to be able to access the shortcut for "tie" without pressing "Shift", we can support that much more reliably if we expect it rather than hoping that your OS and Qt will conspire to send us the "+" keycode. And so on for other potential conflicts, including the numbers on AZERTY keyboards.
In reply to To be clear: MuseScore… by Marc Sabatella
<< Anything we know about devices, harwarde, input, or output, comes through Qt. If Qt says the user pressed "+" (using Qt's own platform-independent constants for this), then that's what we go on. If Qt says the user press Shift+"=" or whatever you need to press on your keyboard to get "+", then that's what we go on. >>
Ok, I get that, it is logic and makes sense.
But in that case, comes back the basic question of this thread ... why does MuseScore asks for your keyboard layout ??
In reply to << Anything we know about… by frfancha
To select the
shortcuts.xmlfile to use, see here: https://github.com/musescore/MuseScore/tree/master/mscore/dataThere are several different ones, because AZERTY is a pretty big fuckup layout, check it out at https://en.wikipedia.org/wiki/File:KB_France.svg if you’ve never had the dubious “honour” to sit in front of an AZERTY keyboard. The numbers are shifted (normally,
1is unshifted and!is Shift-1; in AZERTY,&is unshifted and1is Shift-& (!)), so this means the normal shortcuts just cannot work (if we bind a duration to 1 and something else to Shift-1, well what to do if 1 is already shifted?)Therefore, MuseScore offers several sets of default shortcuts that make sense with the physical layout of the user, and therefore, it needs to know which of them to use.
In reply to To select the shortcuts.xml… by mirabilos
<< AZERTY is a pretty big fuckup layout >>
Please be polite, AZERTY is adapted to several other languages than English that's all.
<< normally, 1 is unshifted >>
No it is not "normal".
It is only normal is you see English and QWERTY as the center of the world.
In reply to To select the shortcuts.xml… by mirabilos
Indeed, as I've been trying to explain :-). What we learned from MuseScore 1 and MuseScore 2 is that one set of shortcuts does not fit all. In MuseScore 1, we did have commands - "add interval below" - mapped to Shift+2 - Shift+9. These worked just fine for QWERTY but messed up the normal functioning of 2-9 on AZERTY since by definition Shift was always pressed when pressing 2-9. The only solution that worked across all OS's was to disable those commands for everyone, which was unfortunate. And now we find cases where, depending on your OS and the version of Qt used, pressing a shifted number key on AZERTY either reports a number to us it reports the raw Shift+symbol combination, and in any case, AZERTY users - like QWERTY users - would prefer not to have to press Shift to access duration in the first place. So the best solution is to have different shortcuts definition for different keyboard layouts. Thus the quarter note shortcut can be "5" (no shift required) for QWERTY and "(" for AZERTY (also no shift required) and it will be guaranteed to work regardless of OS or Qt version.
So once again, in order for all this to work, we need to know your keyboard layout, and while the OS might sometimes tell that to us reliably, obviously (as seen below), it doesn't always. So asking for confirmation is a good thing, period.
In reply to To select the shortcuts.xml… by mirabilos
@mirabilos You have to understand that the different AZERTY keyboads ar used around the world !!! And sure in Canada far from Europe, so you can't throw away them.
In reply to To be clear: MuseScore… by Marc Sabatella
Did you mean “virtually never”?
Anyway, this explains why I have some trouble with some keys… for example, on normal US QWERTY, you have
~on the same key that the accent gravis is on, just with shift… I mapped it so that the unshifted is Esc instead.In reply to Seems to work for the… by Jojo-Schmitz
Failing on my minority-layout
In reply to Failing on my minority-layout by jeetee
And exactly this is what should not happen. Needs fixing before final release. Please file in the issue tracker
In reply to Failing on my minority-layout by jeetee
And it is not that much of a minority problem, I'm affected too ;-) German QWERTY keyboard.
I'm sure this used to work properly before and defaulted correctly