Lazarus Interna verstehen, Weg des Tastencodes bis zum Eventhandler der LCL

Für Fragen zur Programmiersprache auf welcher Lazarus aufbaut
Antworten
thosch
Beiträge: 284
Registriert: Mo 10. Jul 2017, 20:32

Lazarus Interna verstehen, Weg des Tastencodes bis zum Eventhandler der LCL

Beitrag von thosch »

In diesem Strang:
posting.php?mode=edit&f=10&p=124912

habe ich gefragt, wie ich von der Tastatur aus an die eigegebenen Zeichen komme wenn ich sie ausgeben will. Mit der LCL geht das ja wie geschmiert.

Nun möchte ich aber gerne verstehen, wieso das in der LCL funktioniert, ohne LCL aber nicht.


In der System Unit gibt es die Funktionen UTF8Encode und UTF8Decode, damit funktioniert das aber nicht wenn ich nicht die beiden Ereignisse verwende, die aber nur in der LCL definiert sind. Wie mache ich das nun ohne LCL.

Wie haben das die Lazarus Entwickler gemacht oder wie würden sie das machen wenn die Arbeit der Entwicklung geteilt worden wäre und einer die LCL baut und ein anderer diese UTF8 Codes liefert, die dann an den Parameter UTF8Key des EventHandlers übergeben werden. Woher also kommen diese an UTF8Key übergebenen Codes auf dem Weg von der Tastatur dorthin?

In welchen Units muss ich da nachschauen, die das für die LCL bereit stellen?

Ist ja gut und schön, dass Lazarus das so toll macht, aber wie passiert das intern?

Benutzeravatar
af0815
Lazarusforum e. V.
Beiträge: 4765
Registriert: So 7. Jan 2007, 10:20
OS, Lazarus, FPC: FPC fixes Lazarus fixes per fpcupdeluxe (win,linux,raspi)
CPU-Target: 32Bit (64Bit)
Wohnort: Niederösterreich
Kontaktdaten:

Re: Lazarus Interna verstehen, Weg des Tastencodes bis zum Eventhandler der LCL

Beitrag von af0815 »

In der LCL kommt man recht rasch auf das Problem, das es spezifische includes gibt, die je nach CPU/BS/Whatever eingebunden werden. Das macht es schon mal schwerer das zu finden. Wenn man es weis gehts schon besser :-)

Form-> TwinCOntrol property OnUTF8KeyPress ist ein Callback

in TWinControl werden die Messages
procedure CNKeyDown(var Message: TLMKeyDown); message CN_KEYDOWN;
procedure CNSysKeyDown(var Message: TLMKeyDown); message CN_SYSKEYDOWN;
procedure CNKeyUp(var Message: TLMKeyUp); message CN_KEYUP;
procedure CNSysKeyUp(var Message: TLMKeyUp); message CN_SYSKEYUP;
procedure CNChar(var Message: TLMKeyUp); message CN_CHAR;
verarbeitet. Die kommen vom BS.

Die meisten CN verwenden dann TWinControl.DoKeyDownBeforeInterface wo schon viel zugeordnet wird.

So hast du jetzt einen Anfang erhalten :-) wo man sucht.

Schau mal nach wohin CNChar führt -> IntfUTF8KeyPress -> DoUTF8KeyPress :mrgreen: von dort gehts Richtung OnUTF8KeyPress . Ziel erreicht.
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).

Benutzeravatar
theo
Beiträge: 8711
Registriert: Mo 11. Sep 2006, 19:01

Re: Lazarus Interna verstehen, Weg des Tastencodes bis zum Eventhandler der LCL

Beitrag von theo »

Soweit ich weiss, regelt das Betriebssystem diese Dinge. Unter Linux z.B. X11.
https://tronche.com/gui/x/xlib/utilities/keyboard/

Mit dem Linux Programm "xev" kann man gut sehen, wie das abläuft. Hier z.B. ein Euro Zeichen (AltGr + E).
KeyPress event, serial 40, synthetic NO, window 0x7c00001,
root 0x17d, subw 0x0, time 68582151, (118,128), root:(118,157),
state 0x10, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES,
XKeysymToKeycode returns keycode: 92
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False

KeyPress event, serial 40, synthetic NO, window 0x7c00001,
root 0x17d, subw 0x0, time 68582407, (118,128), root:(118,157),
state 0x90, keycode 26 (keysym 0x20ac, EuroSign), same_screen YES,
XLookupString gives 3 bytes: (e2 82 ac) "€"
XmbLookupString gives 3 bytes: (e2 82 ac) "€"
XFilterEvent returns: False

