Gtk3 Infos

[af0815]

Nachdem es laut Mailinglist ja schon Auffassungsunterschiede für GTK3 gibt ("More Gtk3 Status"), wird nicht mal mit GTK4 gespielt

Da geht auch darum, wie und warum welche Layer vorhanden sind/sein müssen.
Zitat von Anthony Walter übersetzt

Hier ist nun das erste große Problem mit dem implementierten Gtk3-Widgetset. Irgendwie hat jemand entschieden, dass es eine nette Idee wäre, ein viertes Stück nur für Gtk3 hinzuzufügen. Dieses Stück versucht, sich zwischen 2 und 3 einzukeilen, indem es die bereits existierende API im flachen C-Stil aus Stück 3 als eine große Reihe von Pascal-Objekten neu erstellt, die die Gtk3-API als eine Reihe von Objekten neu deklarieren (siehe TGtk3Widget in der Datei gtk3widgets.pas). Jetzt haben wir eine vierte Schicht nur für Gtk3, die nicht nur mehr Komplexität hinzufügt, sondern auch eigenartige Verhaltensweisen einführt, die ändern, was jemand, der einen nativen Gtk3-Widget-Port schreibt, wissen muss, während er mit der Erstellung eines Steuerelements oder einer Komponente fortfährt.

Auszugsweise Antwort von Zelijko

Ich habe GTK3-Skelett und grundlegende Steuerelemente + einige Winapi-Funktionen festgeschrieben (AFAIR, es war 2012 oder sogar 2013). Alles basiert auf der qt/qt5/carbon/cocoa-Philosophie, die bereits in LCL enthalten ist. Zu dieser Zeit habe ich gtk2 gewartet und es ist nicht so angenehm für den Betreuer (vielleicht für Sie als Programmierer Ihrer Apps, aber nicht für den Betreuer von Lazarus lcl-ws), also war meine Entscheidung, gtk3 in Pascal-Objekte zu kapseln, und wenn mich jemand darum bittet gtk4 einführen Ich werde es genauso machen. Wieso den ? Einfache Wartung.
Außerdem gab es nach dem Commit von gtk3 keine oder nur wenige Commiter für die gtk3 ws (ich konnte mit gtk3 ws wegen fehlender Freizeit nicht weitermachen).

Da gibt es auch Auffassungsunterschiede zwischen einem Universellen Interface und einer dünneren Variante.

Somit muss man die Diskussion im internationalen Forum und die Mailingliste betrachten um einen Überblick zu bekommen.

[hum4n0id3]

Wie ich das verstehe. An Gtk gibt es kein wirkliches Interesse und den vorhandenen Betreuer fehlt die Zeit. Die Reise geht Richtung Qt.

Für mich ist das nicht wirklich schlimm, weil unter Linux die KDE- und Gnome-Themes sich mittlerweile anpassen. Es gibt Gtk-Breeze sowie Qt-Adweita Themes.

[theo]

Die Reise geht Richtung Qt.

Das klingt für mich nach Marketing-Blabla.

Wir verlieren einfach einen Ast / eine Option / eine Freiheit, wenn niemand etwas dagegen unternimmt und das GTK3 Interface weiter entwickelt.

Das Problem ist, dass viel schlau dahergeredet wird und niemand was tut.

Wenn wir hier einen "GTK3-Interface Workshop"-Thread aufmachen würden, wer wäre dabei die Sache zu analysieren, Lösungen zu besprechen und umzusetzen?

- Theo
-
-
-

[af0815]

Wie ich das verstehe. An Gtk gibt es kein wirkliches Interesse und den vorhandenen Betreuer fehlt die Zeit. Die Reise geht Richtung Qt.

An Gtk besteht sehr Interesse, nur fehlt die Kapazität und gtk2 geht ja eeeeeh noch.

Vergiss QT für eine Ersetzung, da ist auch nicht sicher wohin die Reise geht. Wegen Fork und Lizenz ist auch nicht alles so eitle Wonne, wie es die QT Verfechter gerne präsentieren. Die haben halt Glück, das der Maintainer auf QT gegangen ist und nicht bei gtk geblieben ist. Aber das ist alles eigentlich egal, weil wenn sollte es immer bei mehreren Widgetsets bleiben, die auch die großen Distributionen anbieten.

Wenn wir hier einen "GTK3-Interface Workshop"-Thread aufmachen würden, wer wäre dabei die Sache zu analysieren, Lösungen zu besprechen und umzusetzen?

Klingt mal nicht schlecht, alleine um zu erkennen wie die Widgetsets eingebunden sind und auch wie das funktioniert. Klar, das sind große Schuhe die man da probiert.

