Gtk3 ist nun das Standard-LCL-Widgetset in Linux

[theo]

Die Probleme hatte ich beim Arch und dafür gibt es hier keine Infos .
Probier mal aus , die fehlenden Libs unter EndeavourOS zu installieren , da brauchst Du auch 10 Stunden.
Weil die GTK-Geschichten findest Du nicht in deren Paketquellen , die muß man erst mit yay kompilieren (mit KI-Hilfe und ewig Zeit hatte das ja dann auch geklappt ).

Warum sollte ich mir so eine schrottige Distro antun?
Das ist auch so ein Phänomen, dass die Leute immer die schrägsten Distros installieren, nur damit sie dann herumjammern können, wie kompliziert alles ist.

[af0815]

Die Probleme hatte ich beim Arch und dafür gibt es hier keine Infos .
Probier mal aus , die fehlenden Libs unter EndeavourOS zu installieren , da brauchst Du auch 10 Stunden.
Weil die GTK-Geschichten findest Du nicht in deren Paketquellen , die muß man erst mit yay kompilieren (mit KI-Hilfe und ewig Zeit hatte das ja dann auch geklappt ).

Warum sollte ich mir so eine schrottige Distro antun?
Das ist auch so ein Phänomen, dass die Leute immer die schrägsten Distros installieren, nur damit sie dann herumjammern können, wie kompliziert alles ist.

Grottig nicht unbedingt

EndeavourOS Linux, a terminal-centric Arch-based desktop built for users who want control, speed, and community support

Nur halt nicht für Leute die mit den tiefen von Linux nicht unbedingt firm sind. Terminal-Centric sagt eigentlich schon alles.

[theo]

Grottig nicht unbedingt

Ich habe "schrottig" geschrieben!
Nee, für irgendwas wird diese Distro schon gut sein, bloss eher nicht für den Desktop.

EndeavourOS Linux, a terminal-centric Arch-based desktop built for users who want control, speed, and community support

Nur halt nicht für Leute die mit den tiefen von Linux nicht unbedingt firm sind. Terminal-Centric sagt eigentlich schon alles.

Genau. Auch "control" und "speed" lassen nicht auf Komfort schliessen.
"speed" heisst, wir haben alles "Überflüssige" und Komfortable rausgeschmissen.
"control" heisst, du kannst und musst alles selber machen.

[Niesi]

Ich bin auf interessante Punkte bei der Lizenzierung gestoßen: Qt ist nicht komplett OpenSource.

Wer Qt als OpenSource nutzen und seine Software kommerziell vermarkten will muss

• dynamisch verlinken

• die Qt-Bibliotheken müssen austauschbar sein

• In der Programmdoku muss angegeben werden, dass Qt unter der LGPL verwendet wird

Wer seine Software als Monolith (ein Programm mit allem drin, keine dlls, kein dynamischer Zugriff auf Bibliotheken) verkaufen will, muss eine Lizenz von "The Qt Company" kaufen.

Das ist bei GTK nicht so. Dort müssen nur Modifikationen der GTK-Bibliothek unter der LGPL veröffentlicht werden. Ansonsten ist alles frei.

[corpsman]

a) GTK3
Das Kernprogramm , GUI und sämtliche Aero-Berechnungen laufen gut und schnell (vergleichbar dem GTK2-Programm) , aber mein OpenGL geht leider nicht mehr (old Legacy-Code).

Das mit dem Umstellen ist nicht trivial, aber machbar, ich bin auch gerade dabei meine Anwendungen von OpenGL Lecacy um zu stellen damit es mit GTK3 wieder geht. Hier ein Paar wo das schon geklappt hat:

https://github.com/PascalCorpsman/fpc_atomic
https://github.com/PascalCorpsman/ConfigTD
https://github.com/PascalCorpsman/mini_ ... ixelEditor

Allen gemein ist, dass ich eine art "wrapper" geschrieben habe, mit diesem kann man den Legacy mode recht einfach emulieren. Kern des ganzen sind die folgenden .pas Dateien:
https://github.com/PascalCorpsman/Examp ... engine.pas -> Genereller Zugrif zum Render von graphiken
https://github.com/PascalCorpsman/Examp ... hecker.pas -> Man in the middle OpenGL treiber, welcher es ermöglich einen Haltepunkt in allen Legacy Calls zu bekommen
https://github.com/PascalCorpsman/Examp ... itives.pas -> glbegin Emulation via Shader