KeyRelease event, serial 40, synthetic NO, window 0x7c00001,
root 0x17d, subw 0x0, time 68582487, (118,128), root:(118,157),
state 0x90, keycode 26 (keysym 0x20ac, EuroSign), same_screen YES,
XLookupString gives 3 bytes: (e2 82 ac) "€"
XFilterEvent returns: False

KeyRelease event, serial 40, synthetic NO, window 0x7c00001,
root 0x17d, subw 0x0, time 68582615, (118,128), root:(118,157),
state 0x90, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES,
XKeysymToKeycode returns keycode: 92
XLookupString gives 0 bytes:
XFilterEvent returns: False

thosch
Beiträge: 284
Registriert: Mo 10. Jul 2017, 20:32

Re: Lazarus Interna verstehen, Weg des Tastencodes bis zum Eventhandler der LCL

Beitrag von thosch »

af0815: Genau das werde ich mir jetzt die nächsten Tage ansehen, Danke! So kann ich den für mein Problem relevanten Quellcode studieren.

@theo: Auch ne Möglichkeit. Ist mir aber mit xev Kommando leider zu unbersichtlich die Ausgabe. Die Codes scheinen von System zu System verschieden zu sein, ich erhalte unter Windws einen anderen Code für das 'ß' als unter Windows. Habe auf Terminal unter Whonix xev aufgerufen und danach das 'ß' gedrückt. Die Codes in Windows und in Linux unterscheiden sich. Bringt mich aber erst mal nicht weiter. Trotzdem Danke, habe dadurch ein neues Linux Kommando erlernt, das ich mit auch noch genauer anschauen werde. Werde aber auch unter Linux das Quellcodestudium nach @af0815 anwenden da ich das für ein Lazarus Projekt benötige.

Benutzeravatar
Winni
Beiträge: 990
Registriert: Mo 2. Mär 2009, 16:45
OS, Lazarus, FPC: Laz2.0.12, fpc 3.2
CPU-Target: 64Bit
Wohnort: Fast Dänemark

Re: Lazarus Interna verstehen, Weg des Tastencodes bis zum Eventhandler der LCL

Beitrag von Winni »

Hi!

Was Du suchst, ist der Tastatur-Scancode.

Wikipedia gibt eine dürftige Erklärung:

https://de.wikipedia.org/wiki/Scancode


Ich bin ja froh, wenn die entsprechende Taste das gleichlautende Resultat ergibt. Dafür sind Betriebssysteme da. Egal was sie nun intern treiben.

Vielleicht erklärst Du mal, was Du suchst????


Winni

thosch
Beiträge: 284
Registriert: Mo 10. Jul 2017, 20:32

Re: Lazarus Interna verstehen, Weg des Tastencodes bis zum Eventhandler der LCL

Beitrag von thosch »

@winni:

Wie soll ich das verständlich erklären?

Kennst Du den Raspberry PI?

Ok, wenn der ein Linux vorinstalliert hat, hat der auch Tastatur EIN/Ausgabe, sogar auf der Konsole.

Wenn Freedos vorinstaliert ist, dann auch.

Lazarus bietet Tastatur Ein/Ausgabe mindesten in LAzarus und seinen Komponenten ebenfalls.

Ich arbeite nun an einem Grafikausgabe Programm, mit dem später Demos gebaut werden können, die die Leistungsfähigkeit einer beliebigen Grafikbibliothek aufzeigen, indem Grafikfunktionen dieser Bibliothek ausgeführt werden. Der Anwender sieht dann, wie schenell diese Funktionen dieser Grafikbibliothek ausgeführt werden.

Wie aber soll ich nun innerhalb dieser Bibliothek Buchstaben eingeben, wenn die Codes nicjht mehr den klassischen Ascii Codes entsprechen. DAmals war das einfach, man hat mit chr('<Ascii Code>') den Buchstaben erhalten und mit ord(<Buchstabe>) das Zeichen.

Ich will nun eine Tastatureingaberoutine haben die im Grafikmodus läuft, aber ohne LCL auskommt, also auch mit SVGALib läuft, auch unter Windows, wo ich die SVGALib nachbauen muss. Warum muss ich die dort nachbauen?

Weil mir keine auf Windows basierende SVGALIb bekannt ist.

Wozu brauche ich diese SVGALIb?

Um Consolengrafik damit bauen zu können.

Geht das nicht unter Windows mit anderen Grafikbibliotheken?

