Gleiches Widgetset für Linux (ARM) und Windows?

[Timm Thaler]

Ich hätte gern für einige Programme ein Widgetset, welches unter Windows und Linux gleich aussieht und gleich funktioniert. Immer wenn ich ein Programm von Windows auf Linux portiere, passen trotz AutoSize und Anker die Widgets nicht in die Dialogfenster, die Schrift wird abgeschnitten...

Unter Windows (7) habe ich win32, das funktioniert und ist die Win-Api.

Bei gtk2 fehlt die libgdk-win32-2.0-0.dll. Könnte ich installieren, aber ich weiss nicht ob es sinnvoll ist, mit GTK2 auf Windows noch anzufangen.
Bei gtk3 meckert der Compiler, dass "Identifier not found TGtk3WSCustomImageList" in Gtk3WSImgList.
Bei fpgui meckert der Compiler, dass er fpg_main, verwendet von fpguicrosshelpers nicht finden kann.
Für Qt5 ist die Qt5Pas1.dll nicht vorhanden. Qt würde ich auch wegen dem Lizenzkram eher nicht verwenden wollen.

Unter Linux (ARM) kann ich nur gtk2 kompilieren, da sind die Widgets grundsätzlich größer und uneinheitlicher. Das Aussehen ist mir fast egal, aber wenn ComboBoxen unten aus dem Dialogfenster rutschen und nicht erreichbar sind isses doof.

Mir geht es nicht darum, wie ich die Fehlermeldungen wegbekomme. Das schaue ich mir dann konkret an.

Ich möchte erstmal wissen, ob es ein gemeinsames Widgetset gibt, welches ich unter Windows und Linux nutzen kann und welches einheitlich aussieht.

Idealerweise braucht es keine DLL, sondern wird im Programm eingebunden, so es nicht standardmäßig auf dem Rechner vorhanden ist wie die Win-Api. Meine kleinen technischen Programme sollten möglichst nur aus dem ausführbaren Programm bestehen und nicht irgendwelche DLLs oder Libs mit rumschleppen müssen.

[af0815]

Ich verwende für Windows und RasPian die jeweiligen defaults Widgetsets. Die Unterschiede fange ich mit einer unit ab, wo zB. Versciedene Schriftgrössen ja nach System mit mit Defines hinterlegt sind. Bei manchen Sachen ist auch Linux nicht gleich Linux.

Das hat sich bisher als Optimal herauskristallisiert. Entwickelt wird auf win32 dann auf den RasPi oder Linux portiert.

Noch dazu arbeite ich sehr Framesbetont und halte die Frames auch so, das ich sie einzeln testen kann. Durch diesen Aufbau fange ich die meisten 'Erscheinungen' der Unterschiede ab bzw. vermeide sie. Bsp: Ein Button unter Linux Gtk2 lässt sich in der Farbe ändern unter Win nicht. also lege ich mir ein einfärbbares Element um den Button und färbe den Button nicht ein, sondern nur den 'Rand'. Das Verhalten ist dann wieder überall gleich.

fpgui: hat nicht den gleichen Umfang wie die nativen Widgetsets. Sehr kleine Entwicklergemeinde. Allerdings alles nativ gezeichnet. keine Abhängigkeit zu einem WIdgetset.
GTK3: Ist IMHO alpha derzeit. Könnte aber ev. was werden wenn die ersten Distries GTK2 EOL setzen.
QTx: Keine Erfahrung unter Lazarus
MSE-GUI: Zeichnet auch nativ, Aussehen überall gleich. Durch den Tod von Martin unsicher wie es weitergeht.

[mschnell]

Das "gleiche Aussehen" ist bei Lazarus eigentlich viel besser umgesetzt als bei den meisten anderen Programmier-Umgebungen. Die meisten Anwender wollen auch eher "jeweils ideales" als "gleiches" Aussehen.

Es gibt in Lazarus die Widget Types "FPGui" und "CustomDrawn", die die Widgets mit eigenem Code malen, statt auf das vom Betríebssystem zur Verfügung gestellte Widget Set zurückzugreifen. Damit sieht es natürlich überall gleich aus.

