MSEgui auf neue Plattform portieren?

[mschnell]

Zu deiner frage, wer ist "man", nun zumindest mal die Leute hier in dem Forum.

Du hast natürlich recht. "Embedded" Anwendungen sind sowohl hier im Forum als auch ansonsten in der Lazarus- und MSE- Gemeinde wenig vertreten. (Ist aber "mein" Thema.)
Dabei kann man gerade mit MSE eigentlich sehr schön embedded Anwendungen für headless Systeme erstellen, weil sich die GUI (anders als bei Lazarus) remoten lässt. Bereits verfügbar ist das Remoting Tool "ifi" (da habe ich mit Martin Schreiber vor längerer Zeit ausführlich drüber diskutiert). Andere Arten, eine Remote-GUI Library zu erstellen - vielleicht auch eine Android-Java Anbindung ?? - sind mit der MSEGUI library recht gut möglich, da die "Eventloop" bei MSI komplett mit Library-eigenem Code realisiert ist und nicht auf Queuing-Mechanismen des verwendeten Widget-Sets zurückgreift. Bei Lazarus muss die komplette "WidgetType" Library, die die EventQueue enthält, passend zum angebundenen Widgetset neu erstellen. Deshalb gibt es ohne Anbindung an ein WigetSet keine Eventqueue. Bei MSE wird die Widgetset-Anbindung auf der Event-Queue der Library implementiert.
-Michael

[mschnell]

GNU/Linux bezeichnet Linux distributionen die GNU software verwenden ... Dazu gehören so sachen wie die Shell (z.B. Bash), die Core utils (z.b. cat, tail, uname, usermod, su, echo, etc.), der XServer, etc.

X ist nicht Bestandteil von GNU, sondern ein System von Treibern und Programmen, die auf GNU/Linux (aber auch auf anderen Systemen) laufen, aus einer andern ursprünglichen (Unix-) Ecke kommen und auch nicht von GNU-Team (Stallman), sondern vom "X-Konsortium" in eine freie Form überführt wurden. Siehe -> https://de.wikipedia.org/wiki/X_Window_System.
(Linux wurde ja ursprünglich als freie Variante des Unix-Kernel (für x86) entwickelt und verwendete die freien GNU Tools als zum sinnvollen Betrieb notwendige Programme. Ohne X.)

-Michael

[Warf]

X ist nicht Bestandteil von GNU, sondern ein System von Treibern und Programmen, die auf GNU/Linux (aber auch auf anderen Systemen) laufen, aus einer andern ursprünglichen (Unix-) Ecke kommen und auch nicht von GNU-Team (Stallman), sondern vom "X-Konsortium" in eine freie Form überführt wurden. Siehe -> https://de.wikipedia.org/wiki/X_Window_System.
(Linux wurde ja ursprünglich als freie Variante des Unix-Kernel (für x86) entwickelt und verwendete die freien GNU Tools als zum sinnvollen Betrieb notwendige Programme. Ohne X.)

-Michael

Oh, mein Fehler, dachte die X-Server implementierung (nicht das konzept von X-Window selbst, also das konzept, sondern lediglich die gängige implementierung auf linux systemen) wäre eine GNU software.

[marcov]

Mag ja sein, aber Systemunabhängigkeit, Plattformübergreifend programmiert, wird da viel zu oft mantraartig behauptet. Und Systemunabhängigkeit heißt da für mich eben nicht nur, dass die jeweilige Bibliothek für mehrere Plattformen verfügbar ist, sondern auch, dass diese Bibliothek mit vertretbarem Aufwand auf eine andere noch nicht unterstützte Plattform portierbar ist, weil systemabhängige Teile dann eben nur sehr sparsam verwendet werden, das unbedingt notwendige halt.

Und das ist hier doch auch den Fall? Nur Android hat keinen normalen nativer API aber nur ein Java Applikation Model mit etwas Fähigkeiten um nativer Bibliotheken zu verwenden und ist daneben auch schrecklich Versioniert.

Siehe zb LAMW.

Und da ist hier die gdiplus.dll unpassend, weil die schon wieder zu viele Systemabhängigkeiten einbringt. Nutzt die gdiplus.dll Teile von Windows oder ist ihr Code samt und sonders innerhalb der DLL, ohne dass die da noch von externen Windows Ressourcen abhängt? Es gibt ja Bibliotheken, die keinerlei Abhängigkeiten nach außen haben. Sobald aber die gdiplus.dll zum Beispiel Windows API Funktionen nutzt, besitzt sie solche Abhängigkeiten. Wie aber ist es dann möglich, dass diese DLL als gdiplus.so unter Linux funktionieren kann?

