GUI Programmierung: Toolkit vergleich

[miketech]

Ach und noch etwas: Vielleicht sollte man auch mal die GUIs an sich betrachten:

Afaik bietet Qt mehr GUI-Elemente mit mehr Möglichkeiten. Und mit KDE steht noch mehr zur Verfügung.

Auch so Sachen, wie der File-Dialog: Der ist bei GTK ja wohl ziemlich arm. Der von Qt an sich ist auch nicht so super, stimmt, aber wenn man KDE nutzt und auf die KDE Bibliotheken zurückgreift ist da schon ein großer Unterschied. Und auch vom Style her finde ich Qt wesentlich schicker, zumal es auch viel mehr brauchbare Styles gibt. Bei GTK schaut immer alles etwas unschön aus, oft grau in grau. Das ist auch der Grund, weshalb ich immer KDE benutze und kein Gnome. Weil mir der Gnome-Desktop einfach zu braun/grau und trübe aussieht.

Ich habe hier mehrere GTK-Programme und schon viele verschiedene Styles ausprobiert und nur wenige Styles gefallen mir. Teilweise kamen mir die GUIs auch langsamer vor, als bei Qt. Qt kommt mir also nicht nur schöner, sondern auch schneller vor und mit Qt4 soll sich an der Performance nochmal einiges tun.

Bei Qt tut sich also eine ganze Menge, während ich immer das Gefühl habe, dass bei GTK die Entwicklung ziemlich hängt. Wie lange mussten die Leute auf einen etwas verbesserten File-Dialog warten und der neue ist nun nicht der Renner. Für mich macht es den Eindruck, als ob sich an der GUI von GTK nicht mehr viel ändert.

Das mag jetzt sehr stark nach Flame aussehen, aber das ist genau meine Meinung von GTK, die ich eben hier mal auf den Punkt bringe

Gruß

Mike

 

[pinky]

Ich bin derzeit dabei mich etwas in Ruby einzuarbeiten. Hier bietet mir Ruby alles, was ich brauche. Sockets, Threads usw. Es gibt auch Qt-Bindings für Ruby, allerdings war ich hier dann zum ersten mal etwas unentschlossen, ob ich nun die Qt-Sockets nehme, oder die Sockets von Ruby. Selbiges eben bei Threads. Ich habe also zwei Implementierungen für den selben Zweck, da mir das Toolkit mehr mitbringt, als ich benötige.

imho sollte man immer die implementierung der Programmiersprache nutzen, wenn sie es anbietet. Damit bist du einfach näher am Standard dran, Ruby Programmierer (auch die die mit Qt und GUI nichts am Hut haben) können deinen Code verstehen, ihn nutzen oder dir einfach helfen.

Wenn es bei der Sprache die libs nicht gibt, dann muß man eben immer abwegen.
Wenn es z.B. bei C++ eine saubere und Plattformunabhängige lib gibt die weit verbreitet ist, dann würde ich sie der Qt implementierung vorziehen, einfach um sauber Daten/GUI trennen zu können. Wenn das nicht geht spricht auch nichts dagegen wenn du die Qt Implementierung nimmst oder bei Gtk-C das was du in der glib findest. Aber imho sollte an erster Stelle immer das Toolkit unabhängige stehen was der Standardsprache am nächsten ist.

/* Auf der gtk.org - Seite gibt es bei der API-Reference noch Dokumentation zu glib. Was ist das? glib bietet auch wieder Funktionen, wie threads. */

ja, bei Gtk gibt es zum Teil auch Erweiterungen, ich habe ja auch nicht gesagt, dass prinzipiell alle Erweiterungen schlecht sind.
Der Unterschied ist für mich, dass bei Qt C++ immer weiter aufgeblasen wird und jemand der täglich mit Qt programmiert wohl die einen oder anderen "Kommunikationsprobleme" mit C++ Programmierern bekommt, da sich in meinen Augen Qt immer mehr zu einer eigenen Programmiersprache entwickelt.
Bei Gtk hat man natürlich C auch an der eine oder anderen Stelle etwas "aufgebohrt", wo es nötig war, aber danach hat man saubere Anbindungen an verschiedene Programmiersprachen und jeder kann sich die Programmiersprache aussuchen die am besten zu seiner Aufgabe passt.