Wie vollständig diese (heute) sind und in wie weit sie (heute) tatsächlich funktionieren, weiß ich nicht. Vor ein paar Jahren gab's damit ziemliche Probleme.

-Michael

[Timm Thaler]

Das "gleiche Aussehen" ist bei Lazarus eigentlich viel besser umgesetzt als bei den meisten anderen Programmier-Umgebungen.

Das stimmt schon, bzw. haben andere Programmiersprachen / IDE die Win/Linux Portabilität bieten wie Purebasic oder Qt-Creator das Problem genauso.

Für Linux funktioniert aktuell anscheinend nur GTK2 ohne größere Probleme. Allerdings haben hier editierbare ComboBoxen eine andere Größe als readonly, so dass mir das selbst mit Autosize der Widgets und automatischer Anordnung per Verankerung um die Ohren fliegt:

Wie könnte man das lösen? Der Dialog ist komplett im Formeditor zusammengeklickt.

Und es scheint immer noch das Leck zu geben: Wenn man regelmäßig veränderliche Werte in die Statuszeile schreibt, in meinem Fall eine mitlaufende Zeit und ein empfangener Datenstring, steigt innerhalb weniger Stunden der Speicherbedarf des Programm enorm an.

[Timm Thaler]

Wie ist denn der Stand zu fpGUI? Einerseits scheint das ja recht universell zu sein und auch auf dem Raspberry zu laufen, oder? Andererseits ist bei http://fpgui.sourceforge.net/ die letzte Version fpGUI v1.4.1 released
2015-09-02, das sieht nicht aus als würde da noch was passieren.

Ich möchte halt ungern auf ein totes Pferd setzen und dann in ein paar Wochen feststellen, dass das eine Fehlentscheidung war?

MSE-GUI: Zeichnet auch nativ, Aussehen überall gleich. Durch den Tod von Martin unsicher wie es weitergeht.

Abgesehen von der Unsicherheit: Kann man denn die Widgets aus MSE-GUI einfach mit Lazarus nutzen, oder muss man dazu zwingend die MSE-IDE verwenden?

[mschnell]

Kann man denn die Widgets aus MSE-GUI einfach mit Lazarus nutzen, oder muss man dazu zwingend die MSE-IDE verwenden?

MSE-GUI und Lazarus passen überhaupt nicht zusammen
-Michael

[relocate]

Wie ist denn der Stand zu fpGUI? Einerseits scheint das ja recht universell zu sein und auch auf dem Raspberry zu laufen, oder? Andererseits ist bei http://fpgui.sourceforge.net/ die letzte Version fpGUI v1.4.1 released
2015-09-02, das sieht nicht aus als würde da noch was passieren.

Ich möchte halt ungern auf ein totes Pferd setzen und dann in ein paar Wochen feststellen, dass das eine Fehlentscheidung war?

FPGui ist jetzt auf GitHub : https://github.com/graemeg/fpGUI

[mschnell]

Wie ist denn der Stand zu fpGUI?

Es gibt im Prinzip zwei "FPGui"s: Das "allgemeine", von Lazarus unabhängige, mit einem Form Designer, den ich nicht kenne, und den Lazarus "FPGui Widget Type", der erlaubt, mit dem Lazarus GUI Designer zu arbeiten (und vermutlich bei der Ausführung des Projektes die Library der "allgemeinen" Variante verwendet).

-Michael

[kupferstecher]

Das "gleiche Aussehen" ist bei Lazarus eigentlich viel besser umgesetzt als bei den meisten anderen Programmier-Umgebungen. Die meisten Anwender wollen auch eher "jeweils ideales" als "gleiches" Aussehen.