Ich würde für einen nicht öffentlichen Workshop plädieren, damit mal die darüber diskutieren können, die daran mitstudieren oder arbeiten wollen. Damit kann man auch abbrechen, falls man draufkommt, das die Nummer zu groß ist.

[theo]

Klingt mal nicht schlecht, alleine um zu erkennen wie die Widgetsets eingebunden sind und auch wie das funktioniert. Klar, das sind große Schuhe die man da probiert.

Ich würde für einen nicht öffentlichen Workshop plädieren, damit mal die darüber diskutieren können, die daran mitstudieren oder arbeiten wollen. Damit kann man auch abbrechen, falls man draufkommt, das die Nummer zu groß ist.

"nicht öffentlich" ist auch gut, aber ich kann dir jetzt schon sagen, dass "die Nummer zu groß ist".
Ist halt wie wenn man vor der Eiger-Nordwand steht. Die Vernunft und die Bequemlichkeit sagt einem, dass man nicht versuchen sollte da hoch zu kommen.
Wenn man es aber ganz "hart" will, dann kann man es schaffen.

Wie sagte Churchill: “I have nothing to offer but blood, toil, tears and sweat”

[m.fuchs]

Wenn wir hier einen "GTK3-Interface Workshop"-Thread aufmachen würden, wer wäre dabei die Sache zu analysieren, Lösungen zu besprechen und umzusetzen?

Also ich würde meine begrenzte Zeit durchaus mit einbringen. Aber Frage: wäre es nicht sinnvoll gleich auf GTK4 zu setzen?Es dauert ja sicher ein wenig alles zu bauen und das erscheint mir dann langlebiger.

[af0815]

Wenn wir hier einen "GTK3-Interface Workshop"-Thread aufmachen würden, wer wäre dabei die Sache zu analysieren, Lösungen zu besprechen und umzusetzen?

Also ich würde meine begrenzte Zeit durchaus mit einbringen. Aber Frage: wäre es nicht sinnvoll gleich auf GTK4 zu setzen?Es dauert ja sicher ein wenig alles zu bauen und das erscheint mir dann langlebiger.

GTK4 wäre grüne Wiese, wo sich keiner hingesetzt hat und als Spielwiese IMHO besser geeignet, weil es keine Konflikte mit aktuellen Umsetzungen gibt. Und wenn man anfängt, so ist ja egal wo.

+1

[theo]

Also ich würde meine begrenzte Zeit durchaus mit einbringen.

Gut.

Aber Frage: wäre es nicht sinnvoll gleich auf GTK4 zu setzen?Es dauert ja sicher ein wenig alles zu bauen und das erscheint mir dann langlebiger.

Das ist eine gute Frage.
Einiges spricht dafür, anderes dagegen.
Man muss einfach sehen, dass trotz der Mängel das GTK3 Interface mal prinzipiell läuft und man das wahrscheinlich im Detail komplettieren könnte.
Ein GTK4 auf dieses Level zu bringen ist ein noch viel höherer Berg.

Bei GTK wird das API im Prinzip erst stabil, wenn es bald tot ist.
GTK4 ist noch im Wandel.

Man könnte beim GTK3-Interface erst mal die "deprecated" Sachen ersetzen (ist ja auch schon gut 10 Jahre alt), dann käme man auch näher an die 4.
Ich denke am Besten wäre, an GTK3 zu schrauben mit GTK4 im Hinterkopf. Also im Zweifel die Lösung zu wählen, die auch "Zukunft" hat.

[charlytango]

Entschuldigt bitte wenn das jetzt Off Topic ist. Und ich will auch den Thread nicht kaputt machen. Ich kenn mich mit so einer Programmierung auch nicht aus.

Nur hört sich das historisch für mich an wie viele Open Source Projekte,
Maintainer geben Projekte auf oder wechseln weil Zeit und Geld fehlt.
Und wenn ich von einer Dimension wie Eiger Nordwand höre fällt mir Minihirn als erstes eine fehlende Ressourcenplanung ein. Nämlich Zeit UND Geld. Und das wohl auch über Jahre hinweg. Welche Firma würde denn GTK einsetzen wollen um vielleicht zu den Kosten beizutragen?

Altruismus ist herrlich, wenn man ihn sich leisten kann.

Aber was sage ich, jeder hier weiß das. Nur der Enthusiasmus lässt einen das manchmal vergessen.

Bin nur der einsame Rufer in der Wüste der nach einem sauberen Aufsetzen eines solchen Projektes ruft.

Keine Antworten nötig, wenn überhaupt in einem anderen Thread oder PM, damits nicht ausufert.

[theo]

Lazarus ist nicht entstanden, weil jemand einen "Businessplan" hatte.