Ja, das geht, ist aber dann nicht für Linux verwendbar.

Warum soll das für Linux verwendbar sein?

Weil sich dann auch grafische Benutzeroberflächen bauen lassen, die ohne XServer auskommen, was Rechenleistung spart, gerade bei älteren Rechnern oder dem Rapberry PI.

Wäre es nicht klasse, wenn es eine GUI Komponentensammlung gäbe, mit der man GUI Anwendungen entwickeln könnte, die vom Consolenprompt aus startbar sind und den XServer nicht benötigen?

Programmierer wollen sich auf die Geschäftslogik ihrer Software konzentrieren können und sich nicht mit der Benutzeroberfläche aufhalten.

Anwender wollen eine möglichst intuitive Benutzeroberfläche. Die können heutige Rechner von ihrer Hadrwareleistung her locker bereit stellen. Die Linus Desktops LXDE, XFCE, KDE, Gnome erfüllen da alle Ansprüche. Aber allesamt brauchen die eine raltiv aufwendige Grafikschnittstelle, den XServer. Aber sogar wenn dieser installiert ist, kann ich unter Linux von der Console aus kein LXDE oder XFCE oder KDE oder Gnome Programm aufrufen, dazu muss ich in den Grafikmodus umschalten indem ich zuerst den XServer starte.

Ich will nun eine Grafik und GUI Bibliothek bauen, die ohne XServer auskommt, deshalb brauche ich SVGALib, die die wichtigsten Grafikfunktionen und ebenso eine einfache Fensterverwaltung mit den grundlegenden Widgets, wie Eingabezeile, Texteditor, CheckBox, Radiobutton, Button (Ok, Cancel, ...), Toolbuttons,... Daran arbeite ich aktuell.

Habe bisher in WIndows programmiert, mit einer selber implementierten SVGALib, deren Funktionsköpfe ja im Freepascal Quellcode enthalten sind. Dort habe ich die external Anweisungen entfernt und diese Funktionen mittles einer anderen Grafikbibliothek nachbebaut. Es handelt sich Faktisch um einen Warapper. Dessen Funktionen entsprechen denen der SVGALib, nur habe ich die Grafik mit einer anderen Grafiklib nachgebildet. Meine GUI Klassen rufen nun diese nachgebildeten SVGALib Funktionen auf.

Die GUI soll nur grundlegende Widgets enthalten. Aber die Möglichkeit schaffen, GUI Anwendungen und auch Demos herzustellen die grafisch daher kommen aber dank SVGALib auch ohne XServer ausgeführt werden können. Um die Systemunabhängigkeit auch unter Windows zu testen, habe ich mir eine auf Windows Grafik aufbauende SVGALib gebaut, mit der ich meine GUI dann auch unter Windows testen kann.

UNter Linux muss ich mir dann die echte SVGALib intallieren um deren Funktionen aufrufen zu können.

Dafür fehlt mir nun aber noch die Tastaturabfrage. Mit der Maus kann ich bereits GUI Widgets anklicken und verschieben und deren Größe ändern. Höchste Zeit nun auch die TAstatureingabe zu implementieren, dabei erhalte ich aber wie im Eingangsbeitrag schon geschrieben zum Teil falsche Zeichen.

PascalDragon
Beiträge: 397
Registriert: Mi 3. Jun 2020, 07:18
OS, Lazarus, FPC: L 2.0.8, FPC Trunk, OS Win/Linux
CPU-Target: Aarch64 bis Z80 ;)
Wohnort: München

Re: Lazarus Interna verstehen, Weg des Tastencodes bis zum Eventhandler der LCL

Beitrag von PascalDragon »

Die LCL verlässt sich darauf, dass das jeweilige Widgetset (WinAPI, Qt, GTK, Cocoa, MUI, etc.) sich um die Ereignisbehandlung kümmert (egal ob Maus oder Tastatur). Unter Linux verwendet das jeweilige Widgetset dann die API des X-Servers oder von Wayland, um an die Tastaturereignisse zu kommen. Und diese verwenden wiederum das Inputevent System des Kernels.

Wenn du das ganze für dich selbst machen möchtest, dann solltest du am Besten die libinput verwenden, da diese dir das Eingabesystem für Linux abstrahiert und ohne GUI auskommt (und auch von X11 und Wayland genutzt wird). Du wirst nicht drum herum kommen unterschiedlichen Code für Linux und Windows (und was auch immer sonst) zu schreiben.