Interessantes Thema! Native Widgets sind m.E.n. oft nicht so gut geeignet eine schöne GUI zu basteln. Bspw. passen TLabel nie zu TEdit von der Höhe her, was die Positionierung (unnötig?) verkompliziert. Auch für ansprechende Menüleisten braucht man im Grunde eigene Komponenten (Buttons, Hintergründe, Tabelemente, Statusbereiche). Tabs sehen oft nicht gut aus und unterscheiden sich unter versch. Betriebssystemen zu stark. Mit einer Progressbar unter Windows bin ich auch schon schwer auf die Schnauze gefallen, weil diese für die Animation wiederholt Idle-Time der Anwendung braucht. Hab mir dann eine Progressbar selbst gebaut, auch weil die unter Raspbian einfach zu hässlich war.
Aber: Schaltflächen in Dialogen sollten immer die nativen Buttons sein. Auch Dateidialoge immer nativ. Bei Checkboxen, Scrollleisten und Pulldown-Menüs bevorzuge ich auch die Nativen, da sie das Erscheinungsbild schon sehr stark prägen. Bei Edits und Textfeldern ist es eigentlich egal.
Für mich ist also eine Mischung aus nativen und freigezeichneten Komponenten die beste Lösung, auch wenn es einen gewissen Kompromiss darstellt.

Das schöne an Lazarus ist ja, dass diese Mischung möglich ist und man einen sehr guten Support für die nativen Elemente hat.

[Timm Thaler]

Das schöne an Lazarus ist ja, dass diese Mischung möglich ist und man einen sehr guten Support für die nativen Elemente hat.

Ich hab mir mal die fpgui Libs installiert und die Beispiele ausprobiert. Da gibt es schon in den einfachen Beispielen so viele Anzeigenfehler, das macht keinen Spass. Dialoge sind nur englischsprachig.

Nene, ich werd wohl auch die Standardsets für WinApi und GTK nehmen, damit gibts noch die wenigsten Probleme. Hab noch ein bißchen an den Ankern rumgeschoben und viel Platz eingeräumt, und mit den unterschiedlichen Widgetgrößen unter Linux muss ich halt leben.

Zu GTK3: Das ist ja nun schon einige Jahre abgehangen, die endgültig letzte LTS scheint raus zu sein und GTK4 ist im Anmarsch. Und trotzdem wird es von Lazarus nicht wirklich ernstgenommen. Warum?

[af0815]

Zu GTK3: Das ist ja nun schon einige Jahre abgehangen, die endgültig letzte LTS scheint raus zu sein und GTK4 ist im Anmarsch. Und trotzdem wird es von Lazarus nicht wirklich ernstgenommen. Warum?

Zu lange nicht stabile API. Wer kümmert sich darum - das passiert meist in der Freizeit - und GTK2 läuft mal gut und ist auch nicht abgekündigt.

[Timm Thaler]

Ich glaub ich muss mir auch mal die GTK Lib auf den Windowsrechner holen. Ich hab da ein paar Probleme auf dem Raspi, die anscheinend an GTK liegen und das debuggt sich bescheiden mit Crosscompiler.

[af0815]

Ich habe einen RasPi mit Lazarus ausgestattet und debugge dort wenn es notwendig ist. Auch habe ich es vor langer Zeit mit remote Debugging versucht. Es geht allerdings zäher.

Gtk2 auf Windows muss dir nicht dieselben Probleme zeigen wie am RasPi. Da wäre Linux mit Debian wahrscheinlich geeigneter, notfalls in der VM. RasBian in VM geht nicht wirklich, zumindest habe ich voriges Jahr nichts wirklich lauffähiges gefunden.

[kupferstecher]

Ich hab für den Raspi auch auf meinem Windowsrechner cross-kompiliert, dann per WinSCP das Programm auf den Raspi geladen und per Remotedesktop bedient/getestet. Hört sich vielleicht umständlich an, aber hat ganz gut funktioniert.

[af0815]

Ich hab für den Raspi auch auf meinem Windowsrechner cross-kompiliert, dann per WinSCP das Programm auf den Raspi geladen

WinScp kann man automatisieren, das habe ich getan und nach dem kompüilieren, wird das Programm automatisch auf den RasPi geladen und ausführbar gemacht. Geht recht einfach, wenn man sich die Doku vom WinSCP mal durchliest. Ist ein Kommando-Script das von Lazarus ausgeführt wird und eine Konfigdatei für den WinSCP.