Re: [Neo] Drehen-Taste und Afrikanisch
On Wednesday, 1. July 2009 21:15:09 Alexander Koch wrote: Ich finde schade, dass sich bisher noch niemand zu meinem Vorschlag mit der Haken-Taste geäußert hat, Betrachte das als allgemeine Zustimmung: Schlechte Vorschläge werden hier auf der Liste üblicherweise sehr schnell zerrissen. Der Vorschlag mit Drehungen und Häkchen ist gut durchdacht, er erweitert die Funktionalität sinnvoll, und Interferenzen mit dem status quo scheinen sich auf ein Minimum zu beschränken.
[Neo] neo-vars r1903: das Numpad, wieder mal (sehr technisch)
Werte Urlaubstimmungs-Neo-Gemeinde! Ich habe mich in den vergangenen Monaten gewundert, dass in Excel 2007 mein Dezimalpunkt (oder auch das Dezimalkomma) am Numpad ein wenig bockt, aber nichts weiter unternommen. Jetzt hat’s mir gereicht. Wenn ich beispielsweise hier einen Text eingebe und am Numpad eins–komma–eins tippe, kommt 1,1 heraus. Sehr schön, mit Komma¹, wie es halt so sein soll laut deutscher Tastaturbelegung. In Excel geht das soweit auch richtig: Zahlen haben ein Komma als Dezimaltrennzeichen und können daher sowohl mit dem Komma auf der Haupttastatur, als auch mit dem Komma auf dem Numpad eingegeben werden. Zusätzlich zur Belegung auf Ebene 1 mit „NumpadDot“ gibt es auf Ebene 3 auch noch das simulierte Komma der Haupttastatur und auf Ebene 2 den simulierten Punkt der Haupttastatur. Bei mir ist die Sache aber etwas anders: Aufgrund der beruflichen Tätigkeit, bin ich auf die Internationalität der Zahlen und des Datums angewiesen, also habe ich in den „Regions- und Sprachoptionen“ alles auf „Englisch (USA)“ gestellt, natürlich weiterhin mit deutscher Tastaturbelegung, deutschsprachigen Programmen und mit aktiviertem neo-vars. In normalen Applikationen, die sich um diese Regionsoptionen wenig kümmern, wie mein Thunderbird hier, wird aus einem Druck auf das NumPad-Komma auch weiterhin ein Komma und nicht etwa ein Punkt. Praktischer Weise passt sich Excel an diese Regionsoptionen an und benötigt fortan den Punkt als Zahlen-Komma zur Eingabe, d.h. auf der Haupttastatur muss man das Dezimaltrennzeichen anders tippen als sonst. Tippt man ohne neo-vars bei aktiviertem NumLock das Komma am Numpad, wird dieses automagisch in einen Punkt verwandelt! Hat man hingegen neo-vars aktiviert, kommt merkwürdiger Weise ein widersinniges Komma heraus, und die solcherart eingegebenen Zahlen können von Excel nicht verwendet werden. Man muss dann entweder den Punkt der Haupttastatur drücken, oder auf eine der Unterebenen (genauer: Ebene 2) von NumPadDot ausweichen. Scheinbar funktioniert diese Automatik in Excel nur, wenn tatsächlich das NumLock aktiv ist, und hier hakt es mit neo-vars: Der NumLock wird nur emuliert und ist für das System abgeschaltet. Tatsächlich haben wir aber so etwas wie einen aktivierten NumLock, nur dass man ihn bei Neo nicht deaktivieren kann/soll. Eine Möglichkeit scheint nun zu sein, beim Start von neo-vars den NumLock-State nicht zu deaktivieren, sondern zu aktivieren. Bingo, das Komma wird richtig von Excel in einen Punkt verwandelt! Haken an der Sache ist, dass dann die Ebene 2 des Numpad nicht mehr funktioniert, da hier irgendein Schlitzohr in der Kette zwischen meinen Fingerkuppen und dem AHK die Keycodes austauscht. Nehmen wir weiter die Komma-Taste am Numpad und blicken auf die Tastencodes, die ohne neo-vars so durch den AHK rauschen: NumLock off, Druck auf NumpadDot: 2E 053 d 1.84KOMMA (ZEHNERTASTATUR) 2E 053 u 0.05KOMMA (ZEHNERTASTATUR) NumLock off, Druck auf Shift+NumpadDot: A0 02A d 1.61UMSCHALT 2E 053 d 0.13KOMMA (ZEHNERTASTATUR) 2E 053 u 0.05KOMMA (ZEHNERTASTATUR) A0 02A u 0.16UMSCHALT NumLock on, Druck auf NumpadDot: 6E 053 d 4.39KOMMA (ZEHNERTASTATUR) 6E 053 u 0.08KOMMA (ZEHNERTASTATUR) NumLock on, Druck auf Shift+NumpadDot: A0 02A d 0.14UMSCHALT A0 02A u 0.22UMSCHALT 2E 053 d 0.00KOMMA (ZEHNERTASTATUR) 2E 053 u 0.08KOMMA (ZEHNERTASTATUR) A0 02A d 0.00UMSCHALT A0 02A u 0.14UMSCHALT Aha! Ohne NumLock entsteht der Scancode 2E (Entfernen), mit NumLock entsteht normaler Weise 6E (NumPadDot). Aber wehe, man hält im NumLock-Modus vor NumpadDot eine Shift-Taste gedrückt: Dann wird dieses unmittelbar vor dem Druck des Komma irgendwie deaktiviert (also virtuell losgelassen) und der andere Scancode 2E, also der für Entfernen, geschickt! Anders ausgedrückt: das Shift erscheint deaktiviert, obwohl es gedrückt ist, also erscheint Ebene 2 wie Ebene 1 (nur mit anderem Scancode), Ebene 5 wie Ebene 3 (ebenfalls mit anderem Scancode), und Ebene 7 wie Ebene 4. Ein echter Krampf. Vielleicht ist die AHK-Version von Neo auch deshalb nicht im NumLock-Modus implemetiert worden … Ich habe nun großräumig gefixt: Erstens wird der NumLock beim Start von Neo _aktiviert_. Zweitens werden die beiden SCxxVKyyy-Varianten einer NumPad-Taste eindeutig den unterschiedlichen Zuständen der Shifttaste zugeordnet: Wird bspw. SC6EVK053 empfangen, kann das bei NumLock=on nur _ohne_ Shift-Taste erfolgt sein, umgekehrt deutet ein SC2EVK063 auf ein gedrücktes (aber virtuell losgelassenes!) Shift hin. Drittens wird der Ebene 4 bei gedrücktem Shift ein spezieller Keycode zugewiesen, der in der Ausgaberoutine abfrägt, ob Shift nun künstlich gedrückt
Re: [Neo] neo-vars r1903: das Numpad, wieder mal (sehr technisch)
Hallo allerseits, Matthias Wächter ſchrieb am 02.07.2009 12:46 Uhr: Werte Urlaubstimmungs-Neo-Gemeinde! Es darf auf der Liste durchaus auch mal etwas ruhiger zugehen :-). Dein Excel-Problem kann ich nicht nachvollziehen, da ich Calc und ein ›deutsches‹ Windows benutze. Ich bitte Euch um rege Anteilnahme :-) und natürlich um ausgiebiges Testen des neuen/alten Modus des Navigationsblocks in der neuen Version ab r1903. Ich generiere vorläufig kein neo20.exe und bitte um den Test mit AHK direkt. Dein Wunsch ist mir Befehl … was die Ausgabe/Wirkung der Tasten des Navigationsblockes angeht, kann ich bisher keine Verschlechterung feststellen, alles funktioniert genauso wie vor r1903. Wir sollten da zwar noch ein bisschen länger und in verschiedenen Anwendungen testen, aber prinzipiell scheint es erstmal gut auszusehen :-). Es gibt jedoch einen (recht speziellen) Nebeneffekt, der mir persönlich ziemlich missfällt: Die Auswirkungen Deiner Änderungen auf das Num-Licht. Bisher wurde es beim Aktivieren des NeoVars abgeschaltet (so wie alle anderen Lichter), so dass diese Leuchte als Indikator für das Ein- bzw. Ausgeschaltetsein des Lang-ſ-Modus fungieren konnte. Seit r1903 wird dieses Licht jedoch beim ›Hochfahren‹ des NeoVars standardmäßig aktiviert. Damit das Licht wieder korrekt den Status des Lang-ſ-Modus anzeigt, muss ich diesen erst einmal An- und gleich wieder ausſchalten, was ich ziemlich lästig finde :-(. Und wenn der Lang-ſ-Modus wieder deaktiviert (und Num-Licht ausgeschaltet)ist, ich aber CapsLock-aktiviere, geht auch das Num-Licht wieder an :-(. Kurzum, wenn Excel erfordert, dass der NumLock standardmäßig aktiviert sein muss, ist das schön und gut, aber das sollte möglichst keine Nebeneffekte für die ›Lichter‹ verursachen … eine Verschlechterung des Lang-ſ-Modus will bei mir einfach auf keine große Gegenliebe stoßen, aber ich weiß dass ich da in einer Minderheit bin :-(. Viele Grüße, Dennis-ſ
Re: [Neo] [SVN] Dateien lokal ignorrieren?
On Thursday, 2. July 2009 14:34:42 Dennis Heidsiek wrote: Leider weiß ich nicht, wie man bei SVN Dateien lokal ausſchließen kann (d.h. dass der Link in meinem lokalen Checkout nicht aus Versehen ins Repo eingestellt wird, ohne dass diese svnignore-Regel auch dem Repo selbst hinzugefügt wird). svn stellt nichts ‚aus Versehen‘ ein; dazu bedarf es immer eines ‚svn add‘-Kommandos. Zusätzliche Dateien in einem lokalen Checkout werden einfach ignoriert.
Re: [Neo] [SVN] Dateien lokal ignorrieren?
Hallo allerseits, Hans-Christoph Wirth ſchrieb am 02.07.2009 15:20 Uhr: svn stellt nichts ‚aus Versehen‘ ein; dazu bedarf es immer eines ‚svn add‘-Kommandos. Zusätzliche Dateien in einem lokalen Checkout werden einfach ignoriert. Das ist mir schon klar, aber nichtversionierte Dateien im lokalen Checkout werden trotzdem bei nächsten Add von TortoiseSVN vorgeschlagen, und bei einem add * auf der Kommandozeile hat man das selbe Problem, dass man so unter Umständen aus Versehen Dateien eincheckt, die man gar nicht einchecken wollte. Genau für solche Zwecke ist SVN-ignore gedacht. Meine Frage war, ob man diese Regeln auch auf das lokale Checkout begrenzen kann oder ob man sie immer direkt im Repo eintragen muss (da Mœsi hier so eine Regel gelöscht hatte). Viele Grüße, Dennis-ſ
Re: [Neo] Drehen-Taste und Afrikanisch
Hallo aleχ, Hans-Christoph Wirth ſchrieb am 02.07.2009 09:12 Uhr: On Wednesday, 1. July 2009 21:15:09 Alexander Koch wrote: Ich finde schade, dass sich bisher noch niemand zu meinem Vorschlag mit der Haken-Taste geäußert hat, Betrachte das als allgemeine Zustimmung: Schlechte Vorschläge werden hier auf der Liste üblicherweise sehr schnell zerrissen. Ja, da ist was dran :-). Der Vorschlag mit Drehungen und Häkchen ist gut durchdacht, er erweitert die Funktionalität sinnvoll, und Interferenzen mit dem status quo scheinen sich auf ein Minimum zu beschränken. Ja, auch dem kann ich inhaltlich voll zustimmen :-). Viele Grüße, Dennis-ſ
Re: [Neo] [ticket] #141: Neue xkbmap-Version setzt xkbmap außer Gefecht
#141: Neue xkbmap-Version setzt xkbmap außer Gefecht --+- Reporter: martin_r | Owner: erik Type: Fehler/Defekt| Status: assigned Priority: normal | Milestone: Neo Version 2.0 Component: Treiber: Linux – Xkbmap | Version: 2.0 BETA Resolution: |Keywords: --+- Comment(by aleχ): Hallo, also ich habe jetzt auch mal auf die aktuellste Version gewechselt (hatte vorher die Version ohne Locks, welche einwandfrei funktioniert hatte) und nun geht Ebene 6 nicht mehr richtig, bei den Navigationszeichen 4vlcwuiaeoä reagiert er so wie in Ebene4, alle anderen Zeichen, auch üö (∪∩) funktionieren prima. Habe Gentoo, x11-base/xorg-server-1.6.1.901-r4, und auch das config-paket auf Version 1.6. -- Ticket URL: https://wiki.neo-layout.org/ticket/141#comment:28 Neo-Layout http://neo-layout.org/ Das Neo-Tastaturlayout ist ein freies und ergonomisch optimiertes Tastaturlayout für die deutsche Sprache, das auch sehr viele Sonderzeichen direkt verfügbar macht.
[Neo] [ticket] #148: Cokos werden nach Drü cken von Mod4 beendet
#148: Cokos werden nach Drücken von Mod4 beendet -+-- Reporter: aleχ | Owner: Type: Fehler/Defekt| Status: new Priority: normal | Milestone: Neo Version 2.0 Component: Treiber: Linux – Xkbmap | Version: 2.0 BETA Keywords: | -+-- Hallo, das Problem habe ich nun schon seit einem halben Jahr, bin aber noch nicht dahinter gekommen und wollte es jetzt doch nochmal melden, weil es mich nervt und ich einiges nicht testen kann: Ich kann z.B. ohne Probleme ♫ae → æ eingeben. Wenn ich aber ♫a eingebe, dann kurz Mod4 drücke (und z.B. wieder loslasse) und ich danach e eingebe, so erscheint das e direkt und alleine, die Coko wurde ohne Wirkung beendet. Dies ist auch ein Problem, da ich keine Cokos, die Mod4 tatsächlich brauchen eingeben kann, also ♫⊥⊥ oder ↻⊥, denn egal in welchem Zusammenhang, auch bei deadkeys wie ↻ beendet das Drücken von Mod4 die Coko. Ich glaube, dass es mal irgendwann auf meinem System richtig funktioniert hat, aber kann nicht mehr sagen, welche Änderung das Problem hervorgebracht hat. Hier noch /etc/hal/fdi/policy/10-x11-input.fdi: ?xml version=1.0 encoding=UTF-8? match key=info.capabilities contains=input.keys merge key=input.x11_driver type=stringevdev/merge merge key=input.x11_options.XkbModel type=stringevdev/merge merge key=input.x11_options.XkbLayout type=stringde/merge merge key=input.x11_options.XkbVariant type=stringneo/merge /match Habe Gentoo, den aktuellen xkbmap-Treiber, sowie Compose.neo. Viele Grüße, Aleχ -- Ticket URL: https://wiki.neo-layout.org/ticket/148 Neo-Layout http://neo-layout.org/ Das Neo-Tastaturlayout ist ein freies und ergonomisch optimiertes Tastaturlayout für die deutsche Sprache, das auch sehr viele Sonderzeichen direkt verfügbar macht.
Re: [Neo] [ticket] #148: Cokos werden nach Drü cken von Mod4 beendet
#148: Cokos werden nach Drücken von Mod4 beendet --+- Reporter: aleχ | Owner: Type: Fehler/Defekt| Status: new Priority: normal | Milestone: Neo Version 2.0 Component: Treiber: Linux – Xkbmap | Version: 2.0 BETA Resolution: |Keywords: --+- Comment(by pascal): Mit der Xmodmap funktioniert es korrekt, relevant sind nicht die gedrückten Tasten, sondern die gesendeten Zeichen (wobei Multikey, also ♫, als eigenes Zeichen zählt – so werden, sofern nicht explizit definiert, Verschachtelungen vermieden) Da es also grundsätzlich funktioniert, sollte der die Zeichen liefernde Tastaturtreiber egal sein. -- Ticket URL: https://wiki.neo-layout.org/ticket/148#comment:1 Neo-Layout http://neo-layout.org/ Das Neo-Tastaturlayout ist ein freies und ergonomisch optimiertes Tastaturlayout für die deutsche Sprache, das auch sehr viele Sonderzeichen direkt verfügbar macht.
Re: [Neo] [ticket] #141: Neue xkbmap-Version setzt xkbmap außer Gefecht
#141: Neue xkbmap-Version setzt xkbmap außer Gefecht --+- Reporter: martin_r | Owner: erik Type: Fehler/Defekt| Status: assigned Priority: normal | Milestone: Neo Version 2.0 Component: Treiber: Linux – Xkbmap | Version: 2.0 BETA Resolution: |Keywords: --+- Comment(by aleχ): Huch, als Ergänzung etwas merkwürdig: Das Problem tritt in kwrite auf, nicht aber in xev, oowriter, konsole. Kann mir nicht vorstellen, wie dieser Bug zustande kommt. -- Ticket URL: http://wiki.neo-layout.org/ticket/141#comment:29 Neo-Layout http://neo-layout.org/ Das Neo-Tastaturlayout ist ein freies und ergonomisch optimiertes Tastaturlayout für die deutsche Sprache, das auch sehr viele Sonderzeichen direkt verfügbar macht.
