(ich antworte hier auf zwei emails gleichzeitig, ich hoffe, das verwirrt
nicht)
> > Falsch. Man muss auch noch ein passendes Locale einstellen, und das ist
> > ein einschneidender (oft inakzeptabler) Eingriff.
>
> Wo stellst du ein passendes Locale ein?
Mit LC_ALL. In OpenOffice gibt es auch eine explizite Auswahl in den
Spracheinstellungen.
> Zur Situation der Schweizer Tastatur: mir ist noch nicht klar, wo genau das
> Problem liegen soll.
KP_Separator ergibt mit einem schweizerdeutschen (nicht nur einem
amerikanischen) Locale unter Umständen einen Punkt.
> Dafür hast du in Programmen, die auf der ersten Ebene ein KP_Separator oder
> KP_Decimal erwarten ein Problem.
«Ebene» ist die abstrakte Anwendersicht. Was die Applikation sieht (und
sehen wollen darf) ist ein implementierungsspezifisch. In XKB haben wir
z.B. redirect-Actions für harte Fälle.
> Zum Beispiel die Tastaturmaussteuerung,
Die hat zunächst nichts mit der normalen Belegung zu tun; ein
Zusammenhang ergibt sich erst mit durch die Implementierung. Schauen
wir das doch einmal an. Referenz:
Die Bedienung kann wahlweise über die Ebene 1 des Keypads oder die
rechte Hälfte der Ebene 4 (z.B. mit Mod4_Lock) erfolgen. _
Komma oder Punkt (auf dem Keypad also die Taste neben der 0) lösen
diesen gehaltenen Klick
Ausschnitt aus der Implementierung unter X:
interpret KP_Separator {
action = PointerButton(button=default,count=2);
};
interpret KP_Decimal {
action = LockPointerButton(button=default,affect=unlock);
};
KP_Decimal würde einen gehaltenen Klick lösen, KP_Separator nicht. Die
beiden X-Neos implementieren die Tastaturmaus also nicht korrekt.
xmodmap hat wenige Möglichkeiten; wäre KP_Decimal nicht ausdrücklich
verbannt, könnte man zumindest die Situation auf dem Haupttastenfeld
verbessern (OpenOffice zum Trotz). XKB hat mehr Möglichkeiten und könnte
einen anderen Weg gehen.
Bisher wurden zwei Gründe angeführt, dass die Zifferblöcke unbedingt
KP_Separator und keinesfalls KP_Decimal enthalten müssen: Der Grund
OpenOffice scheitert an schweizerdeutschen Locales (und hat wegen der
Einstellungsmöglichkeiten von OpenOffice wenig Gewicht), der Grund
Tastaturmaus beruht auf einem Irrtum über deren Implementierung unter X.
Da bleibt nicht viel.
> Wenn es eine gute Beschreibung in der Referenz gibt, habe ich nichts dagegen,
> Treiberspezifisches herauszulassen; es darf aber nicht der Fehler gemacht
> werden, durch Verkürzung Funktionalität zu verlieren.
In der Tat ist eine gute Beschreibung schwierig. Vielleicht kann man
sich darauf beschränken zu verlangen, des die Ziffernblöcke und die
KP-Navigationsebene die Funktion des «normalen» Ziffernblocks und der
normalen KP-Navigationstasten nachbilden sollen. Das ist zwar vage,
aber wir kennen die Anforderungen auch nicht detaillierter.
Andreas
