Die Sprache heißt SASS und wird als Präprozessor zur Erzeugung von CSS eingesetzt und spielt bei der Erstellung von Themes eine Rolle. Für eine Buttongroup brauchst du das nicht und für den Bau einer Oberfläche nimmt man z.B. Glade.
Von dasistnichtzumlachen am Di, 7. November 2017 um 18:00 #
Für eine Buttongroup brauchst du das nicht
Doch, anders kriegt man die fehlenden Abstände und nicht abgerundeten Kanten zwischen den Buttons nicht (mehr, Stand: vor etwa einem Jahr) hin. Für normale Buttons ist das aus Nutzerfreundlichkeit auch keine besonders gute Idee, aber für die Undo/Redo-Buttons oben in der Fensterdekoration wie gedit sie hat, ist das quasi Pflicht. Ich rede übrigens nicht von einer Radiobuttongroup, falls die hirnrissig benannten Bildschirmfotos in der Bildersuche das suggerieren sollten.
Glade
ist hinkt chronisch der entsprechenden GTK-Version hinterher. Für hingerotzte 0815 CRUD-Anwendungen reicht das vielleicht gerade noch so aus, aber für irgendwas, was sich irgendwie in GNOME wirklich integrieren soll, nicht.
Doch, anders kriegt man die fehlenden Abstände und nicht abgerundeten Kanten zwischen den Buttons nicht (mehr, Stand: vor etwa einem Jahr) hin. Für normale Buttons ist das aus Nutzerfreundlichkeit auch keine besonders gute Idee, aber für die Undo/Redo-Buttons oben in der Fensterdekoration wie gedit sie hat, ist das quasi Pflicht.
Und genau das lässt sich mit exakt zwei Zeilen Code, ohne irgendwelches CSS machen indem man einfach dem entsprechenden Widget die Style-Class "linked" hinzufügt.
Von dasistnichtzumlachen am Di, 7. November 2017 um 18:30 #
Man greift in den Style ein, ob man das händisch mit mehr CSS oder programmatisch mit weniger CSS ("linked" selbst ist schon ein Teil davon) macht, ist mir egal. Und selbst, wenn es dafür ein Enum-Mapping oder ähnliches gäbe: Buttons zusammenzukleben ist eine semantische Eigenschaft und hat nichts, aber auch gar nichts in den Style-Eigenschaften zu suchen. Es ist schon schlimm genug, dass echtes CSS alles mögliche vermischt.
Dokumentiert ist das übrigens auch nicht in der extremst unvollständigen GTK Doku, sondern auf einer Seite der GNOME-Wiki, die man nur dann findet, wenn man davon weiß und nach "gtk style class linked" sucht.
Man greift in den Style ein, ob man das händisch mit mehr CSS oder programmatisch mit weniger CSS ("linked" selbst ist schon ein Teil davon) macht, ist mir egal. Und selbst, wenn es dafür ein Enum-Mapping oder ähnliches gäbe: Buttons zusammenzukleben ist eine semantische Eigenschaft und hat nichts, aber auch gar nichts in den Style-Eigenschaften zu suchen.
Das ist reine Ansichtssache. Praktisch gesehen ändert man dadurch nur das Aussehen der Buttons. Und was interessiert es dich wie das implementiert ist? Wenn es dich aus welchen Gründen auch immer wirklich so sehr stört
gtk_style_context_add_class (context, "linked");
zu tippen, dann kannst du auch gerne GtkButtonBox verwenden, die das verlinken für dich übernimmt. Und das ist auch so dokumentiert.
Sich an so einer Kleinigkeit so festzubeißen und das als Beispiel für die Grottigkeit eines Toolkits zu nennen ist schon fast lächerlich. Sowohl GTK+ als auch Qt und andere Toolkits haben weit weit größere Defizite, wenn man das überhaupt als Defizit betrachten kann.
Von derspasshoertauf am Di, 7. November 2017 um 19:49 #
Sich an so einer Kleinigkeit so festzubeißen und das als Beispiel für die Grottigkeit eines Toolkits zu nennen ist schon fast lächerlich.
Da irrst du. Solche Semantik-Dinge sind der Grund, weshalb Webentwicklung, Markdown, Accessibility, Content Management im eigentlichen Sinne u.v.m. heute so scheisse sind.
Aber du hast Recht, es gibt viel schlimmere Dinge. Zum Beispiel die Idee, eine GUI-Bibliothek in C zu schreiben, in der vergebenen Hoffnung, dass irgendwelche Skriptkiddies, die das dann leichter benutzen können irgendwas nennenswertes damit bauen, nur um nachher ein Objektsystem und weiteres ranzuflicken. Aber gut, das konnte man vielleicht nicht vorher wissen. Interessante Parallele zu EFL übrigens, die das auch gemacht haben.
Und das ist auch so dokumentiert.
Und wieder ist es in der GNOME Wiki, wo es nichts verloren hat und wo man es nicht findet, wenn man nichts davon weiß. Übrigens scheint die Offline-Dokumentation zu GTK etwas weniger unvollständig zu sein als die Online-Dokumentation. Völlig unverständlich.
Sowohl GTK+ als auch Qt und andere Toolkits haben weit weit größere Defizite, wenn man das überhaupt als Defizit betrachten kann.
Leider geht die Tendenz nicht dahin, dass sich das bessern würde.
Da irrst du. Solche Semantik-Dinge sind der Grund, weshalb Webentwicklung, Markdown, Accessibility, Content Management im eigentlichen Sinne u.v.m. heute so scheisse sind.
Du redest hier von etwas das für den Anwendungsentwickler vollkommen nebensächlich ist. Die Art und Weise wie man einem Toolkit mitteilt, dass Buttons bitteschön zusammenhängend gezeichnet werden sollen ist wohl so unbedeutend wie sonst noch was, noch weniger von Bedeutung ist wie das Toolkit das intern realisiert. Bei Qt wüsste ich noch nicht einmal aus dem Stegreif ob das überhaupt ohne weiteres möglich ist.
Außerdem hast du ja nun schon mehrmals das Thema gewechselt. Aus der ursprünglichen Kritik, man müsse irgendwelchen CSS ähnlichen Text "reinpfuschen" wurde: Man muss etwas nutzen was hinter den Kulissen semantisch fragwürdige Dinge tut. Zu: Aber die Dokumentation taugt nichts!
Und wieder ist es in der GNOME Wiki, wo es nichts verloren hat und wo man es nicht findet, wenn man nichts davon weiß.
Nein, nicht im Wiki sondern in der offiziellen Dokumentation der GtkButtonBox:
Buttons expand to fill the box. This entails giving buttons a "linked" appearance, making button sizes homogeneous, and setting spacing to 0 (same as calling gtk_box_set_homogeneous() and gtk_box_set_spacing() manually).
Du redest hier von etwas das für den Anwendungsentwickler vollkommen nebensächlich ist. Die Art und Weise wie man einem Toolkit mitteilt, dass Buttons bitteschön zusammenhängend gezeichnet werden sollen ist wohl so unbedeutend wie sonst noch was, noch weniger von Bedeutung ist wie das Toolkit das intern realisiert.
Das ist falsch. Wenn nämlich demnächst mal wieder die GTK-Entwickler auf die Idee kommen, die Theme-Unterstützung umzubauen könnte der Code, wohingegen die normalen APIs zumindest der Dokumentation nach nicht so häufig inkompatibel geworden sind.
Bei Qt wüsste ich noch nicht einmal aus dem Stegreif ob das überhaupt ohne weiteres möglich ist.
Vermutlich über QML oder genauso schlimm wie bei GTK, aber wer würde das wollen? An sich sind kombinierte Buttons eine fragwürdige Idee, weil man zwischen Buttons zur Nutzerfreundlichkeit einen Puffer haben möchte. Aber da andere Gnome-Anwendungen das in der Titelleiste auch so machen, wollte ich meine GTK-Anwendung damals auch damit ausstatten, der Konsistenz halber. Wenn die GNOME-Leute sowas zu einem Kernidiom ernenne,n sollte man das auch vernünftig umsetzen können.
Außerdem hast du ja nun schon mehrmals das Thema gewechselt.
Nein, das blieb immer bei "saubere APIs, wo die Semantik nicht mit etwas anderem vermischt wird".
Nein, nicht im Wiki sondern in der offiziellen Dokumentation der GtkButtonBox
Mein Fehler, auch wenn es seltsam ist, dass GTK ihre Dokumentation nicht auf der eigenen Domöne hosten. Ich habe damals hauptsächlich die für Vala benutzt, die teilweise vollständiger war. Und es scheinbar immer noch ist, wenn ich mir z.B. https://developer.gnome.org/gtk3/stable/ch03.html anschaue. Die Sprechblasenmenücontainer, die zu benutzen theoretisch ganz cool gewesen wären sind immer noch nicht da. Damals stand das wenigstens auf irgendeinem Blog.
Aber das eigentliche Kernproblem, nämlich dass man die Seite nicht finden kann, wenn man nicht weiß wie der Kram heißt, ist damit ja nicht gelöst.
Gut, ja das stimmt und ich finde man sollte mehr Druck ausüben und bsw. Dokumentation deutlich umfangreicher zur Verfügung zu stellen. Einerseits will man Spenden kassieren und Entwickler gewinnen, andererseits aber tut man ja wirklich viel um die Leute zu vergraulen. Ich selbst komme mit Python und GTK gut klar, aber wir sind uns einig das es da auch noch viele Defizite gibt. Ob sich das bessert, hm ich glaube nicht.
Das Problem ist vermutlich, dass es zu unökonomisch ist, im Bereich GUI etwas ernsthaftes und ohne Dreingaben zu entwickeln. Die Nische, wo man große Softwareschmieden bedient und dann allen Schnickschnack dranbauen und allen möglichen und unmöglichen Trends nachgehen muss hat Qt. Der Rest kann sich dann leider nicht die zwei Dutzend Mitarbeiter leisten, die man zur Entwicklung bräuchte.
> CSS-ähnlichen Theme-Sprache reinpfuschen
Die Sprache heißt SASS und wird als Präprozessor zur Erzeugung von CSS eingesetzt und spielt bei der Erstellung von Themes eine Rolle. Für eine Buttongroup brauchst du das nicht und für den Bau einer Oberfläche nimmt man z.B. Glade.
Für normale Buttons ist das aus Nutzerfreundlichkeit auch keine besonders gute Idee, aber für die Undo/Redo-Buttons oben in der Fensterdekoration wie gedit sie hat, ist das quasi Pflicht.
Ich rede übrigens nicht von einer Radiobuttongroup, falls die hirnrissig benannten Bildschirmfotos in der Bildersuche das suggerieren sollten.ist hinkt chronisch der entsprechenden GTK-Version hinterher.
Für hingerotzte 0815 CRUD-Anwendungen reicht das vielleicht gerade noch so aus, aber für irgendwas, was sich irgendwie in GNOME wirklich integrieren soll, nicht.
Und genau das lässt sich mit exakt zwei Zeilen Code, ohne irgendwelches CSS machen indem man einfach dem entsprechenden Widget die Style-Class "linked" hinzufügt.
Man greift in den Style ein, ob man das händisch mit mehr CSS oder programmatisch mit weniger CSS ("linked" selbst ist schon ein Teil davon) macht, ist mir egal. Und selbst, wenn es dafür ein Enum-Mapping oder ähnliches gäbe:
Buttons zusammenzukleben ist eine semantische Eigenschaft und hat nichts, aber auch gar nichts in den Style-Eigenschaften zu suchen.
Es ist schon schlimm genug, dass echtes CSS alles mögliche vermischt.
Dokumentiert ist das übrigens auch nicht in der extremst unvollständigen GTK Doku, sondern auf einer Seite der GNOME-Wiki, die man nur dann findet, wenn man davon weiß und nach "gtk style class linked" sucht.
Das ist reine Ansichtssache. Praktisch gesehen ändert man dadurch nur das Aussehen der Buttons. Und was interessiert es dich wie das implementiert ist? Wenn es dich aus welchen Gründen auch immer wirklich so sehr stört
gtk_style_context_add_class (context, "linked");
zu tippen, dann kannst du auch gerne GtkButtonBox verwenden, die das verlinken für dich übernimmt. Und das ist auch so dokumentiert.
Sich an so einer Kleinigkeit so festzubeißen und das als Beispiel für die Grottigkeit eines Toolkits zu nennen ist schon fast lächerlich. Sowohl GTK+ als auch Qt und andere Toolkits haben weit weit größere Defizite, wenn man das überhaupt als Defizit betrachten kann.
Aber du hast Recht, es gibt viel schlimmere Dinge.
Und wieder ist es in der GNOME Wiki, wo es nichts verloren hat und wo man es nicht findet, wenn man nichts davon weiß.Zum Beispiel die Idee, eine GUI-Bibliothek in C zu schreiben, in der vergebenen Hoffnung, dass irgendwelche Skriptkiddies, die das dann leichter benutzen können irgendwas nennenswertes damit bauen, nur um nachher ein Objektsystem und weiteres ranzuflicken. Aber gut, das konnte man vielleicht nicht vorher wissen.
Interessante Parallele zu EFL übrigens, die das auch gemacht haben.
Übrigens scheint die Offline-Dokumentation zu GTK etwas weniger unvollständig zu sein als die Online-Dokumentation. Völlig unverständlich.Leider geht die Tendenz nicht dahin, dass sich das bessern würde.
Du redest hier von etwas das für den Anwendungsentwickler vollkommen nebensächlich ist. Die Art und Weise wie man einem Toolkit mitteilt, dass Buttons bitteschön zusammenhängend gezeichnet werden sollen ist wohl so unbedeutend wie sonst noch was, noch weniger von Bedeutung ist wie das Toolkit das intern realisiert. Bei Qt wüsste ich noch nicht einmal aus dem Stegreif ob das überhaupt ohne weiteres möglich ist.
Außerdem hast du ja nun schon mehrmals das Thema gewechselt. Aus der ursprünglichen Kritik, man müsse irgendwelchen CSS ähnlichen Text "reinpfuschen" wurde: Man muss etwas nutzen was hinter den Kulissen semantisch fragwürdige Dinge tut. Zu: Aber die Dokumentation taugt nichts!
Nein, nicht im Wiki sondern in der offiziellen Dokumentation der GtkButtonBox:
https://developer.gnome.org/gtk3/stable/GtkButtonBox.htmlZusätzlich ist diese Beispiel auch noch in der offiziellen GTK+ Demo-Anwendung mit entsprechendem Code gelistet.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 07. Nov 2017 um 20:21.An sich sind kombinierte Buttons eine fragwürdige Idee, weil man zwischen Buttons zur Nutzerfreundlichkeit einen Puffer haben möchte. Aber da andere Gnome-Anwendungen das in der Titelleiste auch so machen, wollte ich meine GTK-Anwendung damals auch damit ausstatten, der Konsistenz halber. Wenn die GNOME-Leute sowas zu einem Kernidiom ernenne,n sollte man das auch vernünftig umsetzen können.Nein, das blieb immer bei "saubere APIs, wo die Semantik nicht mit etwas anderem vermischt wird".Mein Fehler, auch wenn es seltsam ist, dass GTK ihre Dokumentation nicht auf der eigenen Domöne hosten. Ich habe damals hauptsächlich die für Vala benutzt, die teilweise vollständiger war. Und es scheinbar immer noch ist, wenn ich mir z.B. https://developer.gnome.org/gtk3/stable/ch03.html anschaue.
Die Sprechblasenmenücontainer, die zu benutzen theoretisch ganz cool gewesen wären sind immer noch nicht da. Damals stand das wenigstens auf irgendeinem Blog.
Aber das eigentliche Kernproblem, nämlich dass man die Seite nicht finden kann, wenn man nicht weiß wie der Kram heißt, ist damit ja nicht gelöst.
Gut, ja das stimmt und ich finde man sollte mehr Druck ausüben und bsw. Dokumentation deutlich umfangreicher zur Verfügung zu stellen. Einerseits will man Spenden kassieren und Entwickler gewinnen, andererseits aber tut man ja wirklich viel um die Leute zu vergraulen. Ich selbst komme mit Python und GTK gut klar, aber wir sind uns einig das es da auch noch viele Defizite gibt. Ob sich das bessert, hm ich glaube nicht.
Gehe ich auch nicht von aus.
Das Problem ist vermutlich, dass es zu unökonomisch ist, im Bereich GUI etwas ernsthaftes und ohne Dreingaben zu entwickeln.
Die Nische, wo man große Softwareschmieden bedient und dann allen Schnickschnack dranbauen und allen möglichen und unmöglichen Trends nachgehen muss hat Qt.
Der Rest kann sich dann leider nicht die zwei Dutzend Mitarbeiter leisten, die man zur Entwicklung bräuchte.