In den letzten Tagen habe ich auch noch ein schönes Beispiel gefunden, ich habe mir mal die Qt# bindings angesehen:

Ich muß sagen ich bin ehrlich gesagt etwas erschrocken, wenn man sich nur den Programmcode ansieht (also nicht das drum herum (klassen definition, using,...)) könnte man meinen man schaut sich ein C++ Programm an, also eigentlich das was du den Gtk bindings vorgeworfen hast (lieblos ohne Anpassung auf die Sprache aufgesetzt).
C# bietet eine einfachen Mechanismus um Signale zu verbinden und auch Datei Operationen die mind. so einfach sind wie die von Qt. Aber sobald ich unter C# mit Qt anfange werden QFiles verwendet, Signale werden mit dem gleichen Synatx wie unter C++ verbunden,...
Gtk# hat sich dagegen schön in C# eingebunden und passt sich dem Syntax an und verwendet das was C# einem schon bietet.
Das verstärkt nur wieder meine These: Qt hat sich zu einer eigenen Programmiersprache entwickelt die man über C++ drüber gestülpt hat und z.B. bei den C# Bindings über C# drüber stülpt. Man programmiert aber kaum noch C++ oder C# sondern jedesmal Qt.
GTK ist dagegen ein sauberes Toolkit das man mit vielen Programmiersprachen nutzen kann und das sich immer der Programmiersprache anpasst.

Zu deinem zweiten Beitrag:
Das dir der gnome filedialog nicht gefällt macht das Toolkit weder schlecht noch gut.
Das sind alles rein subjektive Empfindungen, ein gnome/gtk Anwender würde genau das gleiche schreiben nur umgekehrt und beidesmal wäre es genauso falsch wie richtig und würde beidesmal genauso viel/wenig über die Qualität des Toolkits aussagen.

EDIT: Ich habe mir gerade mal Qt-Ruby angesehen, was ich zumindest positiv finde ist, dass man es da endlich mal gschafft hat Qt einen eigenen namespace zu geben. Das wäre imho auch mal bei C++ angebracht.

 

[miketech]

Naja, aber was nützt es mir, wenn ein Toolkit zwar vom Modell her besser aufgebaut zu sein scheint, aber von den Leistungen nicht den Erwartungen entspricht? Das ist wie mit tcl/tk. Das wird auch immer seltener eingesetzt, weils den optischen Erwartungen nicht mehr gerecht wird. Sicherlich kann man darüber streiten, ob GTK nun schön oder hässlich ist. Aber, dass die Entwicklung sehr langsam von statten geht und dass es sowohl optisch, als auch von der Leistung Qt hinterherhinkt ist für mich ziemlich sicher. Meine GTK-Anwendungen sind von der GUI her alle viel träger, als z.B. Qt-GUIs. Und wenn ich schon eine Anwendung mit GUI schreibe, dann mach ich das, weils auch schick aussehen und schön und schnell zu bedienen sein soll.

Und zu den Styles: Ich habe 2 Styles, die mir bei GTK recht gut gefallen. Allerdings sind diese, wie gesagt etwas langsam. Dazu kommt, dass ich z.B. bei KDE Styles habe und dann noch die Farben einstellen kann. Bei GTK bestimmt der Style die Farbe. Mir fehlt da Flexibilität, was mir eben den Eindruck gibt, dass GTK hinter Qt herhinkt. Selbiges bei Gnome: Bei KDE sehe ich bei einem neuen Release, was sich getan hat. Bei Gnome scheint alles sehr träge zu sein, da finde ich fast keinen Unterschied zwischen Gnome 2.4 und 2.8. Aber das ist auch wieder subjektiv und gehört nun nicht hierher.

Kennst Du denn C++ Libraries für Socketprogrammierung? Also Libraries, die plattformunabhängig sind?

Also QtRuby gefällt mir soweit recht gut. Allerdings hatte ich am Anfang ähnlichen Effekt, wie Du bei C#. Mein erstes QtRuby Programm sah aus wie selbiges in C++ mit ein paar Änderungen. Aber was sollte man auch groß ändern. Die GTKRuby Programme sehen auch aus wie die GTK Programme mit C++, weils eben dieselben Klassen sind. Ich weiß nicht, wie es bei Dir bei C# aussah, damit es C++ ähnlicher ist, als GTKRuby, oder QtRuby.

