Architektur MSEide+MSEgui

[mse]

Hier etwas Theorie:

MSEide+MSEgui 2008-11-01 mse
 
 
MSEgui ist eine Pascal Programmbibliothek, die Bausteine zur Entwicklung von Computerprogrammen mit graphischer Bedieneroberfläche zur Verfügung stellt.
 
MSEide ist die entsprechende integrierte Entwicklungsumgebung zur rationellen Softwareproduktion mit Free Pascal und MSEgui.
 
MSEide ist auch zur Entwicklung von gcc- und Mikrocontroller-Anwendungen geeignet.
 
Zur Zeit läuft MSEide+MSEgui unter i386-linux und i386-win32, unterstützte uP's sind CPU32, ARM und AVR32.
 
Der grösste Teil von MSEgui ist Plattform unabhängig. Weitere Plattformen können durch Implementierung der systemabhängigen Softwareteile hinzugefügt werden. Die systemabhängigen MSEgui Module befinden sich in Unterverzeichnissen von lib/common/kernel.
 
 
Wichtige Entwicklungsziele:
 
 
- Massgebliche Erhöhung der Produktivität verglichen mit anderen Entwicklungssystemen.
 
- Identisches Aussehen und Funktionalität auf allen Plattformen ohne zusätzliche Massnahmen im Anwender-Code.
 
- Möglichst wenig Abhängigkeit von zusätzlichen Bibliotheken.
 
- Orthogonalität, es sollen möglichst wenige Beeinflussungen zwischen verschiedenen Programmelementen und möglichst wenige Ausnahmen und Spezialfälle bestehen.
 
- Hohe Parametrierbarkeit der GUI-Elemente.
 
- Die Arbeit mit MSEide+MSEgui soll Spass bereiten.
 
 
Architektur:
 
 
MSEgui benötigt keine externen Komponenten-Bibliotheken, es kommuniziert direkt mit der graphischen Schnittstelle des Betriebssystems, X11 via Xlib auf Linux und gdi32 unter Windows.
 
Für die einzelnen GUI-Elemente werden keine Betriebssystem-Ressourcen angefordert, lediglich die Hauptfenster sind dem Betriebssystem bekannt. Die gesamte Verarbeitung der externen Ereignisse (Tastatur, Maus, Fokussteuerung...) geschieht innerhalb MSEgui auf Pascal Ebene.
 
 
Die Basisklasse für GUI-Elemente ist twidget. Es gibt keine Unterscheidung zwischen einfachen graphischen Elementen und Elementen die den Eingabefokus erhalten können wie in Delphi. Alle MSEgui widgets haben die volle twidget Funktionalität zur Verfügung.
 
Wichtige Eigenschaften von twidget sind twidget.frame und twidget.face. Werden frame oder face nicht verwendet, werden sie durch NIL-Pointer dargestellt, welche kaum Ressourcen benötigen.
 
twidget.frame ist für den Rahmen rund um die Arbeitsfläche des Elementes zuständig.
 
Das Aussehen des Rahmens ist in weiten Grenzen einstellbar. Es können dies einfache und schnell zu zeichnende 3D-Rahmen oder komplexe und daher langsamere aus Bildern zusammengesetzte Konstrukte sein. Weitere Rahmenelemente können Rollbalken, Schaltflächen und Beschriftungen bilden.
 
twidget.face zeichnet den Hintergrund der Arbeitsfläche des GUI-Elementes. twidget.face kann Farbverläufe und Bilder in verschiedenen Formen darstellen, dabei ist auch Teiltransparenz möglich.
 
Zur zentralisierten Einstellung der frame und face Eigenschaften dienen tframecomp und tfacecomp, welche in tframe und tface als template gewählt werden können.
 
Die nächste Stufe der Zentralisierung ist tskincontroller, worin programmweite Einstellungen vorgenommen werden können. tskinkontroller weist dazu den GUI-Elementen entsprechende tframcomp und tfacecomp templates zu.
 
Die Steuerung der widget Funktionen (focusin, focusout...) geschieht durch virtual Prozeduren und Funktionen und nicht durch messages. Die MSEgui Message-Funktion hat andere Aufgaben. Ebenfalls eingesetzt werden Corba-Style-Interface, zur sicheren Verbindung zwischen verschiedenen Komponenten mit automatischer Verbindungstrennung durch destroy wird tobjectlinker benutzt.
 