Damit habe ich bereits sehr viele meiner Anwendungen umstellen können.

Generell gilt es bei GTK3 zu beachten, "Zeichnen" ist nur noch in den Paint Events erlaubt, mal eben so nebenbei ist nicht mehr. Alles Zeichnen muss via invalidate getriggert werden (gerade der ladebalken von FPC_Atomic musste bei mir so überarbeitet werden).

[theo]

Generell gilt es bei GTK3 zu beachten, "Zeichnen" ist nur noch in den Paint Events erlaubt, mal eben so nebenbei ist nicht mehr. Alles Zeichnen muss via invalidate getriggert werden (gerade der ladebalken von FPC_Atomic musste bei mir so überarbeitet werden).

Das wurde offiziell schon immer so empfohlen.
Cross platform ging das beliebige Zeichnen nie überall, soweit mir bekannt ist.
Wenn es trotzdem ging, war das eigentlich "undokumentiertes Verhalten".

[Frank Ranis]

Hallo corpsman,

vielen Dank für deine Antwort ,

Das mit dem Umstellen ist nicht trivial, aber machbar, ich bin auch gerade dabei meine Anwendungen von OpenGL Lecacy um zu stellen damit es mit GTK3 wieder geht. Hier ein Paar wo das schon geklappt hat:

Ich habe mir mal den Code deines PixelEditor gezogen und gestöbert .
Verstehe bis dato aber nur Bahnhof .

Ich hatte mir gestern mal die Demos von der https://wiki.delphigl.com/index.php/Laz ... 3_Tutorial gezogen.
Was ich probiert habe lief soweit , aber die ganzen Abläufe , auch speziell die Geschichte mit den Vertexshader.glsl und Fragmentshader.glsl habe ich noch nicht gerafft .
Habe das bei dir als fixe Strings im uOpenGLGraphikEngine.pas gefunden , braucht man das nie wieder anfassen ?

Ich seh schon , das wird noch ein steiniger Weg .

Gruß

Frank

[Mathias]

Ich hatte mir gestern mal die Demos von der https://wiki.delphigl.com/index.php/Laz ... 3_Tutorial gezogen.
Was ich probiert habe lief soweit , aber die ganzen Abläufe , auch speziell die Geschichte mit den Vertexshader.glsl und Fragmentshader.glsl habe ich noch nicht gerafft .

Du verstehst nicht, was die beiden Shader für einen Zweck erfüllen ?

[Frank Ranis]

Hallo Mathias ,

Du verstehst nicht, was die beiden Shader für einen Zweck erfüllen ?

Nicht so richtig .
Dient der Shader als eine Art Übersetzer zwischen der Hochsprache (Pascal , C ....) und der Grafikkarte , oder wie muß ich das verstehen.

So wie ich das gesehen habe , wird von machen Programmierern der Shader-Code extern auf Platte angelegt (so wie in deinen Demos) .
Andere (wie Corpsman) legen sie intern als Ressourcen-String ab und das scheint dann auch für alles gut zu sein.

Gruß

Frank

[Mathias]

Also die Shader Sprache (GLSL) hat mit Hochsprachen wie C und Pascal gar nichts zu tun.
Der Shader Code, welcher als String vorliegt, schickt man über den Grafiktreiber in die Grafikkarte. Der Treiber kompiliert dann den Code, so wie es FPC mit dem Pascal-Code macht.
Wo du den Shader-Code ablegst, das ist deine Sache, schlussendlich muss du einfach einen Pointer zum String an den Grafiktreiber übergeben. Ich habe im Tutorial Text-Dateien gewählt weil diese im Handling am einfachsten sind. Man kann genau so gut einfach eine Stringkonstante nehmen.

Im Shader läuft eigentlich der ganze Render Prozess ab. Dei ganze Transformation macht man dort, so wie auch die ganzen Beleuchtungs Effekte.

Ich hoffe du verstehst jetzt was es grundlegend mit den Shader auf sich hat.

[corpsman]