Gruß

Mike

 

[pinky]

Naja, aber was nützt es mir, wenn ein Toolkit zwar vom Modell her besser aufgebaut zu sein scheint, aber von den Leistungen nicht den Erwartungen entspricht?

Was sind deine Erwartungen an ein GUI Toolkit? Ich erwarte, dass es mir alles in die Hand gibt um einfach und schnell GUIs zu erstellen. Ich würde sagen da fehlt weder bei Qt noch bei Gtk etwas.
Man könnte die Erwartung etwas erweitern: Weiter sollte es möglichst unabhängig von der Programmiersprach sein. So das ich, wie bei Konsolenprogrammen, die Programmiersprache je nach Aufgabe wählen kann und immer in der Lage bin eine GUI drauf auf zu setzen.
Mit der Erweiterung würde ich sagen geht ein ganz klares Plus an Gtk+

Sicherlich kann man darüber streiten, ob GTK nun schön oder hässlich ist. Aber, dass die Entwicklung sehr langsam von statten geht

was verstehst du unter langsam?
Gtk entwickelt sich mind. so schnell wie Qt und wenn du bei Qt mal die "C++ Verbesserungen" weg lässt, dann tut sich bei den neuen Qt releases auch nicht mehr als bei den Gtk releases. Wobei ich nicht sagen will das es wenig ist was sich da tut.
Aber wenn wir schon auf Oberflächlichkeiten herum reiten, auch wenn ich das für falsch halte, gibt es z.B. bei Gtk schon ewig sogenannte stock-icons. D.h. wenn ich einen save, load, print, add, remove,... (halt lauter Standard sachen) Button anlege, dann bekommen sie bei Gtk ein schönes icon das sich auch dem Style anpasst und um die Übersetzung muß ich mich dann auch nichtmehr kümmern.
Bei Qt gibt es keine einheitliche Lösungs für Standardbutton mit icons+Text und Übersetzung.

Meine GTK-Anwendungen sind von der GUI her alle viel träger, als z.B. Qt-GUIs. Und wenn ich schon eine Anwendung mit GUI schreibe, dann mach ich das, weils auch schick aussehen und schön und schnell zu bedienen sein soll.

Bei mir sind Gtk und Qt Programme gleich träge bzw. flink.
Was das aussehen angeht, mal eine kleine Beobachtung von mir:
Wenn ich KDE benutze kommen mir Gtk Programme auch immer hässlich vor, benutze ich gnome oder xfce kommen mit Qt Programme hässlich vor. Ich denke das henkt zu einem großen Teil auch am Gesamtbild und das du als KDE benutzer dann Gtk als häßlich empfindest ist nicht verwunderlich. Trotzdem oder gerade deswegen ist es aber sehr subjektiv und sagt nichts über die Qualität des jeweiligen Toolkit aus.

Und zu den Styles: Ich habe 2 Styles, die mir bei GTK recht gut gefallen. Allerdings sind diese, wie gesagt etwas langsam.

das sind 2 mehr als ich bei Qt habe
Im ernst, von den Qt styles gefällt mir garkeins, bei KDE finde ich plastik ganz in Ordnung, mit dem rest kann ich nichts anfangen.
Aber auch wenn ich mich wiederhole, wir driften auf Oberflächlichkeiten ab.

Selbiges bei Gnome: Bei KDE sehe ich bei einem neuen Release, was sich getan hat. Bei Gnome scheint alles sehr träge zu sein, da finde ich fast keinen Unterschied zwischen Gnome 2.4 und 2.8. Aber das ist auch wieder subjektiv und gehört nun nicht hierher.

Ja, bei KDE werden die Menus immer voller, bunter und unübersichtlicher. Ich finde 90% der Fälle die Gtk/gnome Programme schöner, aufgeräumter und funktionieller.
Aber du hast vollkommen recht, dass gehört absolut nicht hier her.

Ich weiß nicht, wie es bei Dir bei C# aussah, damit es C++ ähnlicher ist, als GTKRuby, oder QtRuby.