Zur Textspeicherung wird in MSEgui der Typ msestring verwendet. Im Moment ist msestring=widestring. Es ist geplant, den auch unter Windows Referenz-gezählten FPC widestring (UnicodeString) zu verwenden, sobald er in einem FPC Release erhältlich ist.
 
In Textdateien werden utf-8, ASCII oder die lokale Codierung verwendet, MSEide+MSEgui verwendet keine utf-16 Dateien.
 
Die MSEgui Datenbank-Komponenten wandeln von der lokalen Codierung oder von utf-8 (einstellbar) für die Datenpufferung zu widestring. Für Dateioperationen steht ein Satz von MSEgui-eigenen Funktionen mit widestring Schnittstelle zur Verfügung. Die MSEgui Anwendung kann also durchgängig mit widestring arbeiten, was für manche Aufgaben eine erhebliche Erleichterung bedeutet.
 
Für die grundlegenden Datentypen (integer, real, tdatetime...) stehen in MSEgui spezialisierte Datenfelder zur Verfügung (tintegeredit, trealedit, tdatetimeedit...). Wichtigste event Eigenschaft dieser widgets ist onsetvalue, worin auf Anwendereingaben reagiert werden kann.
 
Die t*edit widget können in ein twidgetgrid eingefügt werden und bilden dabei eine Spalte des entsprechenden Datenformates.
 
Für die Anzeige und Editierung von Datenfeldern dienen entsprechend tdbwidgetgrid und ein Satz von tdb*editwidget. Erwähnenswert auch die verschieden lookup-Komponenten und tlookupbuffer, ein schneller assoziativer Datespeicher.
 
Die Grundkomponente der MSEgui Datenbankumgebung ist tmsebufdataset, von welchem tmsesqlquery abgeleitet ist. MSEgui DB ist ein fork des FPC SQLDB Systems, wobei TBufDataset und weite Teile von TSQLQuery und den connection Komponenten komplett neu geschrieben wurden.
 
tmsebufdataset bietet lokale Indizes, calculated- und internalcalc-fields, einen Modus mit unterbrochener Datenbankverbindung, einen in memory-Modus wobei keine Datenbankanbindung notwendig ist und kann ein lokales Journal führen, um eine unterbrochene Datenbankverbindung später wieder aufzunehmen. tmsebufdataset speichert Texte als widestring variabler Länge.
 
Weiter gibt es SQL Script-Komponenten und tsqlresult für schnelle Abfragen ohne den TDataset overhead. Persistente TField Instanzen werden entweder innerhalb tmsesqlquery gehalten, wo sie im Objekt-Ispektor über tmsesqlquery.controller.fields editiert werden können, oder als Einzelkomponenten der 'DBf' Palette in das Formular oder Modul eingfügt.
 
MSEide unterstüzt 'visual form inheritance', Submodule (Delphi TFrame Äquivalent) und erlaubt die Zuweisung von Komponenten anderer Formulare und Module an Komponenteneigenschaften zur Entwurfszeit.
 
Internationalisierung geschieht mittels zur Laufzeit ladbaren Ressourcen-Modulen. Zur Editierung steht MSEi18n zur Verfügung, ein Werkzeug, welches den Import und Export der Texte in Tabellenkalkulationsprogramme zur Übersetzung durch nicht Programmierer erlaubt.


Martin

[mschnell]

Wie sieht es mit der Multi-Thread Unterstützung aus ? (z.B. OS-Unabhängiger Message-Austausch, blocking, etc. )

-Michael

[mse]

Wie sieht es mit der Multi-Thread Unterstützung aus ? (z.B. OS-Unabhängiger Message-Austausch, blocking, etc. )

Vorhanden, darüber haben wir glaube ich schon mehrmals diskutiert. Vielleicht errinnerst du dich auch an MSEifi.

[mschnell]

Klar erinnere ich mich .

Aber wenn Du hier über die Feature von MSEGUI schreibst, sollte das nicht fehlen. Für alle: sowieso - ich dachte Du freust Dich, wenn ich Dir einen Ball zuwerfe - und für mich ist eine Zusammenfassung zur Auffrischung praktisch und Neuigkeiten interessant .

