NoGUIApplication

[mschnell]

Hallo,
Ich bin dabei ein Package für Lazarus zu bauen, das es erlaubt, mit Event-orientierter Programmierung auch Programme zu erstellen, die keine grafische Oberfläche verwenden.

Dafür ist ein neues Package notwendig, weil von Hause aus Lazarus (und Delphi) keine interne Event-Queue unterstützt, sondern die Event-Queue des Grafik-Systems (Windows. QT, GTK, ...) verwendet.

Das neue Paket ist notwendig, wenn man z.B. Programme für "headless" embedded Systeme machen will, die kein Grafik-System haben, oder wenn man Programme machen will, die auf einem (angemieteten) Webserver laufen, der keine GUI für "vom Web aus" gestartete Programme erlaubt. Außerdem sollte es damit in einem GUI-Programm möglich sein, zusätzlich zum Mainthread auch weitere Threads mit Event-orientierter Programmierung zu designen.

Martin Schreibers "MSEIDE" unterstützt im Gegensatz zu Delphi und Lazarus die "NoGUIApplication" mit interner Event-Queue.

Ich habe also (mit Martins Erlaubnis) angefangen, den entsprechenden Code auf Lazarus zu portieren (nicht ganz trivial, weil MSEGUI und Lazarus doch recht unterschiedlich sind). Eine erste Testversion (proof of concept) lebt inzwischen und verarbeitet Timer-Events ganz brav.

Als Beispiel, wie man ein Lazarus-Package bauen kann, das einen neuen "Application" Typ bei der Erstellung eines Programms auswählbar macht, habe ich ExtP (ein Lazarus Frontend für "ExtPascal", das wiederum ein Pascal Frontend für ExtJS ist).

Ich fange an, ein Lazarus "Paket" aus NoGUIApplication zu schnüren, wenn die Funktionalität zufriedenstellend ist.

Wenn das einmal alles läuft, steht die Erweiterung auf "ifi" an (auch ein open Source Projekt von Martin). Hier wird dann wieder eine grafische Oberfläche möglich, indem alle Zugriffe auf die visuellen Komponenten (bei automatischer Erstellung und bei User-Code Zugriffen) über TCP-IP (oder serielle Schnittstelle) an ein nicht unbedingt Projekt-spezifisches Programm geleitet werden, das die Oberfläche auf einem Windows oder Linux PC darstellt. Als Beispiel wie man mit Hilde eines Lazarus "Pakets" visuelle Komponenten zur Design-Zeit (mit dem dort integrierten Code) erzeugen kann, zur Laufzeit aber ganz anderen Code (für die Remote-Anbindung) verwendet und den Design-Zeit-Code gar nicht einkompiliert dient hier wieder ExtP, das genau dies mit einem FPC-config Trick macht.

Bitte melde sich, wer hier mitmachen will (Testen oder Code erstellen).
Gruß,
-Michael

[theo]

Ich hatte bisher noch nie ein Bedürfnis nach so einer Lösung, vielleicht erkenne ich aber nur das Potenzial nicht.
Kannst du mal einfach und kurz erklären, welches Problem dies (bzw. die Konsolenprogrammierung mit Message Queue) löst?

[mschnell]

Kurze Antwort: Ohne Message-Queue kein TTimer und kein TThread.Synchronize.

Kannst du mal einfach und kurz erklären, welches Problem dies (bzw. die Konsolenprogrammierung mit Message Queue) löst?

In Delphi und Lazarus gibt es grundsätzlich zwei verschiedene Programmtypen, die man erzeugen kann:

1) "Command Line Tool".

Das Programm wird gestartet, tut was es soll und beendet sich. Normalerweise wird das benutzt, wenn es nicht nötig ist, dass das Programm in eine "Idle"-Zustand läuft in dem es auf irgendetwas wartet. Und wenn es das doch tut (z.B. ein TCP/IP Client) wartet es nur auf ein einziges Event und nicht auf mehrere gleichzeitig. Wenn man auch das will, muss man z.B. meherer Threads verwenden. (z.B. einem TCP/IP Server)). Der Main-Thread muss dann irgendwie blockiert werden (Am einfachsten: Loop mit "sleep").

Standard-Dinge wie TTimer die Events erzeugen, kann man nicht verwenden.

2) Eine "Application".

Das Programm läuft nach dem Start in einen Idle-Zustand und wartet dann auf "Events". Z.B. einen Mausclick, Tastendruck etc. Es wartet auf diverse Events gleichzeitig, die verschiedenen Komponenten sind als Event-Handler programmiert und erzeugen ihrerseits Events entweder für andere Komponenten oder für den User-Code (oft "On...." genannt). Komplexe Events werden z.B. von der Grafischen Oberfläche (Widgets, z.B. Windows Controls) erzeugt. (In Windows sind das Messages, in Linux Callbacks des Grafiksystems). Die Events werden von Windows bzw vom Grafiksystem in einer (Message/Event-) Queue verwaltet. Will das Programm selber solche "asynchronen" Events erzeugen, (z.B. TTimer) schickt es sie an das Grafiksystem, das sie in die Queue einreiht.

Durch dieses Event-Queue-Verfahren hat das Programm automatisch ein internes "kooperatives" ("run to completeion") Multi-Threadding, das gegenüber echten ("preemptiven") Threads (TThread) den gewaltigen Vorteil hat, dass man Variablen, die von verschiedenen Events genutzt werden nicht durch Semaphoren (Mutex (=TCriticalSection), z.B: TThreadlist, ...) "Threadsafe" gegen mehrfache Zugriffe absichern muss.

