Archiv verlassen und diese Seite im Standarddesign anzeigen : GNOME (gtk+/gtkmm) vs. KDE (kdelibs/qt)
Moin,
ich möchte mich gerne mal mit der Programmierung unter Linux beschäftigen.
Habe sogar ein Buch über KDE/QT-Entwicklung gelesen und fand es für Änfänger nicht so sehr schwierig, dort Fuß zu fassen. Man schreibt in C++ und kann Objekte usw. schön kurz ansprechen.
Mittlerweile läuft bei mir Fedora Core 2.B und nun möchte ich mich auch mal mit GNOME auseinandersetzen, da der Desktop seit meines letzten Ausfluges in die Linuxwelt schöner geworden ist.
Habe mir auch schon mal den Thread Vergleich GTK <-> QT (http://www.mrunix.de/forums/showthread.php?t=32691&highlight=gtk) durchgelesen. Doch dort fehlen mir die Aussagen über die Desktops.
Und da man eben unter GNOME mit gtkmm auch C++ benutzen kann, eine Sprache, die ich lieber nehmen würde als C, und mittels libsigc++ auch Slots/Signals wie in QT benutzen kann (was ich für innovativ hielt), hätte ich gerne mal einen Rat:
Unter welchem Desktop (GNOME / KDE) macht das Programmieren mehr Spass?
Auch als Anfänger möchte ich alle Optionen offen haben, und suche eben nach der Bibliothek, die mir mehr gibt. Und das vielleicht auch leichter, ressourcenschonender und zukunftsträchtiger.
undefined
11-09-2004, 14:52
Obwohl für mich viele Anwenndungen wie gimp avidemux sane unentbehrlich sind bevorzuge ich persönlich kde/qt Entwicklung mit Kdevelop.
Ich habe mich aber auch noch nicht mit anjuta beschäftigt weil es immer die neuste Gnome haben möchte und ich keine Lust habe Tage lang Gnome upzudaten ;)
Sorry
Zu Anfang hatte ich nichts über die Forumssuche gefunden. Daher habe ich mich hier registriert und gepostet. Nun habe ich aber durch Stöbern einige Threads gefunden, die meine Frage diskutierten.
Werde wohl eher zu wxWindows greifen. Mit Gtk wollte ich sowieso nicht arbeiten, da ich objektorientiert schreiben wollte. Daher kann ich mir doch gleich wxWindows ansehen, denn das ist erstens plattformunabhängig und zweitens unter GNOME sowieso Gtk.
Obwohl die Tutorials eigentlich nur aus denen des Projektes bestehen. Und ich auch sonst keine deutschen Quellen fand, denke ich trotzdem, dass dies Projekt Zukunft hat, sonst würde es nicht schon seit 1992 bestehen.
Bin aber trotzdem für jeden Tipp dankbar!!!
peschmae
12-09-2004, 08:59
Gtk ist auch objektorientiert. Wenn auch imo auf eine ein bisschen "schräge" Art und Weise. Hab mich aber nie sehr ausführlich damit befasst.
MfG Peschmä
cybercrow
12-09-2004, 11:40
Gtk ist auch objektorientiert. Wenn auch imo auf eine ein bisschen "schräge" Art und Weise. Hab mich aber nie sehr ausführlich damit befasst.
Das "schräg" muß man aber genauer definieren.
GTK+ ist Objektorientiert. Natürlich ist es etwas "ungewohnt" wenn man das in C macht und ein neues widget "ableiten" will.
Wenn man gtkmm verwendet ist da aber kein wirklicher Unterschied zu Qt.
Der Unterschied ist, dass gtkmm sich mehr auf an "Standard-C++" hält, d.h. alles mit C++ Mitteln macht. Ob das jetzt besser oder schlechter ist sei mal dahingestellt. Ich fand z.B. immer die C++ Art über Container zu iterrieren irgendwie kompliziert. Wenn man wirklich C++ Programmierer ist kommt einem aber gtkmmm vielleicht entgegen.
Insgesamt denke ich das Qt den deutlich geringeren Lernaufwand bietet, da man sich nicht strikt an C++ hält und auch dort wo es angebracht ist vereinfachte konstrukte verwendet. Dazu kommt natürlich die sehr gute Dokumentation.
Bei gtkmm ist der Lernaufwand größer. Dafür sieht es insgesammt mehr wie Standard-C++ aus und wenn man mal beides gelernt hat ist es wahrscheinlich ziemlich egal ob Qt oder gtkmm.
Von wxwidget halte ich nicht viel und habe auch eher negatives darüber gehört. Schon alleine die Art Ereignisse zu verknüpfen mit diesen Eventtable (ähnlich wie bei der win api), da finde ich das signal/slot Konzept viel besser. Dazu kommt das es afaik keinen GUI Builder für wxwidgets gibt und wer will schon eine größere GUI von Hand erstellen?
Ich meine gelesen zu haben, dass man für wxWindows auch Glade benutzen kann. Aber das mit der Eventtable und den Slots/Signals ist schon ne Sache. Die ist mir nicht so aufgefallen.
Und die Slots/Signals finde ich eigentlich sehr schön. Kommt man denn mit GTKmm gut zurecht?
peschmae
12-09-2004, 13:11
Hier wird gtkmm versenkt (http://www.telegraph-road.org/writings/gtkmm_vs_qt.html)
Ein Hauptnachteil von Gtk ist imo die schlechere Portabilität im Vergleich zu Qt und WxWidgets.
Zu WxWidgets gibts Gui-Editoren: http://boa-constructor.sourceforge.net http://wxglade.sourceforge.net
MfG Peschmä
Von wxwidget halte ich nicht viel und habe auch eher negatives darüber gehört. Schon alleine die Art Ereignisse zu verknüpfen mit diesen Eventtable (ähnlich wie bei der win api), da finde ich das signal/slot Konzept viel besser.
Kleine Korrektur: Das System mit dem Eventtable kommt afaik von der MFC (Aber das haengt ja auch mit der WinAPI zusammen...). Die WinAPI selbst setzt ja auf WindowProc mit einer grossen switch/case Anweisung.
Das mit dem Eventtable ist wirklich nicht so schoen.
wxWidgets:
BEGIN_EVENT_TABLE(MyFrame, wxFrame)
EVT_MENU(ID_Quit, MyFrame::OnQuit)
EVT_MENU(ID_About, MyFrame::OnAbout)
END_EVENT_TABLE()
Zum Vergleich die MFC:
BEGIN_MSG_MAP(CMcbWindow)
MESSAGE_HANDLER(WM_PAINT,OnPaint)
MESSAGE_HANDLER(WM_CREATE,OnCreate)
MESSAGE_HANDLER(WM_DESTROY,OnDestroy)
END_MSG_MAP()
Das Fox Toolkit (http://www.fox-toolkit.org/), was auch einige Anhaenger hat, funktioniert anscheinend aehnlich.
Das Problem liegt hier aber meiner Erfahrung nach weniger an den Toolkits. Sie wuerden es schon anders machen, wenn es ginge. Aber richtig einfaches Event-Handling ist in C++ schwierig zu realisieren. Ihr koennt euch ja mal Gedanken machen und probieren das umzusetzen.
Sowas geht halt in C++ nicht:
button.onClick = meineMethode;
Waere aber IMHO das lesbarste... (sowas geht z.B. in Delphi und anderen Sprachen wie Python)
Nun bin ich zum Ergebnis gekommen, dass es nur zwei Wege gibt Event-Handling (ohne Callbacks und/oder sehr vielen Makros) in C++ zu realisieren:
- Ueber etwas Zusatzsyntax und einen Precompiler, so wie es Qt mit moc macht.
- Ueber Templates so wie es bei libsigc++ (und damit gtkmm) oder in der STL (for_each -> mem_fun, etc...) gemacht wird.
Dass es syntaktisch anders ginge zeigt z.B. Delphi: Dort kann man Zeiger auf Methoden definieren, bei denen der Typ des Objekts nicht bekannt sein muss. (procedure of object) In C++ geht das halt nicht so ohne weiteres...
ciao
chrizel
peschmae
12-09-2004, 14:47
A propos Fox, deren FAQ hat eine Übersicht über die Möglichen Event-Verarbeitungsmodelle (Signal-Slot, Funktionspointer, etc): http://www.fox-toolkit.org/faq.html#CALLBACKS
Natürlich ist das Fazit Eventtables seien am Besten, aber das muss man ja nicht glauben ;)
MfG Peschmä
cybercrow
12-09-2004, 15:15
Hier wird gtkmm versenkt (http://www.telegraph-road.org/writings/gtkmm_vs_qt.html)
wobei diese "versenkung" ziemlich alt ist (der Autor kennt gtkmm afaik nur von Version 1.x) und lässt sich auf die neuen Versionen von gtkmm kaum noch übertragen, da hat sich eine Menge getan.
@Kilton: Schau dir doch einfach mal die gtkmm Doku an[1], vorallem das Handbuch[2] und entscheide dann ob es was für dich ist oder nicht.
[1] http://www.gtkmm.org/docs/gtkmm-2.4/docs/
[2] http://www.gtkmm.org/docs/gtkmm-2.4/docs/tutorial/html/index.html
Zu WxWidgets gibts Gui-Editoren: http://boa-constructor.sourceforge.net http://wxglade.sourceforge.net
folgende sind zwar nicht frei erhältlich, aber meiner meinung am weitesten entwickelt:
http://www.anthemion.co.uk/dialogblocks/
http://www.roebling.de/
Danke @cybercrow
Ist denn die Dokumentation bei gtkmm besser als die bei wxwindows?
Brauche nämlich sicher erstmal gute Tuts.
wxWindows lasse ich wohl doch, ist mir nicht so geheuer. Lese darüber so wenig, gibt auch kaum Tuts, obwohl schon so alt.
anda_skoa
13-09-2004, 00:50
Sowas geht halt in C++ nicht:
button.onClick = meineMethode;
Waere aber IMHO das lesbarste... (sowas geht z.B. in Delphi und anderen Sprachen wie Python)
Limitiert einen dann aber auch auf einen Handler pro Event.
Bei Signals&Slots ist es schon ziemlich praktisch, dass man da beliebig viele Verbindungen machen kann.
Dass es syntaktisch anders ginge zeigt z.B. Delphi: Dort kann man Zeiger auf Methoden definieren, bei denen der Typ des Objekts nicht bekannt sein muss. (procedure of object) In C++ geht das halt nicht so ohne weiteres...
Bin auf dem Gebiet von C++ nicht so gut, aber geht sowas nicht auch mit mem_func?
Ciao,
_
Bin auf dem Gebiet von C++ nicht so gut, aber geht sowas nicht auch mit mem_func?
Ja, das habe ich gemeint. mem_func arbeitet mit Templates. Die Syntax schaut dann auch nicht so toll aus... ich glaub das war irgendwie sowas bei for_each:
for_each(it.begin(), it.end(), mem_func(&MeineKlasse::doSomething));
Ich glaube sobald das Ding einen Parameter hat, muss man mit bind2n oder so arbeiten:
for_each(it.begin(), it.end(), bind2n(mem_func(&MeineKlasse::doSomething2), parameter));
Fuer zwei oder mehr Parameter gibts dann noch nix, da muss man sich selber was basteln. Im Endeffekt ist das dann sowas was gtkmm mit libsigc++ schon macht.
Da wirken mir die Qt-connects schon etwas intuitiver.
Limitiert einen dann aber auch auf einen Handler pro Event.
Bei Signals&Slots ist es schon ziemlich praktisch, dass man da beliebig viele Verbindungen machen kann.
Ja, das stimmt. Und das sogar in beide Richtungen! n zu m sozusagen. (1 Signal -> n Slots; n Signale -> 1 Slot) Ich hab mich gestern etwas laenger mit Qt beschaeftigt. Bin schon ziemlich beeindruckt, vor allem von der Dynamik und Einfachheit. Von der Dynamik die ich zuletzt nur von ObjectiveC mit Cocoa/GNUstep/NeXTStep her kannte. Qt scheint hier mit dieser Technologie etwas verwandt zu sein. Zudem hatte ich beim Programmieren mit Qt etwas, was ich so schon lange nicht mehr hatte: Spass.
Wo wir beim Thema sind. :D
Bei GTK+ hatte ich das nicht. GTKmm find ich wg. Templates (und der damit verbundenen Syntax) nicht so toll. Zudem gehoere ich auch nicht zu diesen STL-Unterstuetzern. Zusaetzlich gefaellt mir diese _ Schreibweise bei Methoden etc. nicht so gut. Die Methoden-Schreibweise von Qt trifft da genau in meinem Stil den ich mir in den letzten Jahren angewohnt habe.
Programmiertechnisch gesehen wuerde ich vom derzeitigen Standpunkt aus auf Qt setzen. Auch wenn ich eigentlich mehr in die Gtk-Schiene gehoeren wuerde, weil alle meine Anwendungen die ich verwende Gtk-Programme sind. Mit Qt komme (ich zumindest) schneller voran, denke ich.
Powered by vBulletin® Version 4.2.5 Copyright ©2025 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.