Als weitere erwähnenswerte Punkte fallen mir spontan ein (haben wir sicherlich alles früher schon 'mal angesprochen ) :
- Unterstützung von seriellen Schnittstellen
- Unterstützung von TCP/IP
- CGI-Projekte

-Michael

[mse]

ich dachte Du freust Dich, wenn ich Dir einen Ball zuwerfe - und für mich ist eine Zusammenfassung zur Auffrischung praktisch und Neuigkeiten interessant .

Aha!
Der Beitrag war weniger als Auflistung von Features und mehr als Hilfe zum Verständnis der Zusammenhänge gedacht.
Ich nehme den Ball gerne auf:

MSEgui hat zwei verschiedene application Klasssen. tguiapplication wird eingesetzt, wenn visuelle Komponenten im Spiel sind. tguiapplication benützt die event queue von X11 auf Linux und die Windows message queue. In Fällen, wo kein Graphiksystem benötigt wird (beispielswiese Serverapplikationen) wird tnoguiapplication verwendet. tnoguiapplication benützt eine interne event queue und hat keine Abhängigkeiten zu X11. Dadurch können nicht visuelle MSEgui Komponenten (tthread, taction, ttimer, tstatfile..., DB-Komponenten...) auch auf Systemen ohne Graphikunterstützung eingesetzt werden.
MSEgui hat weitgehende Unterstützung für multi threading Anwendungen wie locks und queues. Beispielsweise benützt auch MSEide mehrere threads, während des Kompilierens kann weitergearbeitet werden.
Für GUI Anwendungen wird "msegui" in "uses" aufgeführt, für GUI-freie Anwendungen "msenogui".

MSEifi ist ein System zur Übertragung von MSEgui Formularen und events über Kommunikationskanäle. Ein Server sendet dabei *.mfm Dateien (die Delphi *.dfm Entsprechung in MSEgui) an einen "MSEgui-Browser". Der MSEifi-Browser baut die forms aufgrund der übertragenen *.mfm Dateien auf und schickt Benutzereingaben zurück an den Server, welcher wiederum den Status und den Dateninhalt der forms im MSEifi-Browser beeinflussen kann. Es ist auch denkbar, den MSEifi-Browser als Internet-Browser-Plugin auszuführen.
MSEifi hat auch eine Schnittstelle zu RemObjects Pascal Script. Solange lediglich scriptbare eventhandler programmiert werden, ist es möglich, MSEifi Programme wahlweise als normale lokale kompilierte Anwendung oder als ferngesteuerte MSEifi Applikation zu realisieren. Zum Einbau der MSEifi Unterstützung muss MSEide mit -dmse_with_ifi kompiliert werden.
MSEifi ist in experimentellem Stadium, beispielsweise sind erst sehr wenige Pascal Script Bindungen vorhanden und die Fehlerbehandlung ist noch ungenügend.
Da ich MSEifi nicht dringen benötige und das Interesse der Anwender gering ist, liegt die Entwicklung im Moment auf Eis.
Eine Beispielapplikation mit Linux und Windows binaries gibt es hier:
http://msedocumenting.svn.sourceforge.n ... edemo/bin/

Martin

[mschnell]

MSEifi ist ein System zur Übertragung von MSEgui Formularen und events über Kommunikationskanäle. Ein Server sendet dabei *.mfm Dateien (die Delphi *.dfm Entsprechung in MSEgui) an einen "MSEgui-Browser". Der MSEifi-Browser baut die forms aufgrund der übertragenen *.mfm Dateien auf und schickt Benutzereingaben zurück an den Server, welcher wiederum den Status und den Dateninhalt der forms im MSEifi-Browser beeinflussen kann.

Ist MESifi inzwischen im "fully released" Status ? (Script würde ich nicht brauchen.)

Ist es denkbar, MSEifi so umzuschreiben, dass es Lazarus *.lfm beackern kann ? (Ich will Delphi-Applikationen portieren, die kann ich mit vertretbarem Aufwand auf Lazarus portieren, vermutlich kann ich die Forms aber nicht auf MSEGUI portieren. )

Dann wäre das Interesse der Anwender groß !!! (zumindest >=1 )

-Michael

[mse]

Ist MESifi inzwischen im "fully released" Status ? (Script würde ich nicht brauchen.)

Nein, immer noch experimentell. Neu sind in SVN Trunk einfachere Linkkomponenten ohne Serialisierung zur Verbindung von GUI und business-Objekten hinzugekommen, diese werde ich vermutlich produktionsreif machen.

Ist es denkbar MSEifi so umzuschreiben, dass es Lazarus *.lfm beackern kann ?

Nur mit sehr grossem Aufwand, da Lazarus die benötigte Infrastruktur nicht hat, beziehungsweise anders aufgebaut ist.

[mschnell]

Nur mit sehr grossem Aufwand, da Lazarus die benötigte Infrastruktur nicht hat, beziehungsweise anders aufgebaut ist.

Ich glaube, ich begebe mich mal daran, etwas ähnliches für Lazarus zu planen. Ich würde mir die generelle Methodik von MSEifi anschauen (das läuft ja vermutlich darauf hinaus, dem Client-Programm alle relevanten visuellen Komponenten einzubauen und auf der Server-Seite diese Komponenten durch "Kommunikations-Adapter"-Komponenten zu ersetzen. ) Ich würde natürlich (zunächst) kein allgemein verwendbares Tool erstellen, sondern die von uns benötigten Komponenten eine nach der anderen hinzufügen.

Aber Voraussetzung dafür ist natürlich erstmal eine TNoGUIApplication

-Michael

[mse]

Ich glaube, ich begebe mich mal daran, etwas ähnliches für Lazarus zu planen.

Wenn ich dich recht verstehe, erlaubt dein Kunde keine Installation irgendwelcher zusätzlicher Software, so dass alles im Webbrowser laufen muss. Also kommt nur Javascript in Frage. Viel Spass!

[mschnell]

Wenn ich dich recht verstehe, erlaubt dein Kunde keine Installation irgendwelcher zusätzlicher Software, so dass alles im Webbrowser laufen muss. Also kommt nur Javascript in Frage. Viel Spass!

Das ist ein anderes Projekt . Das haben wir momentan mit Delphi gelöst. Die komplexesten Client-Seitigen Sachen laufen als Action-Script-Programm (änlich wie Java) in einem von der HTML-Page aufgerufenen Flash-Fenster. Ich recherchiere hier nur für eine potentielle zukünftige Umstellung, damit der Server auf Linux laufen kann und die Client-Software nicht in einer so geschlossenen Umgebung wie Flash laufen muss. Silverlight wäre ein sehr moderner Ansatz, dann müsste man aber von Delphi auf Delphi-Prism statt auf FPC umsteigen....

Das Projekt was ich hier im Kopf habe ist anderer Natur. Da darf auf dem Client alles laufen, der Server darf aber keine grafische Oberfläche (VLC, LCL, MCL) mehr erfordern. Auch in diesem Fall ist die momentan verwendete Software in Delphi, der zukünftige Rechner aber Linux, kein x86 und eben ohne Grafik.

Spaß satt
-Michael

[mse]

Das Projekt was ich hier im Kopf habe ist anderer Natur. Da darf auf dem Client alles laufen, der Server darf aber keine grafische Oberfläche (VLC, LCL, MCL) mehr erfordern.

Ja, dafür ist MSEifi geeignet.

[pluto]

Dafür währe sogar Lazarus geeignet *G*

[mschnell]

Dafür währe sogar Lazarus geeignet *G*

Das ist doch genau das, was ich gerade vorhabe auszuprobieren: eine MSEifi-ähnliche Methodik mit Lazarus zu realisieren.

Dafür ist aber eine TNoGuiApplication notwendig, deshalb bietet Lazarus momentan eben noch nicht den nötwendigen Funktionsumfang (im Gegensatz zu MSEGUI, wo es das gibt.)

Deshalb muss ich zwei Sachen tun, bevor ein erster ernsthafter Test laufen kann: (1) TNoGuiApplication für Lazarus portieren und (2) Implementierung von einem eingeschränkten TForm in einer MSEifi-ähnlichen weise (Server und Client)

-Michael

[mschnell]

Ja, dafür ist MSEifi geeignet.

Übrigens: wofür steht eigentlich die Abkürzung "ifi". Wenn ich da schon was drauf aufbaue, will ich es doch auch kompatibel benennen

-Michael

[mse]

Übrigens: wofür steht eigentlich die Abkürzung "ifi".

Das hat keine Bedeutung mehr, da die ursprüngliche Funktion ausgeweitet wurde. Es sieht einfach lustig aus.