wenn z.B. Signal/Slots so verbunden werden wie du es von C++ kennst, obwohl C# seine eigenen (in meinen Augen sehr guten) Routinen dafür hat. Gtk# verwendet da die C# EventHandler, was u.a. dafür sorgt das sich gtk# sauber in C# eingliedert und sich für einen C# Programmierer bekannt anfühlt (da er bei allen anderen Programmen ja auch mit den C# EventHandlern arbeitet).
Das ist eben das was ich meine, eine ganz klare Aufgabe: GUI Toolkit. Und dann wird es in jeder Programmiersprache mit ihren typischen Mitteln eingebunden. Dadurch kann jeder Programmierer, egal ob C, C++, C#, Ruby, Perl, lisp,... auf seine gewohnte Programmierart eine GUI für sein Programm erstellen.

 

[miketech]

Hi,

ok da hast Du natürlich recht. Dadurch, dass ich KDE verwende, passen GTK GUIs nie optisch zum Rest.

Also ich habe mir eben nochmal GTKRuby etwas angeschaut. Bisher habe ich überwiegend mit der Namensgebung von GTK-Funktionen Probleme gehabt, wie in einem meiner früheren Beiträge erwähnt. GTKRuby unterscheidet sich vom Handling her jedoch sehr wenig von QtRuby. Was mich jedoch immer noch stört: Klassen sind bei gtkmm so geschrieben: DiesIstEineKlasse. Methoden hingegehen: dies_ist_eine_methode. Das widerstrebt mir etwas, da es nicht die Namensgebung ist, die ich wähle. Ja, die Argumente werden langsam etwas dünn, aber ich recherchiere weiter

GTK ist ja eigentlich C, während gtkmm den objektorientierten Ansatz verfolgt, korrekt? Ich komm da etwas durcheinander, wo ich jetzt GTKRuby sehe. Ruby ist ja sehr stark objektorientiert. Müsste das dann nicht gtkmmruby sein? Oder ist gtkmm lediglich die objektorientierte Erweiterung für C++? Und Ruby macht da was eigenes für sich?


Wie schauts eigentlich mit wxWidgets aus? wxWidgets verwendet unter Linux GTK und unter Windows die Windows Libs. Damit schon Erfahrungen gemacht? Ich habs mal versucht, jedoch hat es mir wenig gefallen. Ich kam damit einfach nicht klar, weils mich nicht wirklich angesprochen hat und eine Sprache, oder ein Toolkit muss mich faszinieren, oder irgendwie reizen, damit ich mich privat damit beschäftige. wxWidgets ist objektorientierter, als das einfache gtk, daher hatte ich darauf einen Blick geworfen, weil ich gtkmm nicht kannte. Aber da GTK auch unter Windows läuft, sehe ich nicht die Vorteile von wxWidgets. Zeichnet GTK unter Windows selbst? Oder werden hier die Windows Libs genutzt? Läuft GTK unter Windows denn stabil? Hab da oft nichts positives gehört.

Ich denke ich werde die nächsten Tage, um mich weiter in Ruby einzuarbeiten mal einen Blick auf gtkruby werfen. Da hier ja ausschließlich die GUI-Klassen enthalten sind, kann ich weiterhin mit den Ruby-eigenen Funktionen spielen und gleichzeitig mit GTK mal etwas rumprobieren. Mal schauen, was ich nach ein paar Wochen GTK sage. Ich denke, es ist auch immer etwas Einarbeitung nötig, um ganz gezielt die Vorteile zu erkennen. Da ich mit GTK fast nie was zu tun habe, fehlt mir dies. Ich habe von Anfang an auf KDE gesetzt, nur kurze Zeit mit Gnome verbracht.

Dagegen, dass ein GUI - Toolkit ausschließlich GUI - Funktionalität bieten sollte, sage ich schon gar nichts mehr. Sobald man GUI und Daten voneinander trennt hat man bei Qt sicherlich Probleme, was die Abhängigkeiten angeht. Da hier schnell so Kleinigkeiten, wie String (STL) und QString (Qt) durcheinander geraten.

Allerdings sehe ich, wie schon gesagt noch den Vorteil von Qt, dass ich nur eine einzige Abhängigkeit habe und kein Baukastenprinzip.

Mike

 