Außerdem solltest du unter Linux besser entweder DirectFB oder zumindest den Linux Framebuffer nutzen, da SVGALib einzig und allein auf x86 32-bit Systemen verfügbar ist. Nutzt du ein 64-bit Linux so hast du schon verloren, da im LongMode (der für 64-bit genutzt wird) der VM86 Modus nicht verfügbar ist (der für VGA und VESA Aufrufe nötig ist). Und auf nicht-x86 Plattformen (du hast zum Beispiel den Pi erwähnt) hast du eh kein VGA/VESA verfügbar.
FPC Compiler Entwickler

thosch
Beiträge: 284
Registriert: Mo 10. Jul 2017, 20:32

Re: Lazarus Interna verstehen, Weg des Tastencodes bis zum Eventhandler der LCL

Beitrag von thosch »

Welche Lazarus Units sind da meine Freunde:

-für die Nutzung von

- DirectFB

- Linux Framebuffer

- libinput

Durch das Stöbern in diesen Links habe ich auch noch Raylib und die Pascal Port Datei Ray4Lazmin.zip gefunden.

Ich verwende zur Grafikausgabe die FCLImage Komponenten, ich habe mir da eine TFPfclCanvas Klasse gebaut, die die Grafikausgabe regelt.

Dazu brauche ich irgendeine darunter liegende Grafikbibliothek, die auch Sprites anzeigen, bewegen und in ihrer Größe ändern können sollte. Wenn DirectFB oder Linix Framebuffer dazu völlig ausreicht, um so besser.

Wenn diese Grafikbibliothek schon GUI Widgets mitbringt, um so besser, ansonsten kann ich diese Widgets auch bereit stellen. Die darunter liegende Grafikbibliothek soll dann wegen ihrer Verfügbarkeit auf allen Plattformen die Schnittstelle zwischen Hardware und Bildschirmoberfläche herstellen und so garantieren dass die Grafik und GUI überall läuft. Dann können kleinere Anwendungen im GUI look hergestellet werden die sich vom Konsolenpromt aus starten lassen.

Welche Lazarus Units sind da nun meine Freunde um DirectFB oder LinuxFrameBuffer oder libinput nutzen zu können?

Und wo finde ich aussagekräftige und Anfängerfreundliche Dokumentation dazu?

PascalDragon
Beiträge: 397
Registriert: Mi 3. Jun 2020, 07:18
OS, Lazarus, FPC: L 2.0.8, FPC Trunk, OS Win/Linux
CPU-Target: Aarch64 bis Z80 ;)
Wohnort: München

Re: Lazarus Interna verstehen, Weg des Tastencodes bis zum Eventhandler der LCL

Beitrag von PascalDragon »

thosch hat geschrieben:
Mi 1. Dez 2021, 11:07
Welche Lazarus Units sind da meine Freunde:

-für die Nutzung von

- DirectFB

- Linux Framebuffer

- libinput
Ich weiß nicht, ob da jemand schon Units dafür geschrieben hat, im Zweifel musst du das selbst machen.
thosch hat geschrieben:
Mi 1. Dez 2021, 11:07
Dazu brauche ich irgendeine darunter liegende Grafikbibliothek, die auch Sprites anzeigen, bewegen und in ihrer Größe ändern können sollte. Wenn DirectFB oder Linix Framebuffer dazu völlig ausreicht, um so besser.

Wenn diese Grafikbibliothek schon GUI Widgets mitbringt, um so besser, ansonsten kann ich diese Widgets auch bereit stellen. Die darunter liegende Grafikbibliothek soll dann wegen ihrer Verfügbarkeit auf allen Plattformen die Schnittstelle zwischen Hardware und Bildschirmoberfläche herstellen und so garantieren dass die Grafik und GUI überall läuft. Dann können kleinere Anwendungen im GUI look hergestellet werden die sich vom Konsolenpromt aus starten lassen.
DirectFB und Linux Framebuffer sind low level Systeme. Das heißt du hast letztlich einen Puffer im Speicher mit bestimmter Größe. Du schreibst deine Pixel da rein und sagst ihm unter Umständen noch, dass jetzt die Puffer gewechselt werden können. Der Rest (Sprites, Widgets, etc.) ist alles Handarbeit.
thosch hat geschrieben:
Mi 1. Dez 2021, 11:07
Und wo finde ich aussagekräftige und Anfängerfreundliche Dokumentation dazu?
Bei den jeweiligen Projekten. Du wirst da nicht umhin kommen dich mit C Code und Beispielen auseinander zu setzen.
FPC Compiler Entwickler

Antworten