Ich glaube einige Dingen wie antialiased Text wäre nur möglich mit gdiplus auf Windows. Auf einige Platformen macht MSEGUI vielleicht noch etwas Extras über die Portablen Subsatz hinaus um mehr Native aus zu sehen.

Wie die andere schon sagten, denke ich nicht das das MSEGUI das nutzt under Linux.

[mschnell]

"Normale" Android Programme laufen als Dalvik Code auf der virtuellen Maschine und sind deshalb CPU-Plattform-unabhängig (Es gibt Android nicht nur auf ARM, sondern auch u.a. auf x86).
Natürlich kann man (z.B. mit fpc generierte) native Programm laufen lassen. Allerdings nicht einfach mit den in der Android GUI normalerweise verwendeten Start-Mechanismen starten. Die GUI darzustellen ist dann noch eine ganz andere Herausforderung.
Es geht aber auch anders, weil fpc ja auch Java Byte Code generieren kann, der dann wieder in Dalvik übersetzt werden kann. -> https://wiki.freepascal.org/FPC_JVM
-Michael

[marcov]

"Normale" Android Programme laufen als Dalvik Code auf der virtuellen Maschine und sind deshalb CPU-Plattform-unabhängig (Es gibt Android nicht nur auf ARM, sondern auch u.a. auf x86).

Ich glaube seit Android5 es mehr und mehr wieder nach native geht. Aber ich habe keine Ahnung ob es neue binary Typen gibt die ganz Native sind. Und ich weiss auch nicht was ein Typisch App heutzutage macht.

Was du sagst ist die alte Theory, aber ich weiß nicht was das wert ist nach 10 Versionen Android.

[mschnell]

Ich glaube seit Android5 es mehr und mehr wieder nach native geht.

-> https://www.incloud.de/blog/2017-05-wis ... ybride-app
Dann müsste es ja auch eine GUI - Anbindung ohne Java geben, die mit der Java-App-GUI API zusammenarbeiten kann.
-Michael

[marcov]

Ich glaube seit Android5 es mehr und mehr wieder nach native geht.

-> https://www.incloud.de/blog/2017-05-wis ... ybride-app
Dann müsste es ja auch eine GUI - Anbindung ohne Java geben, die mit der Java-App-GUI API zusammenarbeiten kann.
-Michael

Das ist html5 vs android apps. Nicht android java apps vs native machinecode apps.

[mschnell]

Das heißt auch native Apps können die HTML5 - API verwenden, ohne dazu Umwege über Java zu gehen ? Und für den Benutzer ist dann nicht mehr erkennbar, ob es eine native oder eine Java App ist ?
Leider hat Lazarus ja keinen Supptort für HTML GUI.
-Michael

[theo]

Das heißt auch native Apps können die HTML5 - API verwenden, ohne dazu Umwege über Java zu gehen ? Und für den Benutzer ist dann nicht mehr erkennbar, ob es eine native oder eine Java App ist ?
Leider hat Lazarus ja keinen Supptort für HTML GUI.

Soweit mir bekannt ist, ist das letztlich immer ein Webbrowser, der die Arbeit macht und irgendwie "nativ" gekapselt wird. U.u. mit einem HTTP Server im Hintergrund.
S.a. https://electronjs.org/

[mschnell]

Soweit mir bekannt ist, ist das letztlich immer ein Webbrowser, der die Arbeit macht und irgendwie "nativ" gekapselt wird. U.u. mit einem HTTP Server im Hintergrund.

So habe ich das auch verstanden. Aber wie kommuniziert die APP mit diesem Webbrowser ?
Will man eine "Rich Internet Application" machen (die auf einem Webserver läuft und einen Webbrowser über Internet als "GUI" verwendet) braucht man sowohl http als auch WebSockets zur bidirektionalen Kommunikation. Das wäre ziemlich daneben um einer App eine Lokae GUI zu geben. Deshalb vermute ich, dass da eine spezielle API für geschaffen worden ist, vermutlich JAVA basierend.
Deshalb die Frage, ob man diese API auch mit FPC nutzen kann.
-Michael

[mschnell]

Nur Android hat keinen normalen nativer API aber nur ein Java Applikation Model mit etwas Fähigkeiten um nativer Bibliotheken zu verwenden und ist daneben auch schrecklich Versioniert.

Anscheined gibt es aber solche nativen APPs mit nicht-Browser-artiger GUI. Ich kann mir nicht vorstellen dass diese APP mit standard JAVA / HTML-GUI Methodik gebaut ist. Funktioniert und aieht eher aus wie ein entsprechendes Desktop-Programm . -> http://www.extreamsd.com/index.php/prod ... or-android Bezüglich Audio sagen sie "... completely bypasses the Android audio system, the limits of Android are no longer applicable... " Ich vermute für die GUI gilt ähnliches.

-Michael