[pinky]

Was mich jedoch immer noch stört: Klassen sind bei gtkmm so geschrieben: DiesIstEineKlasse. Methoden hingegehen: dies_ist_eine_methode. Das widerstrebt mir etwas, da es nicht die Namensgebung ist, die ich wähle.

ja, da hat jeder seinen eigenen Stil. Programmiersprachen und auch Toolkits sind halt auch immer etwas sehr individuelles dem einen liegt das eine und dem anderen das andere.
Ich persönlich finde die Unterstriche auch nicht so toll, aber die gtkmm Hacker scheinen es eben anders zu sehen, gtk# hat z.B. diese Unterstriche nicht und kommt mir zur Zeit sowieso am meisten bei der GUI Programmierung entgegen (auch wenn es die unseglichen .exe und .dll Endungen in die GNU Welt einführt).

GTK ist ja eigentlich C, während gtkmm den objektorientierten Ansatz verfolgt, korrekt?

zur hälfte
GTK ist in C geschrieben, soweit richtig. Aber gtkmm ist nicht der "objektorientierten Ansatz" sondern die C++ Bindings für gtk+. gtkmm macht also nicht mehr als das es dir ermöglich Gtk+ in C++ auf die C++ typische Art zu verwenden.
Objektorientiert ist Gtk+ immer, auch unter C! Objektorientiert ist eine generelle Art zu programmieren und unabhängig von einer Programmiersprache.
Wobei es natürlich Programmiersprachen gibt die es begünstigen und Programmiersprachen wo man eher "tricksen" muß bzw. wo es vielleicht auch besser ist wenn man es garnicht erst versucht.
Ich würde z.B. nie versuchen in Gtk+ (also in C) eine eigene widget Klasse zu erstellen oder sogar von einer bestehenden abzuleiten. Das ist mir dann doch zu heftig, diese Basisarbeit überlasse ich gerne den Gtk+ Hackern und bediene mich dann an den "einfachen" Bindings für höhere Sprachen.

Ich komm da etwas durcheinander, wo ich jetzt GTKRuby sehe. Ruby ist ja sehr stark objektorientiert. Müsste das dann nicht gtkmmruby sein? Oder ist gtkmm lediglich die objektorientierte Erweiterung für C++? Und Ruby macht da was eigenes für sich?

Die Bindings entstehen immer aus GTK+, d.h. aus dem C Toolkit.
Also egal ob Gtkmm, GTKRuby, gtk#, PyGtk, CL-Gtk,... die Basis ist immer GTK+

Wie schauts eigentlich mit wxWidgets aus? wxWidgets verwendet unter Linux GTK und unter Windows die Windows Libs. Damit schon Erfahrungen gemacht? Ich habs mal versucht, jedoch hat es mir wenig gefallen. Ich kam damit einfach nicht klar, weils mich nicht wirklich angesprochen hat und eine Sprache, oder ein Toolkit muss mich faszinieren, oder irgendwie reizen, damit ich mich privat damit beschäftige.

Ich selber habe nie mit wxwidgets gearbeitet.
wxwidget ist vielleicht leichter zu portieren, da es unter windows die windows GUI verwendet.
Auf der anderen Seite verwendet wxwidget unter GNU/Linux zwar Gtk um die GUI zu zeichnen, es ist aber nicht Gtk. Das merkt man daran, dass z.B. die Treeview oder Toolbar anders aussieht als bei Gtk anwendungen und auch ansonsten erkennt man einfach am Aufbau das es nicht wirklich Gtk ist. Dazu kommt dann natürlich auch, dass man es z.B. nie wirklich in gnome integrieren kann und gnome-libs verwenden kann und Styles haben auch so ihre Probleme mit verschiedenen Elementen von wxwidget.
Alles in allem also etwas das für crossplattform Sachen sicher nicht schlecht ist, aber für GNU/Linux bzw. gnome/gtk auch alles andere als optimal ist. Daher war es für mich nie wirklich interessant.

Zeichnet GTK unter Windows selbst? Oder werden hier die Windows Libs genutzt? Läuft GTK unter Windows denn stabil? Hab da oft nichts positives gehört.