Im Moment sind wir hier dabei, Freiwillige bzw. Enthusiasten zu finden und keine Bedenkenträger.

[af0815]

Ein (genialer) Maintainer musste sich für einen Bereich entscheiden und das ist halt für ihn QT geworden. Weil 2 so große Bereich geht einfach nicht, das ist nachvollziehbar.

Das ist in jedem Projekt so. Das hat nichts mit OpenSource zu tun. Wenn in einer Firma etwas kein Geld bringt, so wird es fallengelassen. Und das ohne viel Federlesen, im Softwarebereich kannst du noch von Glück reden, wenn es dann im SourceCode veröffentlicht wird. Ansonsten Pech gehabt.

[af0815]

Bezüglich Gtk3:
Der Anknüpfungspunkt ist /lazarus/lcl/interfaces/gtk3 und als Vergleich /lazarus/lcl/interfaces/qt5

bei QT gibt es gleich einmal die cbindings mit den c-files, die es bei gtk3 nicht gibt. Dort gibt es die gtk3bindings, die aber alle pas files sind. Das müssen also mal die Dateien sein, die mit gir2pascal erzeugt werden. Das heisst es gibt einmal einen Prozess vorher der passen muss, die Umwandlung von gir in pas.

[theo]

bei QT gibt es gleich einmal die cbindings mit den c-files, die es bei gtk3 nicht gibt. Dort gibt es die gtk3bindings, die aber alle pas files sind. Das müssen also mal die Dateien sein, die mit gir2pascal erzeugt werden. Das heisst es gibt einmal einen Prozess vorher der passen muss, die Umwandlung von gir in pas.

Nicht wirklich.
Qt ist komplizierter, weil zuerst eine Interface DLL in C gebraucht wird, da Qt in C++ ist und FPC mit diesen Klassen nichts anfangen kann.
Daraus wird eine "Zwischenschicht" -> libQt5Pas.so.
Darüber bist du übrigens neulich gestolpert (Re: Lazarus QT5 auf bare Metal Debian 11 Probleme)

Diesen Schritt brauchst du bei GTK nicht, da FPC das C Interface direkt ansprechen kann.
Gir2Pas ist ein Art Header-Übersetzer (wie h2pas), der einem sehr viel Arbeit abnimmt.
Das muss ja sowieso getan werden.

Aber: Das ist bei GTK3 ja alles da, also primär kein Problem. Erst wenn man die "Deprecations" raus haben will vielleicht.

[af0815]

Qt ist komplizierter, weil zuerst eine Interface DLL gebraucht wird, da Qt in C++ ist und FPC mit diesen Klassen nichts anfangen kann.
Daraus wird eine eine "Zwischenschicht" -> libQt5Pas.so.
Darüber bist du übrigens neulich gestolpert (Re: Lazarus QT5 auf bare Metal Debian 11 Probleme)

Korrekt, deswegen habe ich mal in die Verzeichnisse geschaut. Und da ist mir noch viel mehr aufgefallen, auch wie Fragmentiert gtk2 zwischen Lazarus und FPC ist, aber das ist eine andere Geschichte. Ich habe dort schon viel Zeit verbracht, weil es manchmal im RasPi Bereich (arm-linux) zu Problemen gekommen ist.

Aber: Das ist bei GTK3 ja alles da, also primär kein Problem. Erst wenn man die "Deprecations" raus haben will vielleicht.

Nicht nur das, es sollte zuerst möglich sein, mal auf dieselben Header zu kommen, wie in Lazarus jetzt vorhanden sind. Damit weis man mal, das der Weg der richtige ist. Ich kenne das von anderen Fällen, manchmal ist es notwendig von Version zu Version gehen und nicht den ganzen Schritt auf einmal.

Deswegen ist auch der Prozess von Anfang an, meiner Meinung nach, wichtig. Damit kann man jederzeit die Basis wiederherstellen. Ich bin unter Linux nicht so zu Hause wie andere hier.

Nach den Basics, stellt sich die Frage und wie Testen. Weil wenn braucht man ja ein nachvollziehbares Umfeld um zu sehen, das das ganze nicht verschlimmbessert wurde.

[hum4n0id3]

Bei GTK wird das API im Prinzip erst stabil, wenn es bald tot ist.

Auch nur komisch weil es bisher der Wahrheit entspricht

Man kann ein privates Gtk3-Repository erstellen und die beteiligten und/oder interessenten einladen. Wenn es nennenswerte fortschritte gibt, kann man das Repository immer noch public machen.

Ich kann euch leider nicht helfen. Weder habe ich große Pascal-Erfahrungen, noch wirklich Zeit und komme meinem eigenen Zeug nicht hinterher