Tastaturkürzel neu belegen mit deutscher Tastatur (Mac)
Problem: Nicht jede Tastenkombination auf dem Mac mit deutscher Tastatur kann als Tastaturkürzel in MS 4.2 festgelegt werden. z.B. ">" kann nicht als decresc. festgelegt werden (Standard ist "."). Das hängt wohl mit dem deutschen Tastaturlayout zusammen. Gibt es eine Liste mit frei verfügbaren Kombinationen?
Comments
Es gibt natürlich keine Liste von frei verfügbaren Tastaturkürzel.
Aber Du kannst Dir eine Liste von den vergebenen machen und daraus aus auf Verfügbare schließen.
->Bearbeiten ->Einstellungen Registerblatt 'Tastenkürzel' und dann ein- oder zweimal (je nachdem, wie Du aufsteigend oder absteigend sortiert haben möchtest) auf die Spaltenüberschrift 'Tastenkürzel' klicken und das dann als PDF (vorausgesetzt Du hast einen PDF-Drucker eingerichtet) ausdrucken.
Edit: ich beziehe mich auf 3.6.2; sollte aber unter 4.x nicht anders sein.
In Mu4 kannst du die Liste der Kürzel exportieren und bearbeiten.
https://musescore.org/de/node/329657#Importing_and_exporting_shortcuts
Die vollständige Liste ist auch im Handbuch.
https://musescore.org/de/node/332987
In reply to In Mu4 kannst du die Liste… by Mr Fox
> Die vollständige Liste ist auch im Handbuch.
Welche aber nur für das oben angegebene Tastaturlayout zutrifft. Entscheidend ist, welcher Scancode von der Tastatur gesendet wird (und damit, wie die Tastatur aufgebaut ist).
Danke, das ist mir soweit bekannt. In einem früheren Post bekam ich die Rückmeldung, dass eben nicht alle Tasten/Tastenkombinationen in MS 4 verfügbar sind - also unabhängig von der Standardbelegung durch MS. In MS 3.6 konnte ich z.B. wie oben erläutert die Taste ">" frei belegen, in MS 4 ist das nicht mehr möglich, da anscheinend nicht-englische Tastaturen nicht mehr in dem Maße unterstützt werden.
Im Moment möchte ich !,",§,$,%,& verwenden, kann dies in den Einstellungen eingeben, aber es funktioniert nicht.
In reply to Danke, das ist mir soweit… by Hubato
> Im Moment möchte ich !,",§,$,%,& verwenden, kann dies in den Einstellungen eingeben, aber es funktioniert nicht.
Kann ja auch nicht funktionieren. Du willst Zeichen zuweisen, aber es können nur Tasten zugewiesen werden. Deswegen nennt sich das auch Tastaturkürzel.
Beispiel: Das Zeichen & erhältst Du ja schon mit einem Tastaturkürzel <Shift>+<6>.
Deswegen geht auch > nicht auf der deutschen Tastatur, weil dieses Zeichen im Gegensatz zur amerikanischen Tastatur in der zweiten Tastaturebene liegt und auf der deutschen Tastatur die physische Taste < ist.
Nur Zeichen, die auf einer Tastatur ohne den Sondertasten Strg (Ctrl), Shift, Alt, Alt gr, Meta erreichbar ist, ist als Tastaturkürzel verwendbar.
">" kann auch auf dem Mac als decresc. festgelegt werden:
https://musescore.org/en/comment/1188618
(mit Dank an Jojo-Schmitz)
(man muss dazu die shortcuts.xml-Datei editieren)
In reply to ">" kann auch auf dem Mac… by Malte Rogacki
und < funktioniert dann noch? Z.B. in Texten? (kann sein, das beim Editieren von Text keine Tastaturkürzel ausgewertet werden).
In reply to und < funktioniert dann noch… by tuxan
Ja, das funktioniert weiterhin. Ich würde deshalb annehmen, dass das auch bei den anderen Fällen geht.
Mal ausprobieren: Ja, zum Beispiel für "!" muss man dann händisch "Shift+!" eintragen. Das ist zwar von der Anzeige in den Voreinstellungen her etwas irritierend, denn der Befehl ist ja nicht "Shift + Ausrufezeichen", sondern "Shift + 1". Interessanterweise funktioniert letzteres ebenfalls. Das zusammen spricht m.E. gegen die Vermutung, dass die Zuweisung nicht mehr (ausschließlich) via Zeichen, sondern Tastenposition erfolgt, denn "Shift+!" setzt m.E. voraus, dass das Programm "weiß", dass "!" der Taste "1" zugeordnet ist
Meine extrem laienhafte Vermutung geht in Richtung eines Bugs in Qt, da das Problem m.W. nur bei Mac und nicht bei anderen Plattformen auftaucht. Und ja, das ist ein Bug in den 4er Versionen, in 3.x ging das alles noch problemlos.
In reply to Ja, das funktioniert… by Malte Rogacki
Es wird, meine ich, in Mu4 nicht mehr das Qt Tastatur Handling verwendet, zumindest aber auf eine andere Art
In reply to Ja, das funktioniert… by Malte Rogacki
Nunja, der Weg von der Tastatur ins Programm ist lang. In X11 unter Linux (Windows, Mac ist ähnlich) durchläuft ein Tastendruck eine Menge unterschiedlicher Abstraktionsschichten, bevor er tatsächlich auf eine Funktion abgebildet werden kann. Die Tastatur-Hardware repräsentiert einen Tastendruck (bzw. das Loslassen einer Taste) mit einem sogenannten Scancode. Das ist eine kurze Byte-Folge, die sich je nach Tastaturtyp unterscheidet (so senden z.B. USB- und PS/2-Tastaturen unterschiedliche Scancodes) und vom Linux-Kernel anhand einer Tabelle in sogenannte Linux-Keycodes umgewandelt wird. Der Tastatur-Treiber des X-Servers wiederum greift den Linux-Keycode auf erzeugt daraus einen X11-Keycode. Nachdem das XKB-System im Regelfall auch weiß, welches Tastaturmodell am Rechner hängt, kann es jeder Taste zusätzlich noch einen symbolischen Namen zuordnen.
Auf diesem Weg kann man viel manipulieren. Der Fenstermanager reicht das Tastaturereignis dann zum auf dem Desktop aktiven Programm weiter und dann kommt es darauf, wie die Programmierer dieser Anwendung das Binding von Tastaturereignissen an die Widgets (Elemente des Programmfensters) umgesetzt haben.
Da ich nichts Grafisches für internationale Verwendung schreibe, habe ich auch keine Ahnung im Umgang mit verschiedenen Tastaturlayouts.
Meine extrem laienhafte Vermutung geht in Richtung eines Bugs in Qt, da das Problem m.W. nur bei Mac und nicht bei anderen Plattformen auftaucht.
Naja, ich verordne da das Problem ein bischen bei Apple. Es gibt da zwei Möglichkeiten, wie man seine Tastatur verwendet (ähnlich wie bei Notebooks mit aktiver FN-Taste oder inaktiver FN-Taste). Je nachdem, was man eingestellt hat, muß noch eine zusätzliche Taste gedrückt werden oder darf eben nicht gedrückt werden.
Und die Leute wissen davon meist nichts.
In reply to Ja, das funktioniert… by Malte Rogacki
> _Das ist zwar von der Anzeige in den Voreinstellungen her etwas irritierend, denn der Befehl ist ja nicht "Shift + Ausrufezeichen", sondern "Shift + 1". _
Das meinte ich, als ich von _Tastatur_kürzel gesprochen habe. Das ! wird ja schon mit dem Tastaturkürzel Shift+1 erzeugt. Es muß immer das Zeichen angegeben werden, das ausgegeben wird, wenn nur diese eine Taste gedrückt wird. Und zu dem Zeichen kommen dann die Sondertasten dazu. z.B. Shift+1 oder Strg+1 oder Strg+Shift+1 oder ...
Aber die 1 muß die über den Buchstaben sein. Die 1 vom Nummernblock ist was anderes. Jedenfalls meistens. In Musescore scheinbar nicht (habe gerade mal Strg+3 getestet; egal ob Zahlenreihe oder Nummernblock erzeugt eine Triole).
In reply to > _Das ist zwar von der… by tuxan
> Das meinte ich, als ich von _Tastatur_kürzel gesprochen habe. Das ! wird ja schon mit dem Tastaturkürzel Shift+1 erzeugt. Es muß immer das Zeichen angegeben werden, das ausgegeben wird, wenn nur diese eine Taste gedrückt wird.
Gegen diese Theorie/Sichtweise spricht m.E., dass eben "Shift+!" genau so funktioniert...
In reply to > Das meinte ich, als ich… by Malte Rogacki
Nein. Anders geht es nicht. Eine Tastatur sendet keine Zeichen, sondern Scancodes (auch wenn es Tastaturen gibt, die man umprogrammieren kann, aber dann senden die eben andere Scancodes).
Wenn "Shift+!" trotzdem funktioniert, würde ich darauf schließen, das die Programmierer eine Mappingebene eingezogen haben.
In reply to Nein. Anders geht es nicht… by tuxan
Das sollte das Betriebssystem erledigen
In reply to Das sollte das… by Jojo-Schmitz
Ja, das Betriebssystem setzt die Scancodes in Zeichen um. Aber immer nur 1. Tastaturebene.
Der Programmierer wertet das Zeichen + Sondertasten aus. Bei der von mir verwendeten Sprache sieht das für Strg+q so aus:
bind . <Control-KeyPress-q> { befehl }
und jetzt wird es interessant:
Die 1 (über den Buchstaben):
bind . <KeyPress-1> { befehl }
Das ! also Shift+1:
bind . <Shift-KeyPress-exclam> { befehl }
Da bekommt man ohne Handbuch/Hilfstool graue Haare.
Edit: Jetzt, wo ich nochmal drüber nachdenke. Bei meinem Zeugs (TK) ist das wie bei Musescore bis Version 3. Es wird mehr als die erste Tastaturebene ausgewertet (ich verwende für Shortkeys eigentlich nur Strg und Alt). Jetzt mit Version 4 hat das vom programmieren viel logischere Auswerten von nur der ersten Tastaturebene Einzug gehalten.
Allerdings etwas verwirrend für Anwender. Es gibt sicherlich nicht mehr viele, die die Anordnung der Beschriftung auf der Tastatur zu deuten wissen. Die Taste zeigt ein H - wenn man draufdrückt kommt ein h
In den Angaben zu den Shortcuts wird imho richtigerweise der Aufdruck der Tastatur angegeben. Aber manche Anwender sagen sich, mit N komme ich in den Eingabemodus, also drücken sie, weil sie gelernt haben ein großes N ist Shift plus die Taste 'N' und wundern sich, das es nicht funktioniert.
In reply to Nein. Anders geht es nicht… by tuxan
M.W. gibt es bei macOS eine Funktion, die zu einem keyboard event (also zum scancode) das entsprechende Unicode-Zeichen liefert. Also sollte es auch möglich sein, die Tastaturbefehle so zu handhaben. Wie gesagt, bei Windows und vermutlich Linux geht es ja auch.
In reply to M.W. gibt es bei macOS eine… by Malte Rogacki
Sicher. Unter X (Linux) ist dafür Xmodmap zuständig. Da das jetzige MacOS auf dem unixoiden Darwin basiert, wird es da sicherlich ähnlich sein. Vielleicht nennt es sich da AppleGreavesModmap. Dem Apfel fehlt ja schließlich ein bischen was. ;-)
In reply to Nein. Anders geht es nicht… by tuxan
Ähm. Wo funktioniert "Shift+!" trotzdem.
Als Eintrag in der shortcuts.xml-Datei? Wenn ja, dann könnte das mit Mapping zutreffen.
Wenn Du nicht die shortcuts.xml-Datei meinst, dann frage ich mich, was Du mit "Shift+!" meinst.
Die Zahlen auf dieser Reihe bzw. der untere linke Aufdruck sind die erste Tastaturebene, sprich: das was ohne Sondertasten erreichbar ist.
Das, was links oben auf der Tastatur aufgedruckt ist, ist die 2. Tastaturebene. Um diese Zeichen darzustellen muß Shift gedrückt werden. Deswegen hast Du auch auf der Tastatur Großbuchstaben stehen und zwar links oben.
Zeichen, die rechts unten auf der Taste aufgedruckt sind, liegen auf der 3. Tastaturebene. Die sind mit 'alt graphics' erreichbar (z.B. @µ~).
Die Tastatur sendet nicht Shift plus 1 = ! - sonder Shift pressed, 1 pressed oder um es genauer zu sagen: 0xff0d 0x31 (kundige sehen, das ich die linke Shifttaste benutzt habe.) Ohne Shifttaste sendet die Tastatur nur 0x31.
In reply to Ähm. Wo funktioniert "Shift+… by tuxan
Ja, ich meine das als Eintrag in der shortcuts.xml-Datei. Und ich verstehe auch vollkommen, was Du meinst (im Hinblick auf scancodes ausw.)
Um das noch mal etwas zu präzisieren:
Das Ausgangsproblem war (bei mir) "<" und ">" für crescendo und decrescendo. Bei der 3.6.2 auf dem Mac und der 4.x auf Windows funktionieren dafür die reinen Zeichen an sich in der shortcuts.xml
(Ich bekomme das mit dem "Code zitieren" gerade irgendwie nicht hin.)
Auf dem Mac funktioniert genau das bei der 4.x nun nicht mehr.
Standardmäßig liegt das dort auf "Shift+," und "Shift+." (also auf den Tasten, die bei amerikanischer Tastaturbelegung "<" und ">" bedeuten).
Ich kann das nun in den Voreinstellungen ummappen, und mir wird dort auch korrekt "<" und ">" angezeigt (genau wie in 3.6.2!). Allerdings hat ">" dann keine Funktion. Das bedeutet also, die Voreinstellungen erkennen diesen Befehl (und zeigen ihn mir dort auch korrekt an), aber das eigentliche Programm erkennt ihn nicht. In der shortcuts.xml stehen jetzt also die gleichen Codes wie oben in der 3.6.2, aber es funktioniert nur noch einer.
Wenn ich nun für "add-hairpin-reverse" allerdings manuell "Shift+<" ODER "Shift+>" eintrage, funktioniert auch der Tastaturbefehl wieder wie früher (identisch für beide Varianten!). In den Voreinstellungen werden mir auch die korrekten Entsprechungen angezeigt, nämlich Shift< und Shift>, was beides nicht ideal ist.
In reply to Ja, ich meine das als… by Malte Rogacki
Mmh.
Meines erachten müßte einmal "Shift+>" und einmal nur "<" stehen.
Was passiert, wenn Du das, was nicht funktioniert mit "Control+<" (falls der nicht schon vergeben ist) belegst? [ob 'Control' jetzt die richtige Bezeichnung ist, weiß ich jetzt nicht aus dem Kopf.]
Du könntest auch "Control+<" und "Control+Shift+<" probieren. Nach einer kurzen Umgewöhnungsphase sitzt das dann. Die shortcuts.xml sichern, damit bei Programmupdate Du die nur wieder zurückspielen kannst (Die vom update umbenennen nach z.b. shortcuts.xml.Versionsnummer - falls sich was entscheidendes geändert hat).
Edit: Argh; Fehlerteufel in der ersten Zeile:
Korrektur: Meines erachten müßte einmal "Shift+<" und einmal nur "<" stehen.
In reply to Mmh. Meines erachten müßte… by tuxan
Ich habe jetzt mal in meiner shortcuts.xml von v3.6.2 geschaut.
<SC>
<key>add-hairpin</key>
<seq><</seq>
</SC>
<SC>
<key>add-hairpin-reverse</key>
<seq>></seq>
</SC>
und aus irgendeiner 4er Version (liegt noch rum, falls ich irgendwann die nochmal testen sollte)
<SC>
<key>add-hairpin</key>
<seq>Shift+,</seq>
</SC>
<SC>
<key>add-hairpin-reverse</key>
<seq>Shift+.</seq>
</SC>
was ; und : eigentlich bedeuten würde.
Aber eines ist zu erkennen. Es wurde etwas verändert. In der 3er wird auf die Zeichen gemappt. In der 4er wird Keysym (Keycode?) verwendet.
Ich würde daraus schlussfolgern:
> entspricht: Shift+<
< entspricht: <
in der shortcuts.xml (auf der rechten Seite das Zeichen, was erscheint, wenn die Taste ohne Sondertasten gedrückt wird.).
Man, ist das nervig mit den spitzen Klammern. In pre funktioniert der Hafer wieder anders als normal. Grrh.
Edit:
Anmerkung:
Bei Ctrl, Shift, etc. auf Groß-, Kleinschreibung achten.
In reply to Ich habe jetzt mal in meiner… by tuxan
So ist es, und das Problem ergibt sich m.E. hauptsächlich daraus, dass das beim Zuweisen in den Voreinstellungen anders gehandhabt wird. Wenn ich dort die Taste "Shift" und eine weitere Taste drücke, wird eben nicht "Shift+weitere Taste" in die shortcuts.xml geschrieben, sondern das entsprechende Zeichen.
In reply to So ist es, und das Problem… by Malte Rogacki
Jetzt schließt sich bei mir der Kreis.
Das ist sozusagen ein 'UX-Bug' oder besser gesagt widersprüchliche Benutzungsvorgabe.
Wird wohl erst in MS 4.4 gelöst. Hoffentlich.
https://github.com/musescore/MuseScore/issues/16199