FLTK Meinungen
-
Qtianer schrieb:
Was will man denn noch mehr?
Modernes C++.
bietet ein ganzes Framework, dass auf fast jedem C++-Compiler, der je entwickelt wurde kompilierbar ist
Leider behindern sich die Entwickler mit diesem Anspruch eher selbst. Wozu soll das gut sein? Wer verwendet heute noch 10 Jahre alte Compiler?
Gruß,
QtianerGebe dir Recht. Das ist aber auch der Grund weshalb Qt keine Exceptions verwendet; um die Kompatibilität zu älteren Compilern zu wahren.
-
Was mir an wxWidgets nicht gefällt ist diese Makro-Lastigkeit.
Warum das Gedöhns mit eigener EVENT_TABLE? Dafür gibt es in C++ "virtual". Man kann sich dann halt keine eigenen Bezeichner ausdenken sondern muss bestimmte Virtuelle Funktionen implementieren. Aber wen scherts? Oder hat das EVENT_TABLE noch nen Vorteil, den ich nicht sehe?
Hier gab es mal ein böses Problem (SEGFAULT) durch diese EventTable, find ich leider nimmer...Das andere was ich immer finde ist das "IMPLEMENT_APP", was scheinbar eine globale Variable anlegt. Will man das nutzen braucht es ein DECLARE_APP (oder?). Kann man da nicht gleich nen Singleton verwenden? Das erleichtert die Arbeit ungemein.
Wegen Qt und Moc:
Das macht schon noch mehr als nur SIGNAL/SLOT ermöglichen. Properties, z.B. Das wird dank Kinetic (Animations-Framework) richtig bequem, dank QPropertyAnimation. In 5 Zeilen hat man eine fertige Animation
Designer-Integration wird dadurch auch verdammt einfach.
QMetaObject ist auch ne feine Sache.Und wer will kann auf den moc komplett verzichten. Der erstellt nur ein Sourcefile, das man natürlich auch selber schreiben kann, dann sollte man auf die nicht-C++-konformen Sachen und einen zusätzlichen Preprozessor verzichten können. Ist halt zusätzlicher, fehleranfälliger Zeitaufwand, aber dafür kann man alles "direkt kompilieren". moc machts halt automatisch und einfacher
Und die nötigen Tools kommen bei der Qt-Standardinstallation mit, also was solls
Wenn man über die Probleme hinwegsehen kann, bietet Qt halt einiges an Bequemlichkeiten.
-
Du übersiehst etwas..
Wegen den Events:
Man muss diese Makros nicht benutzen. Man kann auch über Bind() dynamisch in die Events einsteigen. Hat den selben Effekt. Diese Makros sind im Endeffekt ein überbleibsel als das so gängig war. Stichwort: Ähnlichkeit zu MFC schaffen. Kam von M$ das Gedöns :P. Ich finds nicht so übel, weil ich es halbwegs übersichtlich finde und solange es funktioniert... im Endeffekt sinds nur Makros, die eine Funktion implementieren mit eben diesen Bind() Commands bzw sowas ähnliches.Das IMPLEMENT_APP-Makro hingegen ist wichtig. Es ist ein Makro, welches im Endeffekt die Main einsetzt, damit der Linker sich nicht wegen fehlender WinMain oder _main beschwert. Das sorgt für Platformunabhängigkeit und ist schöner als tausend #ifdefs wenn Du ein Programm für als bsp Handheld und M$ Windows kompilierst.
edit:
Nein, DECLARE_APP brauchts nicht unbedingt. Nur wenn man in anderen Klassen auf das einzigste wxApp Element zugreifen will...
rya.
-
Scorcher24 schrieb:
Man muss diese Makros nicht benutzen. Man kann auch über Bind() dynamisch in die Events einsteigen.
Ja, das hab ich auch gelesen. Trotzdem: Warum nicht gleich mit virtellen Methoden? Hast du ne Ahnung ob sich das mit wxWidgets-3.0 ändern wird? Ist halt ne zusätzliche Krücke. Wenn ich in Qt wissen will, was der Kerl jetzt mit der Maus anstellt, mach ich "Strg+F"->"mousePressEvent"->Enter->Ziel. So hab ich nen zusätzlichen Suchaufwand. Aber wahrscheinlich gibts eh Namenskonventionen, an die man sich hält.
Das IMPLEMENT_APP-Makro hingegen ist wichtig. Es ist ein Makro, welches im Endeffekt die Main einsetzt, damit der Linker sich nicht wegen fehlender WinMain oder _main beschwert. Das sorgt für Platformunabhängigkeit und ist schöner als tausend #ifdefs wenn Du ein Programm für als bsp Handheld und M$ Windows kompilierst.
Dann scheint es Qt in die lib auszulagern, denn da funktionieren Programme mit normalem Standard-C++-konformem "int main()", man legt ein QApplication-Objekt in der main() an, und auf allen Plattformen läuft es.
Nein, DECLARE_APP brauchts nicht unbedingt. Nur wenn man in anderen Klassen auf das einzigste wxApp Element zugreifen will...
rya.Das meinte ich mit "wenn man das nutzern will". Laut Doku macht das ne forward-declaration auf das app-Objekt.
-
l'abra d'or schrieb:
Was mir an wxWidgets nicht gefällt ist diese Makro-Lastigkeit.
Warum das Gedöhns mit eigener EVENT_TABLE? Dafür gibt es in C++ "virtual". Man kann sich dann halt keine eigenen Bezeichner ausdenken sondern muss bestimmte Virtuelle Funktionen implementieren. Aber wen scherts? Oder hat das EVENT_TABLE noch nen Vorteil, den ich nicht sehe?c++ verwendet vtable für virtuelle Funktionen, 4 Byte werden für jede virtuelle Funktion verwendet, egal ob überschrieben oder nicht.
Bei der Komplexität von MFC würde jedes Fenster eine ca 400 Byte große Tabelle mit sich rumschleppen.
-
l'abra d'or schrieb:
Scorcher24 schrieb:
Man muss diese Makros nicht benutzen. Man kann auch über Bind() dynamisch in die Events einsteigen.
Ja, das hab ich auch gelesen. Trotzdem: Warum nicht gleich mit virtellen Methoden? Hast du ne Ahnung ob sich das mit wxWidgets-3.0 ändern wird? Ist halt ne zusätzliche Krücke. Wenn ich in Qt wissen will, was der Kerl jetzt mit der Maus anstellt, mach ich "Strg+F"->"mousePressEvent"->Enter->Ziel. So hab ich nen zusätzlichen Suchaufwand. Aber wahrscheinlich gibts eh Namenskonventionen, an die man sich hält.
Das IMPLEMENT_APP-Makro hingegen ist wichtig. Es ist ein Makro, welches im Endeffekt die Main einsetzt, damit der Linker sich nicht wegen fehlender WinMain oder _main beschwert. Das sorgt für Platformunabhängigkeit und ist schöner als tausend #ifdefs wenn Du ein Programm für als bsp Handheld und M$ Windows kompilierst.
Dann scheint es Qt in die lib auszulagern, denn da funktionieren Programme mit normalem Standard-C++-konformem "int main()", man legt ein QApplication-Objekt in der main() an, und auf allen Plattformen läuft es.
Nein, DECLARE_APP brauchts nicht unbedingt. Nur wenn man in anderen Klassen auf das einzigste wxApp Element zugreifen will...
rya.Das meinte ich mit "wenn man das nutzern will". Laut Doku macht das ne forward-declaration auf das app-Objekt.
Is doch egal wie es Qt macht, bedenke das wxWdigets wirklich freie Software ist, im Gegensatz zu Qt wo du dich denen fügen musst, auch wenn es viel besser geworden ist so kannst du denn noch nicht machen was du willst damit, da es doch kommerziell ist.
Ich persönlich kenne keine Alternative zu wxWidgets wo man mit machen kann was man will. Für viele reicht es einfach, und es muss auch nicht immer alles perfekt sein um Spass zu machen. Ich kenne Leute die programmieren 8bit Assembler und haben jede Menge Freude dran.
Wenn dir Qt soviel besser gefällt nimm es doch und gut ist, anderen gefällt es halt nicht, basta. Es gibt nun mal nicht das perfekte Framework für alle.
-
Zabou schrieb:
c++ verwendet vtable für virtuelle Funktionen, 4 Byte werden für jede virtuelle Funktion verwendet, egal ob überschrieben oder nicht.
Bei der Komplexität von MFC würde jedes Fenster eine ca 400 Byte große Tabelle mit sich rumschleppen.Und?
-
l'abra d'or schrieb:
Was mir an wxWidgets nicht gefällt ist diese Makro-Lastigkeit.
...
Das macht schon noch mehr als nur SIGNAL/SLOT ermöglichen. Properties, z.B. Das wird dank Kinetic (Animations-Framework) richtig bequem, dank QPropertyAnimation. In 5 Zeilen hat man eine fertige Animation
Designer-Integration wird dadurch auch verdammt einfach.
QMetaObject ist auch ne feine Sache.Komische Logik. Du beschwerst dich über die Makros in wx, aber die Makros in Qt stellst du als Vorteil.
Entweder man findet Makros schlimm, oder nicht. Warum sind die Qt/Moc-Makros nicht schlimm, oder sogar gut?.
-
Nimm den nicht zu ernst, der trollt gerne mal etwas rum. Die Kommentare kann man zu 90% ignorieren wenn es um qt zu wxwidgets geht.
-
Jippie, ich bin der böse Troll von Nebenan
Alles ist Subjektiv, vor allem die eigene Meinung. Ich kenne wxWidgets noch nicht gut genug, verzeiht mir also meine Qt-lastige Sichtweise. Bin aber dabei in wxWidgets einzutauchen, weils mich interessiert!
Makro-Lastigkeit war wohl nicht korrekt, außerdem wusste ich zu dem Zeitpunkt noch nicht dass es mit Bind geht (man lernt ja nur dazu). Und ich finde die Macros bei Qt "besser", weil sie tatsächlichen Mehrwert bieten. Ein IMPLEMENT_APP wird bei Qt nicht nötig um ein WinMain zu kreieren oder eben ein int main, je nach Plattform. Dagegen finde ich Properties, SIGNAL/SLOT, QMetaObject eine schöne Sache, die händisch recht viel zusätzliche Zeit benötigen. Die mögliche Verharmlosung kommt daher, dass ich GUI mit Qt angefangen habe und es gewohnt bin, ich respektiere aber andere Meinungen und verschrei Artchi (dessen AlgierLib sich echt gut anhört, BTW.) nicht als Troll, weil er Qt nicht mag.Und wxWidgets4free: Qt steht seit v4.6.0 unter LGPL, damit darf ich sehr wohl Proprietäre Programme schreiben, ohne für Qt zahlen zu müssen. Ich darf halt dann nicht statisch linken - darf ich das bei wxWidgets? Ich glaube nicht.
-
l'abra d'or schrieb:
Jippie, ich bin der böse Troll von Nebenan
Alles ist Subjektiv, vor allem die eigene Meinung. Ich kenne wxWidgets noch nicht gut genug, verzeiht mir also meine Qt-lastige Sichtweise. Bin aber dabei in wxWidgets einzutauchen, weils mich interessiert!
Makro-Lastigkeit war wohl nicht korrekt, außerdem wusste ich zu dem Zeitpunkt noch nicht dass es mit Bind geht (man lernt ja nur dazu). Und ich finde die Macros bei Qt "besser", weil sie tatsächlichen Mehrwert bieten. Ein IMPLEMENT_APP wird bei Qt nicht nötig um ein WinMain zu kreieren oder eben ein int main, je nach Plattform. Dagegen finde ich Properties, SIGNAL/SLOT, QMetaObject eine schöne Sache, die händisch recht viel zusätzliche Zeit benötigen. Die mögliche Verharmlosung kommt daher, dass ich GUI mit Qt angefangen habe und es gewohnt bin, ich respektiere aber andere Meinungen und verschrei Artchi (dessen AlgierLib sich echt gut anhört, BTW.) nicht als Troll, weil er Qt nicht mag.Und wxWidgets4free: Qt steht seit v4.6.0 unter LGPL, damit darf ich sehr wohl Proprietäre Programme schreiben, ohne für Qt zahlen zu müssen. Ich darf halt dann nicht statisch linken - darf ich das bei wxWidgets? Ich glaube nicht.
Doch, darfst Du.
Die wxWidgets-Lizenz ist eine leicht modifizierte LGPL und erlaubt daher die freie Verwendung in proprietärer und freier Software und den weiteren Vertrieb unter einer selbst gewählten Lizenz.
http://de.wikipedia.org/wiki/WxWidgets
Und ob man QT oder wx oder was auch immer: Darf doch jeder so glücklich werden wie er will. Ich mit wx und Du mit QT :). Hauptsache Du programmierst feine Sachen und am besten Open Source :D.
rya
-
Wobei das "LGPL" bei wxWidgets etwas irritiert, gemeint ist damit nämlich nicht die Lesser GPL, sondern die Library GPL, welche als "deprecated" (AFAIR) gesetzt ist.
Und ja, jedem das was ihm gefällt! Flamen will ich eigentlich nicht (oder hab ich geschrieben dass wx scheiße ist? Glaub nicht...)
-
l'abra d'or schrieb:
verschrei Artchi (dessen AlgierLib sich echt gut anhört, BTW.) nicht als Troll, weil er Qt nicht mag.
Also es ist nicht so, das ich es hasse. Ich habe da Kritikpunkte, aber wenn man sich meine Beurteilung auf meiner Homepage dazu liest, wird man feststellen, das Qt doch recht gut weg kommt.
-
Ok, ich kratze den Trollstempel von dir ab :D.
Ich bin auch kein qt Gegner, nur kommt es halt für mich nicht in Frage. Ich möchte nun mal selbst entscheiden wie ich mit meinem Framework umgehe. Ferner lehne auch alle Köderversuche von kommerzieller Software ab die versucht mit eingeschränkten Kostenlosvversionen Kunden zu binden, also fällt VisualStudio für mich auch flach. Aber ich arbeite eh lieber ohne IDEs, da meine Projekte nie so groß werden als dass ich sowas brauchen würde. Das ist alles selbstverständlich auch total subjektiv aber ich programmiere ja auch nur so zum Spaß, bei dem Stand der Softwareentwicklung möchte man das auch nicht gerne beruflich machen
-
freizeit_programmierer schrieb:
Hast ja recht, aber nachdem ich gelesen habe das fltk doch ziemlich instabil werden kann werde ich jetzt mal wxwidgets probieren
Öh, nee, FLTK ist extrem stabil, wenn man die "Stable Release" v1.1.10 nutzt. V1.3 ist auch schon gut im Rennen und kann wesentlich mehr. v2.1 ist ein anderes Thema, wird aber eh nicht mehr weiter entwickelt, wie man an jeder Ecke der Internetseite lesen kann... .
-
Ihr koennt ueber FLTK sagen was ihr wollt, aber es hat eine WESENTLICH schoenere API als wxWidgets oder Qt, ganz ohne Makros
Okay, es fehlen Sachen wie Netzwerkprogrammierung... aber das laesst sich ja alles sehr leicht nachruesten (selbst wxWidgets-Programmierer verwenden lieber CURL als die native wxWidgets-Netzwerk-Lib :p ). So wird einem keine STL-aehnliche Container & Co. 'angedreht'.
-
Die meisten bekannten GUI Libs sind schon sehr lange auf dem Markt und sind auch kräftig im Einsatz. Deshalb sind sie auch stabil. Egal ob FLTK, FOX-Toolkit u.a. Alle sind von der Stabilität bedenkenlos empfehlenswert. Auch wenn sie nicht die Publicity von Qt und wx haben.