gute Frage. Also ich habe es nie selber unter windows versucht.
Was ich weiß:
Lange Zeit haben Gtk Anwendungen auch unter windows den default gtk style verwendet, haben also etwas fremd ausgesehen. Seit gtk2.4 übernimmt gtk aber relativ gut die windows styles (afaik ab win2000) und in gtk2.6 wurde es afaik weiter verbessert.
Alles in allem sollte es kein Problem sein gtk unter windows zu nutzen, es gibt ja auch kommerzielle Firmen die gtk für windows verwenden.

Allerdings sehe ich, wie schon gesagt noch den Vorteil von Qt, dass ich nur eine einzige Abhängigkeit habe und kein Baukastenprinzip.

sicher hat es auch seine Vorteile, wollte ich auch nie bestreiten.
Mich stört nur, dass Qt auch da Eigenwege geht, wo es eigentlich nicht nötig gewesen wäre und wo man sich einfach besser an der Programmiersprache ihrer Wahl (C++) halten hätten können bzw. sollen.

 

[miketech]

Hi,

GTK ist in C geschrieben, soweit richtig. Aber gtkmm ist nicht der "objektorientierten Ansatz" sondern die C++ Bindings für gtk+. gtkmm macht also nicht mehr als das es dir ermöglich Gtk+ in C++ auf die C++ typische Art zu verwenden.

Ok danke.


Mal aus persönlichem Interesse: Bist Du Gnome-User? Oder XFCE oder so?


MySQL setzt ja z.B. auch auf GTK, was die Anwendungen mit GUIs betrifft. Wobei ich eher glaube, dass hier versucht wird auf Lizenzkosten von Qt zu verzichten, die ja nun nicht so günstig sind.

Ich werde mich mal erkundigen, wie GTK-Programme unter Windows laufen. Gimp läuft ja wohl, aber ich habe wie gesagt von schon so einigen crashes gehört.

Gruß

Mike

 

[cocaxx]

Hi!

Das größte Problem mit gtk unter Windows ist, dass die user zu dumm sind, gtk zu installieren. Drauf ist es nämlich nicht und sie sind es auch nicht gewohnt, irgendwelche Abhängigkeiten selber zu installieren.
Da ist es bequemer, sie ziehen sich Photoshop per KaZaa und cracken es, das sind sie gewohnt....


grüße
cocaxx

 

[miketech]

Der war böse )

Mike

 

[manthano]

Aber wahr. Ist wirklich so, alle Windows-User die ich kenne sind zu faul ein bisschen Software zu installieren oder mal selbst ein Problem in die Hand zu nehmen, denken aber sie wären besonders genial wenn sie sich kommerzielle Programme illegal runterladen.

 

[Sir Auron]

Hi!

Das größte Problem mit gtk unter Windows ist, dass die user zu dumm sind, gtk zu installieren. Drauf ist es nämlich nicht und sie sind es auch nicht gewohnt, irgendwelche Abhängigkeiten selber zu installieren.
Da ist es bequemer, sie ziehen sich Photoshop per KaZaa und cracken es, das sind sie gewohnt....


grüße
cocaxx

Tja dann hat man zwar das minderwertigere Programm, aber es geht ja schnell .

Nee mal im Ernst GTK auf Windows wird echt wenig benutzt (außer static bilds). Schade.

 

[miketech]

Hi,

naja aber Qt-Programme seh ich dort auch sehr selten. Die meisten kommerziellen Programme werden ja noch ausschließlich für Windows entwickelt. Da tuns dann auch die Windows Libraries. D.h. da wird dann mit MFC oder wie das alles heißt rumgefriemelt, bis es schließlich mal läuft *scnr*

Mike

 

[pinky]

Mal aus persönlichem Interesse: Bist Du Gnome-User? Oder XFCE oder so?

ich lasse mich da ungern in Kategorien drängen. Auf dem Desktop verwende ich hauptsächlich gnome, habe aber auch kde installiert und verwende auch das ab und zu. Auf dem Notebook verwende ich zur Zeit xfce, da es die richtige Mischung zwischen klein und konfortabel hat. Habe aber auch schon fluxbox, windowmaker und ähnliches verwendet und es ist auch nicht ausgeschlossen das ich das mal wieder verwenden.
Ich lege mich da nur ungerne fest, warum auch...
Aber alles in allem bin ich schon eher auf der gtk/gnome Schiene, sind für mich einfach oft die besseren Programme.