Mit TNoGUIApplication kann man (hoffentlich bald) GUI-lose Programme mit TTimer und TThread.Synchronize etc komfortabel programmieren.

-Michael

[theo]

Das ist mir schon klar. Wie du selber sagst, ist dies aber im Zusammenhang mit

Mausclick, Tastendruck
..
Callbacks des Grafiksystems)

von Bedeutung, und typischerweise nicht in einer Anwendung, die mit dem Graphischen System nix am Hut hat.
Einen TTimer (falls überhaupt benötigt) kann man auch anders implentieren.

Nicht das deine Erklärung falsch wäre, aber den konkreten Nutzen kann ich leider noch immer nicht erkennen.

[mse]

...von Bedeutung, und typischerweise nicht in einer Anwendung, die mit dem Graphischen System nix am Hut hat.
Einen TTimer (falls überhaupt benötigt) kann man auch anders implentieren.

Nicht das deine Erklärung falsch wäre, aber den konkreten Nutzen kann ich leider noch immer nicht erkennen.

Natürlich kann man... Aber es ist halt meistens besser, die optimalen Methoden und Werkzeuge zu erarbeiten, als sich auf Bestehendes nicht optimales zu begrenzen.

[mschnell]

Einen TTimer (falls überhaupt benötigt) kann man auch anders implentieren..

Die Funktion für den Programm-Anwender natürlih. Ohne Event-Queue ist das für den Programmierer aber etwas völlig anderes und in komplexen Programmen viel schwerer handhabbares. Das schöne an Delphi-typischer Programmierung ist ja (neben der Objekt-Orientierung) gerade das Denken in "Eventhandlern".

-Michael

[theo]

Naja ich bleibe skeptisch, was das Bedürfnis dafür betrifft, werde mir das Resultat aber gerne anschauen.
Vielleicht geht mir ja dann ein Licht auf.

[mschnell]

Vielleicht geht mir ja dann ein Licht auf.

spätestens, wenn auch der ifi-Kram läuft Oder auch wenn jemand ein Beispiel mit ExtP vorführen kann (habe ich nicht vor, es könnte aber Interessenten geben).

-Michael

[Targion]

Was genau ist denn der Unterschied zum NoGUI-Widgetset in Lazarus?

[mschnell]

Was genau ist denn der Unterschied zum NoGUI-Widgetset in Lazarus?

2008 habe ich erfolglos versucht das zu testen. In der Forum-Diskussion darüber bin ich auf Martins MSEGUI NoGUIApplication gestoßen, die (mit MSEIDE sofort einwandfrei funktionierte).

Ich schaue mir das NoGUIWidgetSet jetzt noch 'mal daraufhin an, ob jemand daran weitergearbeitet hat, und ich es vielleicht testen kann.

-Michael

[theo]

Wenn ich mir den Code in lazarus/lcl/interfaces/nogui anschaue, sehe ich eigentlich ein reines LCL Widgetset Skelett.
Mehr als die Anforderungen zum Kompilieren scheint das nicht zu erfüllen.

[mschnell]

Vielleicht ist es sinnvoll es mit NoGUIApplication tatsächlich in Funktion zu setzen, anstatt - wie ich es momentan vorhabe - ein Lazarus Paket zu schnüren, das dem Programmierer beim Beginn des Projektes zusätzlich zu "Application", "Program" ... auch "No GUI Application" (fällt jemandem ein schöner Name dafür ein ) anbietet.

-Michael

[theo]

Vielleicht ist es sinnvoll es mit NoGUIApplication tatsächlich in Funktion zu setzen, anstatt

Ich glaube nicht, dass das nicht funktioniert. Es erfüllt aber wahrsch. nicht den Zweck den du annimmst.
Wahrsch. ist es nur da, um die LCL ohne GUI-Library Abhängigkeiten einzubinden. Es hat wahrsch. nicht die Absicht, Widgetset zu spielen.

Ich würde mal die Devels fragen.
Immerhin wird es aktuell irgendwie verwendet. Schau mal ins makefile:

Code: Alles auswählen

lazbuild: lazbuilder
lazbuilder:
   $(MAKE) -C lcl/interfaces/nogui 
   $(MAKE) -C ide lazbuilder LCL_PLATFORM=nogui

[Targion]

NoGUI ist dafür da, die LCL auch in Anwendungen nutzen zu können, die keine Abhängigkeit zum Widgetset haben.
So gibt es z.B. dadurch, dass lazbuild jetzt NoGUI anstelle von GTK2 verwendet kein Problem mehr, wenn man es ohne X11 benutzen möchte.
@mschnell Wenn das der Sinn des NoGUI-Widgetset ist, dann wäre es aber sehr sinnvoll, deinen Code dafür zu verwenden, da man so dann noch mehr LCL funktionen ohne Widgetset-Abhängigkeit nutzen kann. (z.B. Bilder zeichnen geht mit NoGUI nicht) Oder verstehe ich dein Projekt da falsch?

[mschnell]

Oder verstehe ich dein Projekt da falsch?

Bei NoGUIApplication geht es um Events (wie Timer-Events, TThread.Synchronize, ... und alles was davon abgeleitet ist). Die Programmierung vollzieht sich dann Delphi-typisch ausschließlich in der Erstellung einer Anzahl von Event-Handlern. Das Programm beendet sich nur, wenn man eine entsprechende Funktion aufruft. das Verlassen des User-Codes "nach unten" bringt das Programm höchstens in einen Idle State.

Mit LCL-Komponenten hat das wenig zu tun.

Das NoGUI Widget set scheint also etwas ganz anderes im Sinn zu habn.

-Michael