Diskussion:GTK

Aus Wikibooks

Der Titel sollte geändert werden zu „GTK mit C++“, da hier ja nicht allgemeingültig GTK behandelt wird, sondern unter der Voraussetzung, daß C++ bekannt ist. Die Verwendung von GTK beschränkt sich jedoch nicht auf C, weshalb dadurch ein falscher Eindruck entstehen könnte. -- Kuroi-ryu 13:45, 16. Okt. 2007 (CEST)

Nein, dieses Buch hat dzt. nichts mit C++ zu tun. Es wird ansatzweise das klassische GTK+ in C beschrieben. Einziger Unterschied ist, dass die im Buch gelisteten C-Programme dann mit einem C++-Compiler übersetzt werden sollen. Für C++ gibt es ein eigenes GTK-Interface namens "gtkmm". --62.47.56.16 09:21, 1. Nov. 2007 (CET)

Der Einwand ist berechtigt. Den Punkt habe ich ergänzt. -- Penma 20:35, 28. Jan. 2008 (CET)

[Bearbeiten] Compiler-Befehl

Es wäre für Besucher sicher sehr hilfreich, wenn irgendwo mal ein Befehl stehen würde, wie man die Programme auch kompiliert. Immerhin gibt es doch Unterschiede zum einfachen gcc -o datei.c datei. Das was ich über Google gefunden habe, funktioniert mit den Programmen hier leider nicht :-( Daher kann ich das nicht selbst hinzufügen. -- 89.55.173.215 21:59, 29. Mär. 2009 (CEST)

[Bearbeiten] Dampf ablassen - Hinweise auf Probleme in gtk

Hallo,

aller Voraussicht nach werde ich nicht an diesem Buch mitschreiben. Aus meiner Sicht gibt es viel zu viele Aufgaben in der Verbesserung von Software, also beim Programmieren selbst, um das zu tun. Heute bin ich aber zu müde für konzentrierte Arbeit - ich werde hier Dampf über gtk ablassen. Aber im Besonderen im Hinblick auf Lücken in der Dokumentation, die ein solches Buch (leicht ? - jedenfalls auf einem Bruchteil der Seiten der Referenzen) füllen könnte.

Ich arbeite seit zwei Jahren an einem Projekt in Python mit pygtk, von dessen Anwendung ich recht und schlecht überlebe, und werde es demnächst teuer zum Kauf anbieten. Die Käufer werden aber auch den Source-Code vollständig (und individualisiert) erhalten. gtk war meine vierter GUI-Builder, davor XView mit C++, TK mit tcl und auch Python, und ein bisschen VisualStudio. Einiges ist sehr gut in gtk, das pixbuf-Objekt z.B. - ich wollte frisch skalierte Bilder aus dem Arbeitsspeicher per ftp direkt zum ISP-Provider hochladen (also ohne Zwischenspeichern auf die Festplatte) - nachdem ich die Python-ftp-Schnittstelle neu geschrieben hatte, ging das per pixbuf.save_to_callback() auch. Ich bin bestimmt kein Dünnbrettbohrer. pixbuf_scale_simple() ist schnell genug, um auch auf älterer Hardware bei echten Bildern ab 200*320px ruckelfrei schnellen Folgen von resize-events zu folgen usw. usw. . Ja, auch ScrolledWindow.add_with_viewport() ist das beste, was ich in der Hinsicht je gesehen habe.

Pango ist klasse, cairo auch (das ist allerdings kein Verdienst der gtk-Programmierer).

Aber nun zum Dampfablassen: Am zweiten Tag gab es erst einmal eine stundenlange Suche nach set_border_width() oder so etwas Ähnlichem. Ergebnis: Gibts nicht. Was die gtk-Leute "border" nennen, ist, was der Rest der Welt "margin", vielleicht auch "(external) padding" nennt, und die border_width gibt's tatsächlich nicht - die steht fixiert auf 2px. TK (beschreibt sich als einfach und ist das auch) hat schon hier mehr zu bieten.

TK's grid() hat auch mit anchor('NW') and friends auch ein gutes Stuck mehr zu bieten als gtk.Table(). TK's pack() gegenüber gtk.Box auch. CSS mit Tables kann auch viel mehr (zumindest dann, wenn man in gtk eben nicht Massen von einander einhüllenden gtk.Boxen schreiben will) - und das halte ich eigentlich für Minimum, wenn schon von hochwertigen Oberflächen die Rede ist.

Und kein Wort in den Tausenden Seiten Tutorial und Referenz, das auf die fixierte border_width hinweist. Diese Seiten haben an dem Punkt nichts anderes geleistet, als die Zeit zur Feststellung, dass es das nicht gibt (in einem so großen System mit um die 100 Methoden der Basisklasse gtk.Widget) zu vervielfachen.

Eine der nächsten Horror-Erfahrungen kam dann mit den shared Styles. Ich wollte in bestimmten Fenstern einen tiled background, und da ich Xlib mal ein bischen kennengelernt hatte, war das auch zu schaffen. Nur: Diesen background kriegen dann erst einmal alle Widgets dieser Klasse (In meinem Fall Toplevel-Windows - in den Dialogen sah das unglaublich scheußlich aus). Noch heute bin ich in der Situation, dass ich mit einem Toplevel-Window GM, in dem SP liegt, nicht weiß, warum dies:

sty = SP.eveBox.get_style().copy()
tile = gtk.gdk.pixmap_create_from_xpm(GM.window, None, graficsDir + 'bgTile4.bmp')
sty.bg_pixmap[0] = tile[0]
SP.eveBox.set_style(sty)

zur Abtrennung des Styles funktioniert, dies

sty = GM.get_style().copy()
tile = gtk.gdk.pixmap_create_from_xpm(GM.window, None, graficsDir + 'bgTile4.bmp')
sty.bg_pixmap[0] = tile[0]
SP.eveBox.set_style(sty)

aber nicht. Letzteres bringt den Hintergrund mit bgTile4 wieder auf alle Toplevels - copy() trennt irgendwie, und natürlich völlig undokumentiert, nur halb ab. Ich habe nur gelernt, dass ich in den Tausenden Seiten Referenz gar nicht erst nach einer Antwort zu suchen brauche.

Insgesamt schon einige Tage habe ich dann darauf verwendet rc-Style-Bindungen an Widgets hinzukriegen. Ich weiß, dass jedes Mal, wenn ich das wieder versuche, einige Stunden Experimentieren fällig sind, mit Pech ohne Ergebnis. Immerhin habe ich erreicht, meine Scrollbars, d.h. vor allem auch deren Tröge färben zu können (was nicht aus den Style Attributes der Referenz zu erschließen war). Aber dass eine Zeile wie

widget "Wain.*GtkEntry" style "entry_blabla"

mit einem benannten Toplevel Wain funktioniert, in dem die Entries keinesfalls als direkte Childs liegen, und das eigentlich sinnvollere

widget "Wain.*.GtkEntry" style "entry_blabla"

nicht, kann ich nicht verstehen. Außerdem style ich hier Entries - warum das mit widget_class nicht funktioniert, was eigentlich ja auch sinnvoller wäre ??? Wie gesagt, normalerweise langes Experimentieren mit ungewissem Ausgang - die Dokumentation ist bei weitem nicht genau genug. Lang wird das Experimentieren auch dadurch, dass es nicht die geringsten Fehlermeldungen beim Lesen der ausgesprochen syntax-sensiblen rc-files gibt.

Und es gibt bugs - von denen will ich hier nicht reden (vielleicht ja auch durch pygtk oder Windows verursacht). Naja, ein Beispiel: key_release_events für die Tab-Taste gehen bei mir in das folgende Widget der Fokus-Kette. Ein Horror für Validierungs-Code für Entries in einer der üblichen Entry-Ketten zur Datenerfassung. Zu wissen, dass es die gibt, macht ein Experimentieren wie oben nicht lustvoller.

Vor einiger Zeit - das heißt nach anderthalb Jahren Erfahrung mit der pygtk-Referenz - stieß ich dann - mehr beim Schmökern auf library.gnome.org - darauf, dass es engines gibt. Damit ließen sich z.B. die 2px border-width überwinden - tatsächlich kann man widgets damit so ziemlich jede gewollte Gestalt geben. Da angekommen, und die rc-Files wirklich genau verstanden, lassen sich mit Code hauptsächlich aus Cairo mit vertretbarem Aufwand endlich tatsächlich die hochwertigen Oberflächen machen, die gtk.org verspricht. Vorher müsste ich mir allerdings - wie der banshee-Chefentwickler - noch einen eigenen ListView schreiben, und danach wird das eher ein Nebenprojekt sein. D.h. nach zwei Jahren intensiver, fast täglicher Beschäftigung mit gtk schätze ich, erst nach vier Jahren wirklich zufriedenstellende Oberflächen erzeugen zu können, und bis zur wirklichen Beherrschung ohne jedes Experimentieren und mit wenig Nachschlagen wahrscheinlich 10.

Es gibt aber keine Alternativen (außer via Java vielleicht) für wirklich portablen Code. wxWidgets kann auf gtk aufsetzen und insofern nicht grundlegend besser sein.

Sollte allerdings die w3c-Vision wahr werden, Programmoberflächen als svg-Grafiken mit event-sensiblen Elementen wirklich malen zu können (was übrigens jetzt schon geht, aber z.B. bei Tabellen wahrscheinlich nicht mal an die - vielerseits bemängelte - Performance von gtk.TreeView heranreicht), dann sieht es sehr, sehr trübe aus für die Zukunft von gtk. Wer will sich dann noch so tief einarbeiten, eigene engines zu schreiben ?

Dieses Buch hier steht offenbar ganz am Anfang - vielleicht bleibt dieser Anfang auch leider erst einmal monatelang "pending". Was ich hier sagen will: Es kann nicht darum gehen, die Tutorials ein x-tes Mal abzuschreiben, oder die halbautomatisch erzeugten Referenzen. Ohne Englisch geht hier gar nichts. Leuten, die man einzig durch das Deutsch der Übersetzung zu gtk bringt, tut man langfristig Schlimmes an. Sehr viel Ärger und Frust hätte mir eine Dokumentation erspart, die

1. sich nicht darum herumdrückt, Beschränkungen wie bei der border-width auch anzugeben, d.h. auch

1b. zu erklären, dass man in gtk vielfach Boxen für reine Positionierungszwecke ineinanderschachteln muss. Grundsätzlich muss man von vornherein bereit sein, immer wieder gtk.Boxen für keinen anderen Zweck als das \hfil von TeX erzeugen. Und es wäre auch gut, einmal zu erfahren, welcher Typ Widget für \hfil eigentlich am ökonomischsten ist.

2. die shared Styles gründlich zu erklären (bis zu dem Punkt, wo es um die Konsequenzen der Verwendung von Pointern oder Referenzen im Source Code geht).

3. Eine Beschränkung ist auch der isolierte gdk.pixmap-Typ, der nicht mit gdk.pixbuf zusammenarbeiten kann, d.h. das Fehlen einer Funktion wie gdk.pixmap.create_from_pixbuf (und umgekehrt). Ein Typ, der eigentlich nur aus historischen und bei heutiger Performance nicht mehr sinnvollen Gründen (Server-Bitmaps in X11) vorhanden ist. Dass das obige gtk.gdk.pixmap_create_from_xpm mit Windows-Bitmaps überhaupt funktioniert, ist natürlich glücklich, aber auch nicht dokumentiert (und gilt vielleicht nicht für andere Betriebssysteme ohne xpm-Unterstützung).

4. Die rc-Syntax ist eindeutig und vollständig darzustellen,

5. die Bezeichnungen der Referenz sind zu erklären, nämlich vor allem, was der Block Style Attributes eigentlich darstellt Bei "Attributes" habe ich an Objekte gedacht - wieder so eine irreführende Benennung - dass es hier in irgendeiner Weise um rc's geht, war dadurch für mich völlig verdeckt. Typisch - leider, leider mögen die gtk-Entwickler Klassen- bzw. Objekt-Attribute nicht (und produzieren Seiteneffekte ohne Ende).

6. Hinweise auf engines, deren evt. eigene Style Attributes und deren multiplen Gebrauch durch rc-Files, also unbedingt Beispiel-rc-Files mit mehreren Engines. Etwas wie dieses

geht nur mit zwei engines. 90% der engines halten sich an die unannehmbaren Simpelst-Rechtecke für Tab-Reiter der Standard-Engines (das Beispiel ist xfce gemischt mit clearlooks für die Notebooks).

7. für den TreeView: Okay, um path und tree_iter kommt man sicherlich nicht herum. Für mich unfassbar ist die Vermischung von Layout und Inhalt (in einem derart MVC-geprägten Umfeld !!) durch

treeviewcolumn.add_attribute(cell_renderer, attribute, column)

Dies bedeutet für komplexere Layouts von TreeViews, dass man Spalten dessen Models (!) für das Layout-Verhalten von CellRenderers einrichten muss. Das fällt so völlig aus dem Bild, dass ich Stunden brauchte, um diese Denkblockade zu überwinden, und muss viel klarer dargestellt werden als in den offiziellen Tutorials. Die Doku müsste hier ganz klar sagen, dass das - an vielen Stellen sehr ernst genommene - MVC-Paradigma hier durchbrochen wird, worum sie sich auch hier wieder herumdrückt. So etwas ist auch deshalb in keiner Weise zu erwarten, weil die Rückgabetypen von gtk.gdk.color_parse und pango.FontDescription natürlich nicht in Zellen des gtk.ListStore passen - dies Konstrukt geht nur durch das Vorhandensein von - prinzipiell gesehen redundantem - Convenience Code.

Tja, im Moment kann ich vom gtk-Zug nicht herunter. Und ich bin schon auch dankbar. Aber wenn ich daran denke, dass Python nur durch seine Unicode-Error-Meldungen wirklich wehtut, Eclipse und sqlite nie, und an die vielen, vielen Stunden Schmerz durch gtk, dann wünsche ich allen viel Glück und viel, viel Erfolg, die durch gute Doku versuchen, anderen diese Schmerzen zu ersparen. Aber bitte - keine zehnte Kopie der Tutorials, sondern ran an die schwierigen Stellen. --3Jane 16:37, 10. Okt. 2009 (CEST)

Ich hab mal am Anfang und am Ende ein bisschen quergelesen. Warum tut man sich solche "unverbindlichen" GUI-Libs an, wenn man damit Geld verdienen muss/will? Mit "unverbindlich" meine ich, dass man keinen am Schlawittchen packen kann, wenns klemmt. Ich hab einiges mit Tcl/Tk gemacht, vieles mit PerlTk und mache heute sehr viel mit wxpython (ich liebe Python), aber nichts Komplexes für den Markt. Damit wäre ich nicht konkurrenzfähig. Ich bin mal gespannt, wie lange es z.B. dauern wird, bis die Python-GUI-Libs (oder andere) unter Python 3.x laufen. Jahre, mehrere, etliche. Das ist alles eben, ja, zu unverbindlich.

Wenn der Kunde knackige Windows-Software will, gibts C#/.NET, früher MFC, der Rest bekommt Java/Swing. Die Macken sind in der Zahl übersichtlich, Hilfe gibt es mannigfaltig. Ja, sorry, wenig hilfreich, aber sicherlich auch nicht der richtige Ort hier. Den Dampf sehen leider nicht die Richtigen. --84.131.132.17 22:49, 11. Okt. 2009 (CEST)

In VisualStudio habe ich mal in 6.2 gearbeitet, da waren Tabellen-Steuerelemente für Hunderte von Euro dazugekauft worden. Eins war für Tabellenkalkulation - unter VB funktionerte da etwa nur die Hälfte der Funktionen (und das vom Marktführer in der Hinsicht !). Nie wieder VS.

Gtk.TreeView geht zwar bei 20 Spalten und 1000-3000 Zeilen (je nach Hardware) ziemlich in die Knie - aber das ist mehr als nichts. Es ist aber so, dass moderne Grafikkarten richtig programmiert soviel mehr hergeben würden, bzw. Draw-on-Demand sogar unendlich viele Zeilen möglich macht (für lazy evaluation - dies "unendlich" ist natürlich von geringem praktischen Wert), dass diese höchstens paar Tausend Zeilen halt reichlich wenig sind. In meiner Software könnten Bedienungsfehler eine fünfstellige Zahl von Zeilen aus der Datenbank anfordern - ich habe nicht die geringste Lust, meine Programme damit zu befrachten, so etwas abzufangen, wo das doch - wie gesagt - leicht gehen sollte und diese Zeilen auch für Gigabit-Ethernet kein wirkliches Problem mehr darstellen.

Mir persönlich ist außerdem die Portabilität meiner Software wichtig und noch mehr: Ambulanz. Eclipse, die JRE, Python, gtk und gcc unter MinGW können ohne Administratorrechte zum Laufen gebracht werden (evt. muss man in einer lokalen Umgebung einen PATH setzen, dann geht das) - ich kann mit meinen Programmen nicht nur von externem Laufwerk im Internetcafé arbeiten, sondern sie dort sogar auch weiter entwickeln. Ich werde nichts, absolut nichts mit der Windows Registry machen. Und die Kunden können ihre Firma fast komplett mit in den Urlaub nehmen - auf Notebook oder in einer Konfiguration mit externer Festplatte wie meiner.

Und ich möchte nicht mit den gtk-Leuten streiten. Was oben kritisiert wird, sind ja vor allem Lücken in der Doku - damit, die gut zu machen, haben ja 95% aller Programmierer so ihre Probleme.--3Jane 21:50, 15. Okt. 2009 (CEST)