Hallo corpsman,

vielen Dank für deine Antwort ,

Das mit dem Umstellen ist nicht trivial, aber machbar, ich bin auch gerade dabei meine Anwendungen von OpenGL Lecacy um zu stellen damit es mit GTK3 wieder geht. Hier ein Paar wo das schon geklappt hat:

Ich habe mir mal den Code deines PixelEditor gezogen und gestöbert .
Verstehe bis dato aber nur Bahnhof .

Ich hatte mir gestern mal die Demos von der https://wiki.delphigl.com/index.php/Laz ... 3_Tutorial gezogen.
Was ich probiert habe lief soweit , aber die ganzen Abläufe , auch speziell die Geschichte mit den Vertexshader.glsl und Fragmentshader.glsl habe ich noch nicht gerafft .
Habe das bei dir als fixe Strings im uOpenGLGraphikEngine.pas gefunden , braucht man das nie wieder anfassen ?

Ich seh schon , das wird noch ein steiniger Weg .

Gruß

Frank

Du musst aufpassen, das was meine Engine da macht hat eigentlich nichts mit Shader Programmierung zu tun, mir ging es dort darum den "alten" Code als Shader laufen zu lassen und so wenig wie nur irgend möglich im "alten" code zu ändern. Das hat aber auch Nachteile, denn mein "wrapper" unterstützt zwar die alten Befehle fast nathlos macht dies aber mit deutlichem Overhead, das heißt das wird alles "Langsam". Bei Anwendungen wir FPC_Atomic oder dem Pixeleditor, wo es quasi fast keine Texturen gibt ist das Egal. Sollte Deine Anwendung aber deutlich "Mehr" machen, kannst du diesen "Hack" nicht machen..

[Mathias]

@corpsman

Erstaunlich was du das für Games mit der LCL hingekriegt hast. Ich hätte für sowas eher SDL und GLFW genommen.

[corpsman]

*g*
naja viel LCL ist da ja nicht mehr drin, ist ja nur ein OpenGL Fenster und das weiter reichen der Events in meine Anwender Klasse. GLFW kenne ich nicht, SDL kenne ich ist mir aber unsympatish, da ich keine weiteren Libs mit ausliefern möchte, gerade deswegen ist Lazarus ja so toll, ich schreibe es einmal und es läuft direkt auf den großen Plattformen

[Mathias]

da ich keine weiteren Libs mit ausliefern möchte, gerade deswegen ist Lazarus ja so toll,

Ja. das ist ein riessen Vorteil von RTL / LCL, dafür wird dies mit sehr viel Overhead erkauft.

Ich habe eine Demo mit GTK4 geschrieben, alles läuft sehr geschmeidig, mit der LCL habe ich sowas nicht hingekriegt.
Und dies ohne OpenGL. GTK4 arbeitet mit Cairo, oder mit dem Modernen Snapshoot alles mit Double und die LCL verwendet wie zu Win3 Zeiten noch Integer. Auch mit der Framrate kämpft die LCL.

[corpsman]

Ja. das ist ein riessen Vorteil von RTL / LCL, dafür wird dies mit sehr viel Overhead erkauft.

Solltest du damit die Dateigröße meinen, die ist mir wurscht.
Wenn du dir meine Anwendungen anschaust wirst du auch feststellen, dass mir meistens eher "einfache" Graphiken im 2D Bereich genügen. Gerade an einem Beispiel wie FPC_Atomic habe ich Pro Frame ca 20 bis 50 Graphiken die beteiligt sind, und einen Netztraffic der geringer ist als der meines Parallel laufenden webradios. Damit will ich sagen, dass es häufig gar nicht notwendig ist high end zu haben (auch wenn ich es durchaus gut fände zu wissen das High end theoretisch machbar wäre ).

Zajian hat in Salamanca auch sehr schön gezeigt was mit den verschiedenen Widget Sets geht und was nicht, auch wo die LCL unterstützen kann (er zeigte das an einer Anwendung die einfach nur die Uhrzeit angezeigt hatte).

Deine Anspielung auf Double und Integer kann ich nicht ganz verstehen, meinst du damit die Koordinaten der Widgetsets. In OpenGL ist das dann "Single"..