Interfaces - Wofür ist die NoGui Schnittstelle von Lazarus?

Für Dinge rund um die Unterstützung des offizielen Lazarusprojekts, wie Übersetzungsabsprachen und anderem.
Anonymus
Beiträge: 31
Registriert: Di 15. Dez 2015, 10:36

Interfaces - Wofür ist die NoGui Schnittstelle von Lazarus?

Beitrag von Anonymus »

Hallo!

Ich habe mir mal die Lazarus Verzeichnisse angeguckt und auch ..\lcl\interfaces gefunden.

Dort gibt es ein Verzeichnis mit dem Namen "nogui"

Wofür ist das?

mschnell
Beiträge: 3444
Registriert: Mo 11. Sep 2006, 10:24
OS, Lazarus, FPC: svn (Window32, Linux x64, Linux ARM (QNAP) (cross+nativ)
CPU-Target: X32 / X64 / ARMv5
Wohnort: Krefeld

Re: Interfaces - Wofür ist die NoGui Schnittstelle von Lazar

Beitrag von mschnell »

Lazarus (die LCL) kann verschiedene Widget-Sets aufrufen, um eine grafische Oberfläche für das Programm zur Verfügung zu stellen. Man kann in den Projekt-Optionen aussuchen, welcher "WidgetType" verwendet werden soll.

"NoGUI" verbindet sich mit keinem Widget Set und ist daher auch auf "Headess" Systmen (die keine grafische Oberfläche unterstützen, meist Linux) einsetzbar.

Die aktuelle Version von NoGUI ist "passiv" und stellt keine Event-Queue (und damit z.B. auch keinen TTimer) zur Verfügung.

Ich habe vor einiger Zeit mal eine aktive Version angefangen. Das ist aber nicht nicht wirklich verwendbar.

Das MSE-System bietet bereits die Möglichkeit aktive NoGUI Programme zu erzeugen.

-Michael

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

Re: Interfaces - Wofür ist die NoGui Schnittstelle von Lazar

Beitrag von theo »

Naja, diese Erklärung ist aber mMn nicht ganz verständlich.

Man kann natürlich ohne weiteres normale Kommandozeilen Programme oder Dienste mit Lazarus machen.

Wenn ich das richtig verstanden habe, kann man mit NoGui ansatzweise so arbeiten, wie man es von der GUI Programmierung in Lazarus gewohnt ist.
Also mit Komponenten und dem Objektinspektor.
Das mag bei einigen nicht visuellen Komponenten wie Indy halbwegs Sinn ergeben, aber so richtig eingeleuchtet hat mir diese Idee nie.

Kann auch sein, dass ich es nicht verstanden habe.

mschnell
Beiträge: 3444
Registriert: Mo 11. Sep 2006, 10:24
OS, Lazarus, FPC: svn (Window32, Linux x64, Linux ARM (QNAP) (cross+nativ)
CPU-Target: X32 / X64 / ARMv5
Wohnort: Krefeld

Re: Interfaces - Wofür ist die NoGui Schnittstelle von Lazar

Beitrag von mschnell »

theo hat geschrieben:Wenn ich das richtig verstanden habe, kann man mit NoGui ansatzweise so arbeiten, wie man es von der GUI Programmierung in Lazarus gewohnt ist.


TTimer, TThread.Synchronize, TThread.Queue und Application.QueuAsyncCall funktionieren ohne Message Queue nicht.

Man kann sich natürlich selber im User-Code eine Message-Queue aufbauen in der dann auch für TThread.Synchronize und TThread.Queue die funcktion "checkSynchronize()" aus der FPC-RTL aufgerufen wird. So macht das ja die Erweiterung für "NoGUI", die ich in Arbeit habe. Um zu "arbeiten, wie man es von der GUI Programmierung in Lazarus gewohnt ist", (also ausschießlich "Event-Orientiertes Programmieren" im User-code <main Thread>) müsste m.A. aber die Queue bereits von der LCL zur Verfügung gestellt werden.

-Michael

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

Re: Interfaces - Wofür ist die NoGui Schnittstelle von Lazar

Beitrag von theo »

Also für den TE in einfache Worte gefasst: Vergiss es! :wink:

Anonymus
Beiträge: 31
Registriert: Di 15. Dez 2015, 10:36

Re: Interfaces - Wofür ist die NoGui Schnittstelle von Lazar

Beitrag von Anonymus »

mschnell hat geschrieben:
theo hat geschrieben:Wenn ich das richtig verstanden habe, kann man mit NoGui ansatzweise so arbeiten, wie man es von der GUI Programmierung in Lazarus gewohnt ist.


TTimer, TThread.Synchronize, TThread.Queue und Application.QueuAsyncCall funktionieren ohne Message Queue nicht.

Man kann sich natürlich selber im User-Code eine Message-Queue aufbauen in der dann auch für TThread.Synchronize und TThread.Queue die funcktion "checkSynchronize()" aus der FPC-RTL aufgerufen wird. So macht das ja die Erweiterung für "NoGUI", die ich in Arbeit habe. Um zu "arbeiten, wie man es von der GUI Programmierung in Lazarus gewohnt ist", (also ausschießlich "Event-Orientiertes Programmieren" im User-code <main Thread>) müsste m.A. aber die Queue bereits von der LCL zur Verfügung gestellt werden.

-Michael


Wie weit ist diese Arbeit an der NoGui Erweiterung fortgeschritten? Und wie wird die Message Queue da realisiert?

Langsam aber sicher frage ich mich allerdings, wie das Microsoft mit Windows 9x und Windowas 3.x gelöst hat. Da war DOS noch der Unterbau. Beim NT Kernel kann das Problem ja schom im Systemdesign berücksichtigt worden sein, aber in Zusammenwirken mit DOS?

CheckSynchronize verlässt sich ja letzlich auch auf Windows Funktionen, wie ich das auf die Schnelle gesehen habe.

@theo:

Wäre schade, aber ich gebe die Hoffnung dank Michaels Arbeit noch nicht ganz und gar auf. Schaun mar mal. Wenn wirklich nix geht, dann eben nicht.

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

Re: Interfaces - Wofür ist die NoGui Schnittstelle von Lazar

Beitrag von theo »

Anonymus hat geschrieben:@theo:

Wäre schade, aber ich gebe die Hoffnung dank Michaels Arbeit noch nicht ganz und gar auf. Schaun mar mal. Wenn wirklich nix geht, dann eben nicht.


Welche Hoffnung? Was erhoffst du dir denn?
Du hast ja ursprünglich nur gefragt, wozu das gut sei.

mschnell
Beiträge: 3444
Registriert: Mo 11. Sep 2006, 10:24
OS, Lazarus, FPC: svn (Window32, Linux x64, Linux ARM (QNAP) (cross+nativ)
CPU-Target: X32 / X64 / ARMv5
Wohnort: Krefeld

Re: Interfaces - Wofür ist die NoGui Schnittstelle von Lazar

Beitrag von mschnell »

Anonymus hat geschrieben:Wie weit ist diese Arbeit an der NoGui Erweiterung fortgeschritten? Und wie wird die Message Queue da realisiert?

Die "normalen" Widget-Sets haben (mindestens) zwei Message Queues. Die eine ist in der FPC RTL realisiert und die handler für die gequeten Events werden in "Checksynchronize()" aufgerufen. Die andere ist durch Funktionalität des Widget-Sets (Windows, QT, ...) realisiert, mit den sich das Programm verbindet.

Meine NoGUI Erweiterung verwendet ausschließlich die Queue aus der FPC-RTL (mit Hilfe von TThread.Queue). Und TTimer ist durch den Timeout-Parameter von CheckSynchronize realisiert. Das funktioniert OS- und Architektur-Unabhängig ohne "Klimmzüge".

Anonymus hat geschrieben:CheckSynchronize verlässt sich ja letzlich auch auf Windows Funktionen, wie ich das auf die Schnelle gesehen habe.
Offensichtlich hast Du nicht in den Sourcecode der Linux Variante geguckt :D .

Ist mir aber auch egal, da ich CheckSynchronize einfach benutze und hoffe das es tut, was es soll. Ich habe es nur unter Linux getestet.

-Michael

Anonymus
Beiträge: 31
Registriert: Di 15. Dez 2015, 10:36

Re: Interfaces - Wofür ist die NoGui Schnittstelle von Lazar

Beitrag von Anonymus »

mschnell hat geschrieben:Meine NoGUI Erweiterung verwendet ausschließlich die Queue aus der FPC-RTL (mit Hilfe von TThread.Queue). Und TTimer ist durch den Timeout-Parameter von CheckSynchronize realisiert. Das funktioniert OS- und Architektur-Unabhängig ohne "Klimmzüge".

mschnell hat geschrieben: Offensichtlich hast Du nicht in den Sourcecode der Linux Variante geguckt :D .


Habe ich wirklich noch nicht, da ich mit Windows arbeite. Setzt das dann auf Linux Console oder X-Server auf?

mschnell hat geschrieben:Ist mir aber auch egal, da ich CheckSynchronize einfach benutze und hoffe das es tut, was es soll. Ich habe es nur unter Linux getestet.

-Michael


Klar! Wenn es funktioniert ist das auch richtig so. Es sei sdenn man will den Ouellcode genauer studieren, um zu sehen, wie es warum funktioniert.

Werde mir die Thread Units plus Check Syncronize aber nun ach genauer anschauen. Könnte man da nicht auch die LCL auf MseGui aufsetzen? Obwohl dann noch eine Message Queue, die der MSE Gui dazu käme.

In einem Multi Tasking System sehe ich den Sinn mehrerer Message-Queue's darin, dass das Betriebssysten ja eine braucht, welche die einzelnen Programme ansteuern kann, um ein aktuell zu bedienendes auszuwählen. Die anderen Message Queue's ssind dann den Programmen zugeordnet, damit die bedient werden können.

Nun verstehe ich aber nicht, warum nun neben der Message-Queue in der LCL noch eine gebraucht wird, um die Schnittstelle zum Betriebssystem bilden zu können. In Windows ist die System Message Queue schon vorhanden, in Linux auch, da Linux auch ein Multitasking System ist.

Warum also wird im Fall unserer Schnittstelle nun die zweite Message Queue gebraucht? Ich habe da ein Verständnisproblem. Kann das aufgeklärt werden?

mse
Beiträge: 2013
Registriert: Do 16. Okt 2008, 10:22
OS, Lazarus, FPC: Linux,Windows,FreeBSD,(MSEide+MSEgui 4.6,git master FPC 3.0.4,fixes_3_0)
CPU-Target: x86,x64,ARM

Re: Interfaces - Wofür ist die NoGui Schnittstelle von Lazar

Beitrag von mse »

Anonymus hat geschrieben:Werde mir die Thread Units plus Check Syncronize aber nun ach genauer anschauen. Könnte man da nicht auch die LCL auf MseGui aufsetzen? Obwohl dann noch eine Message Queue, die der MSE Gui dazu käme.

Man könnte auch MSEide+MSEgui direkt verwenden. ;-)
In einem Multi Tasking System sehe ich den Sinn mehrerer Message-Queue's darin, dass das Betriebssysten ja eine braucht, welche die einzelnen Programme ansteuern kann, um ein aktuell zu bedienendes auszuwählen. Die anderen Message Queue's ssind dann den Programmen zugeordnet, damit die bedient werden können.

Nun verstehe ich aber nicht, warum nun neben der Message-Queue in der LCL noch eine gebraucht wird, um die Schnittstelle zum Betriebssystem bilden zu können. In Windows ist die System Message Queue schon vorhanden, in Linux auch, da Linux auch ein Multitasking System ist.

Warum also wird im Fall unserer Schnittstelle nun die zweite Message Queue gebraucht? Ich habe da ein Verständnisproblem. Kann das aufgeklärt werden?

Im Falle von MSEgui wird zwischen GUI und nicht-GUI Anwendungen unterschieden, indem entweder "msegui" und "mseapplication" oder "msenoguiapplication" in "uses" des Hauptprogrammes aufgeführt werden.
Um plattformunabhängig zu sein implementiert MSEgui seine event-queue in TcustomApplication. Die plattformabhängigen units "mseguiintf" bereiten die vom Graphik- und IO-System der Plattform stammenden messages auf und speisen sie in die event-queue von TCustomApplication.
"msenoguiapplication" benötigt kein Graphiksystem und keine System-message-queue und stellt trotzdem die volle event-queue Funktionalität zur Verfügung.
Es lässt sich also auch in GUI-losen Systemen der RAD Ansatz mit Datamodulen und Komponenten inklusive TTimer und TThreadComp anwenden. Dies ist vor allem für Datenbank- und Webanwendungen praktisch und sehr produktiv.
Linux z.B. hat von Haus aus keine IO-message-queue, erst X11 stellt sie zur Verfügung. X11 ist auf den wenigsten Linux-Servern installiert.

Anonymus
Beiträge: 31
Registriert: Di 15. Dez 2015, 10:36

Re: Interfaces - Wofür ist die NoGui Schnittstelle von Lazar

Beitrag von Anonymus »

mse hat geschrieben:
Anonymus hat geschrieben:Werde mir die Thread Units plus Check Syncronize aber nun ach genauer anschauen. Könnte man da nicht auch die LCL auf MseGui aufsetzen? Obwohl dann noch eine Message Queue, die der MSE Gui dazu käme.

Man könnte auch MSEide+MSEgui direkt verwenden. ;-)
In einem Multi Tasking System sehe ich den Sinn mehrerer Message-Queue's darin, dass das Betriebssysten ja eine braucht, welche die einzelnen Programme ansteuern kann, um ein aktuell zu bedienendes auszuwählen. Die anderen Message Queue's ssind dann den Programmen zugeordnet, damit die bedient werden können.

Nun verstehe ich aber nicht, warum nun neben der Message-Queue in der LCL noch eine gebraucht wird, um die Schnittstelle zum Betriebssystem bilden zu können. In Windows ist die System Message Queue schon vorhanden, in Linux auch, da Linux auch ein Multitasking System ist.

Warum also wird im Fall unserer Schnittstelle nun die zweite Message Queue gebraucht? Ich habe da ein Verständnisproblem. Kann das aufgeklärt werden?

Im Falle von MSEgui wird zwischen GUI und nicht-GUI Anwendungen unterschieden, indem entweder "msegui" und "mseapplication" oder "msenoguiapplication" in "uses" des Hauptprogrammes aufgeführt werden.
Um plattformunabhängig zu sein implementiert MSEgui seine event-queue in TcustomApplication. Die plattformabhängigen units "mseguiintf" bereiten die vom Graphik- und IO-System der Plattform stammenden messages auf und speisen sie in die event-queue von TCustomApplication.
"msenoguiapplication" benötigt kein Graphiksystem und keine System-message-queue und stellt trotzdem die volle event-queue Funktionalität zur Verfügung.
Es lässt sich also auch in GUI-losen Systemen der RAD Ansatz mit Datamodulen und Komponenten inklusive TTimer und TThreadComp anwenden. Dies ist vor allem für Datenbank- und Webanwendungen praktisch und sehr produktiv.
Linux z.B. hat von Haus aus keine IO-message-queue, erst X11 stellt sie zur Verfügung. X11 ist auf den wenigsten Linux-Servern installiert.


So weit, so gut. Aber gibt es schon eine Lösung, die MSE Gui als Unterbau für die LCL zu verwenden? So wie das für die fpGUI schon der FAll ist oder für GTK oder qt?

Wenn es schon klappen sollte, wie installiere ich dann MSEGui in Lazarus?


Noch eine Verständnisfrage:

Dos hatte zwar auch nur die Kommandoshell, war aber ein SigleTasking System. Von TSR Prozessen abgesehen konnte DOS zur gleichen Zeit nur ein Programm ausführen. Linux aber kann Multitasking auch auf der Console. Dennoch kann ich einen der Hintergrundprozesse jederzeit in den Vordergrund holen und bei Bedarf bedienen. Wie macht Linux das. Haben die vom User bedienbaren Prozesse dann eine Kopie der Kommando-Shell integriert? Dann bleibt aber immer noch das Problem der Auswählbarkeit eines der Prozesse. Wie funktioniert das also dort?

.

mse
Beiträge: 2013
Registriert: Do 16. Okt 2008, 10:22
OS, Lazarus, FPC: Linux,Windows,FreeBSD,(MSEide+MSEgui 4.6,git master FPC 3.0.4,fixes_3_0)
CPU-Target: x86,x64,ARM

Re: Interfaces - Wofür ist die NoGui Schnittstelle von Lazar

Beitrag von mse »

Anonymus hat geschrieben:So weit, so gut. Aber gibt es schon eine Lösung, die MSE Gui als Unterbau für die LCL zu verwenden?

Nicht dass ich wüsste. Das macht auch keinen grossen Sinn, da MSEide+MSEgui ein in sich vollständiges und ausgereiftes System ist. Die Entwicklung startete im Jahr 1999 etwa gleichzeitig wie der Lazarus Vorgänger Megido. AFAIK meint Lazarus "der von den Toten Erweckte", also das widerauferstandene tote Megido Projekt.
So wie das für die fpGUI schon der FAll ist oder für GTK oder qt?

Das Lazarus fpGUI widgetset ist so viel ich weiss im Alpha-Stadium und wird nicht aktiv entwickelt. Auch für fpGUI macht meiner Meinung nach der Lazarus Überbau keinen Sinn. fpGUI gibt es hier:
http://fpgui.sourceforge.net/
Ich weiss nicht, ob fpGUI eine ereignisgesteuerte nogui-application anbietet, jedenfalls habe ich noch nie davon gehört.
Wenn es schon klappen sollte, wie installiere ich dann MSEGui in Lazarus?

MSEide+MSEgui gibt es hier:
https://sourceforge.net/projects/mseide-msegui/
MSEide ist eine vollständige, leistungsfähige und handliche RAD-Entwicklungsumgebung.
Noch eine Verständnisfrage:

Dos hatte zwar auch nur die Kommandoshell, war aber ein SigleTasking System. Von TSR Prozessen abgesehen konnte DOS zur gleichen Zeit nur ein Programm ausführen. Linux aber kann Multitasking auch auf der Console. Dennoch kann ich einen der Hintergrundprozesse jederzeit in den Vordergrund holen und bei Bedarf bedienen. Wie macht Linux das. Haben die vom User bedienbaren Prozesse dann eine Kopie der Kommando-Shell integriert? Dann bleibt aber immer noch das Problem der Auswählbarkeit eines der Prozesse. Wie funktioniert das also dort?

Die shell ist parent-process der gestarteten Anwendungen.
Mit "Linux" ist lediglich der Kernel gemeint. "Konsolen" sind unter Linux - und generell unter UNIX - Prozesse, welche mittels seriellen Verbindungen mit der Umgebung kommunizieren. Früher z.B. über RS232 mit einem Fernschreiber oder einem Bildschirmterminal, heute meist mittels Pseudoterminals welche die Zeichen via Framebuffer oder X11-Fenster darstellen oder über das Netzwerk mit einem anderen Computer via TELNET oder SSH. Eine oft genutzte shell ist "Bash". Bash kann in einer Sitzung verschiedene child-Prozesse verwalten:
https://www.gnu.org/software/bash/manua ... ob-Control

Anonymus
Beiträge: 31
Registriert: Di 15. Dez 2015, 10:36

Re: Interfaces - Wofür ist die NoGui Schnittstelle von Lazar

Beitrag von Anonymus »

mse hat geschrieben:
Anonymus hat geschrieben:So weit, so gut. Aber gibt es schon eine Lösung, die MSE Gui als Unterbau für die LCL zu verwenden?

Nicht dass ich wüsste. Das macht auch keinen grossen Sinn, da MSEide+MSEgui ein in sich vollständiges und ausgereiftes System ist. Die Entwicklung startete im Jahr 1999 etwa gleichzeitig wie der Lazarus Vorgänger Megido. AFAIK meint Lazarus "der von den Toten Erweckte", also das widerauferstandene tote Megido Projekt.
So wie das für die fpGUI schon der FAll ist oder für GTK oder qt?

Das Lazarus fpGUI widgetset ist so viel ich weiss im Alpha-Stadium und wird nicht aktiv entwickelt. Auch für fpGUI macht meiner Meinung nach der Lazarus Überbau keinen Sinn. fpGUI gibt es hier:
http://fpgui.sourceforge.net/
Ich weiss nicht, ob fpGUI eine ereignisgesteuerte nogui-application anbietet, jedenfalls habe ich noch nie davon gehört.
Wenn es schon klappen sollte, wie installiere ich dann MSEGui in Lazarus?

MSEide+MSEgui gibt es hier:
https://sourceforge.net/projects/mseide-msegui/
MSEide ist eine vollständige, leistungsfähige und handliche RAD-Entwicklungsumgebung.
Noch eine Verständnisfrage:

Dos hatte zwar auch nur die Kommandoshell, war aber ein SigleTasking System. Von TSR Prozessen abgesehen konnte DOS zur gleichen Zeit nur ein Programm ausführen. Linux aber kann Multitasking auch auf der Console. Dennoch kann ich einen der Hintergrundprozesse jederzeit in den Vordergrund holen und bei Bedarf bedienen. Wie macht Linux das. Haben die vom User bedienbaren Prozesse dann eine Kopie der Kommando-Shell integriert? Dann bleibt aber immer noch das Problem der Auswählbarkeit eines der Prozesse. Wie funktioniert das also dort?

Die shell ist parent-process der gestarteten Anwendungen.
Mit "Linux" ist lediglich der Kernel gemeint. "Konsolen" sind unter Linux - und generell unter UNIX - Prozesse, welche mittels seriellen Verbindungen mit der Umgebung kommunizieren. Früher z.B. über RS232 mit einem Fernschreiber oder einem Bildschirmterminal, heute meist mittels Pseudoterminals welche die Zeichen via Framebuffer oder X11-Fenster darstellen oder über das Netzwerk mit einem anderen Computer via TELNET oder SSH. Eine oft genutzte shell ist "Bash". Bash kann in einer Sitzung verschiedene child-Prozesse verwalten:
https://www.gnu.org/software/bash/manua ... ob-Control



Danke für die Antwort! Den Link werde ich mir auch ansehen.

Da sind wir einer Meinung bezüglich Sinnhaftigkeit von Widgetsets unterhalb der LCL. Ein vernüftiges Grafiksystem zur Anzeiger der Widgets und Images sollte ausreichen. Statdessen aber setzt die LCL auf andere Widgetsets auf, obwohl die LCL diese schon selber zeichnen könnte.

Die fpGUI hat keine NoGUI Schnittstelle. Die setzt direkt auf dem Windows API und unter Linus auf X11 auf.
Zuletzt geändert von Anonymus am Mo 13. Jun 2016, 11:56, insgesamt 2-mal geändert.

mschnell
Beiträge: 3444
Registriert: Mo 11. Sep 2006, 10:24
OS, Lazarus, FPC: svn (Window32, Linux x64, Linux ARM (QNAP) (cross+nativ)
CPU-Target: X32 / X64 / ARMv5
Wohnort: Krefeld

Re: Interfaces - Wofür ist die NoGui Schnittstelle von Lazar

Beitrag von mschnell »

Anonymus hat geschrieben: Könnte man da nicht auch die LCL auf MseGui aufsetzen? Obwohl dann noch eine Message Queue, die der MSE Gui dazu käme.

Ich habe versucht, Teile der mse-RTL in einer LCL - Erweiterung einzusetzen. Das ist mit nicht gelungen, obwohl Martin mir aktiv geholfen hat. Die Strukturen sind einfach zu unterschiedlich.

Mehrere Message Queues gleichzeitig sind das Haupt-Problem (und meiner Ansicht nach ein historisch bedingter Design-Fehler vom Lazarus). Das würde ich auf jeden Fall vermeiden. Und deshalb habe ich die Fertigstellung der seit Jahren ziemlich fertigen NoGUI-Erweiterung zurückgestellt bis die offizielle FPC - Distribution (auf meinen Wunsch von vor noch mehr Jahren) nun ab Version 3.0 das Delphi 7 kompatible "TThread.Queue()" hat und man dadurch die Queue in der RTL auch füttern kann.

Man braucht in einem Multi-Threading Programm definitiv für den Main-Thread nur eine Event-Queue. Alle Threads und die Widget-Set API können die füttern. Mehrere Queues für einen Ziel-Thread zu synchronisieren ist fürchterliches Gebastel. Lazarus macht das, weil die eine Queue in der fpc-RTL realisiert ist (wo die Lazarus - Entwickler keinen direkten Einfluss drauf haben)und früher keinen Eingang zum Füttern hatte (außer TThread.Synchronize, was ja zusätzlich wartet), und weil Lazarus zunächst unter Windows entwickelt wurde und die andere Queue da (wie bei Delphi die einzige Queue) von Windows selbst ("Message-Queue") zur Verfügung gestellt wird, was in Linux aber so nicht geht und deshalb in den Widget-Types für Linux und OSX dann doch Queues in Pascal-Code implementiert werden mussten.

Weitere Queues für zusätzliche Threads wären schön (mse kann das, soweit ich weiß). Delphi kann das aber nicht und Lazarus auch nicht. Damit könnte man dann die "Worker" Threads mit demselben "Event-orientierten" Paradigma programmieren wie den MainThread (wenn man das will).

-Michael
Zuletzt geändert von mschnell am Sa 18. Jun 2016, 14:04, insgesamt 6-mal geändert.

mschnell
Beiträge: 3444
Registriert: Mo 11. Sep 2006, 10:24
OS, Lazarus, FPC: svn (Window32, Linux x64, Linux ARM (QNAP) (cross+nativ)
CPU-Target: X32 / X64 / ARMv5
Wohnort: Krefeld

Re: Interfaces - Wofür ist die NoGui Schnittstelle von Lazar

Beitrag von mschnell »

Anonymus hat geschrieben:Statdessen aber setzt die LCL auf andere Widgetsets auf, obwohl die LCL diese schon selber zeichnen könnte.

Das ist auch sinnvoll, da die externen Widget Sets Betriebssystem-spezifisch (und in ein komplexes konfigurierbares Darstellungs-System eingebettet) sind (bei Windows ja sogar in dass Betriebssystem fest integriert und vermutlich nur schwer austauschbar) und deshalb eine deutlich höhere Performance und Funktionalität aufweisen als von der LCL selbst gezeichnete Ansätze (wie "FPGUI" und "Customdrawn"). Die LCL muss aber Betriebssystem-unabhängig einsetzbar sein und darf deshalb nur in Details spezifische Veränderungen zeigen.

Mit der Entwicklung der diversen externen Widget-Sets durch eigene Teams kann das Lazarus Team keinesfalls mithalten.

(Ich habe auf die Dauer vor, zu versuchen FPGui- (oder vermutlich eher CustomDrawn-) Teile zu portieren und in den neue noGUI Widget-Typ als Sub-Typ (neben "ifi" und vielleicht einer rudimentären Javascript-getriebenen Web GUI) zu integrieren. Da ich aber schon 62 bin wird das wohl im Himmel released. :D (Oder man steigt auf mse um :D :D :D )

-Michael

Antworten