Nee mal im Ernst GTK auf Windows wird echt wenig benutzt (außer static bilds). Schade.

Naja, ein aktuelles Beispiel wäre http://www.multidmedia.com/ die ihre komplette windows Software mit Gtk erstellen, wobei sie gerade negativ auffallen weil sie wahrscheinlich die GPL verletzen, da sie die gnome-stock-icons verwenden.

Ansonmsten gibt es hier ja auch noch ein paar, die Listen sind aber sicher alles andere als vollständig:
http://www.gtkmm.org/commercial_support.shtml
http://www.gtk.org/success/

Ich denke da gibt es auf jedenfall keinen großen Unterschied zu Qt.

 

[miketech]

Hi,

ok ein Allround-User. Ich muss mich immer erst auf ein Desktop-System einarbeiten, damit all meine Anwendungen genau so sind, wie ichs möchte und alles so ausschaut und sich anfühlt, damit ich mich wohl fühle. Derzeit grad am Gnome rumprobieren. Da muss ich der Fairness halber noch zugeben, dass es im Moment gar nicht so schlecht aussieht. Nur mit den Icons kämpfe ich noch etwas. Die sind alle braun und wenn ich andere installiere, werden nie alle Icons mit abgedeckt. Gibt immer wieder welche, die noch braun/grau sind. Sobald XFCE in der Version 4.2 erschienen ist, was ja bald der Fall sein dürfte, werde ich damit weitertesten. XFCE 4 unterstützt bisher bei mir kein Xinerama. Ich hab hier zwei Bildschirme gleichzeitig laufen und XFCE läuft nur auf einem, obwohl auf der XFCE Seite steht:

Xfce 4 features and components
Real multiscreen and Xinerama support.

Vielleicht bezieht sich das erst auf Version 4.2, mal schauen.


Programmiert hier eigentlich auch jemand mit TCL/Tk? Oder anderen Toolkits wie FOX, oder was es alles so gibt? Bis jetzt wurden hier ja nur die größten, GTK und Qt angesprochen.

Gruß

Mike

 

[hehejo]

Ich hab in letzer Zeit wieder etwas Lust auf Python bekommen.
Darum hatte ich mich auch mal an wxPython (http://www.wxpython.org/ (Pythonbindings für wxWidgets) rangemacht.
Das finde ich im Moment recht einfach zum programmieren - aber sicherlich werde ich mir auch mal pygtk (www.pygtk.org) ansehen.
Falls sich pyGtk so schön wie das wxPython anfühlt - ok ich hab bisher nur sehr kurz "gefühl" - dann ist klar gtk mein Favourit!

@gtk auf Windows:
Ich hab hier gimp 2.0 installiert.
Auf der entsprechenden Seite waren auch noch die Downloads für GTK_for_Windows. Einfach installiert und *tattaa*.


@Bindings für verschiedene Sprachen
Wie macht man denn sowas???

 

[miketech]

Hi,

rein Interesse halber: Hat jemand mal Erfahrungen mit Python + Qt gemacht? Ich höre oft nur Python in Verbindung mit Gtk. Davon schwärmen doch einige. Nicht, dass ich vorhätte mich damit zu beschäftigen, nur hör ich davon sehr wenig.

Wenn auf Windows Gtk installiert, kann man dann einfach die PyGtk - Programme ausführen? Oder gibts da noch mehr zu tun, bis sowas läuft?

Zu den Sprachbindings: Das würde mich auch mal sehr interessieren. Wie geht man da vor?

Gruß

Mike

 

[hehejo]

Ich glaube, es muss auch noch pygtk installiert werden.

edit: DANKE

 

[hehejo]

So. ich hab mich etz ein bisschen mit GTK+ (also pyGTK) beschäftigt!
Ich bin restlos begeistert! Das Grafikzeugs geht einem echt einfach von der Hand. Hat man einmal das Grundprinzip verstanden dann rockt die Bude!
Wenn ich da an die MFC denke, wird mir richtig schlecht!
Ob ich nun gtkmm oder pygtk verwende.. EGAL. Die Logik dahiner ist gleich!

GTK!!