FLTK Meinungen

Scorcher24

freizeit_programmierer schrieb:

Is sehr nett, ich habe auch schon mal mit rumgespielt. Mir gefallen die dynamsichen Eventhanlding besser als die Eventmakros, aber das kann ja jeder machen wie er will.

Das mit HTML 1 is völlig egal, da ich nur GUI brauche und den Rest selbst mache zu Lernzwecken oder halt noch andere libs bei bedarf dazuhole.

Kann ich eigentlich bei wxWidgets wenn ich das für statisch kompiliere auch nur die libs reinhauen die ich brauche also z.B html draussen lassen?

Das macht der Compiler automatisch. Der linkt nur, was wirklich gebraucht wird.
Das Framework ist allerdings in mehrere kleine libs unterteilt. So musst Du nur gegen das linken, was du brauchst. Auch bei den .dll ist das so. Es gibt viele kleine dll, die für einen bestimmten Bereich zuständig sind. Man kann aber auch alles in eine große packen. Wie man das möchte.
rya.

Artchi

freizeit_programmierer schrieb:

@artchi: deine lib schaut schon ganz nett aus es fehlen aber auch einige GUI Elemente wie TreeViews, Grids, Toolsbars, Split- und TabbedWindows oder?

Verständlich das da noch so viel fehlt, da es ja nicht mal eine Version 1.0 gibt. Es ist ganz klar noch in Entwicklung und es lebt auch sehr stark. Deshalb gibt es auch keine "Werbung" dafür.
Die anderen GUI-Libs wie FLTK oder wx sind dagegen schon viel länger auf dem Markt. Wenn Du JETZT was produktives brauchst, sind die anderen Libs besser für dich geeignet.

Ja stimmt du bist ja noch nicht bei der Version 1 angelangt und leider brauche ich schon jetzt was komplettes. Das soll aber nicht heißen das ich deine Lib nicht mal ausprobieren werden, auf jedenfall bleibt der Link zu deiner Seite erhalten. Es macht alles einen sehr seriösen Eindruck, ist irgendwie schade das nur du dran arbeitest, was passiert wenn du keine Lust mehr drauf hast oder dir was passiert?

freizeit_programmierer schrieb:

Is echt schwer was komplettes leichtgewichtiges nur für GUI zu finden.

wieso?
so wie ich das sehe kommt eigentlich nur fltk fuer dich in Frage - da warst du eigentlich schon auf dem richtigen Weg. fltk-programme duerfen statisch gelinkt werden und erreichen eine unschlagbare Exe-Groesse - wenns dir darum geht wirst du was besseres (im Moment) nicht finden. Mit Hilfe von Schemes kannst du auch den "altmodischen" Look aufpeppen.
wxWidgets ist keine reine GUIlib sondern ein Framework mit allem moeglichem SchnickSchnack und meiner Meinung nach zu ueberladen fuer einen, der "nur" eine "leichtgewichtige GUIlib" sucht.

Hast ja recht, aber nachdem ich gelesen habe das fltk doch ziemlich instabil werden kann werde ich jetzt mal wxwidgets probieren, da sind die exe dann ca 3MB was zwar 10x mehr als bei fltk ist aber noch hart an der grenze liegt was ich mir so vorstellen kann. Vorteil sind natürlich die nativen Widgets. Das mit den Schemes kling aber auch interessant.

Artchi

freizeit_programmierer schrieb:

ist irgendwie schade das nur du dran arbeitest, was passiert wenn du keine Lust mehr drauf hast oder dir was passiert?

Das ein Proejkt eingestellt wird, kann jedem Projekt passieren. Bei MySQL hat man auch das Zittern bekommen, als Oracle Sun aufkaufte.

Das Argument für OpenSource ist aber meistens, das falls es sterben sollte, man es wenigstens selber weiter entwickeln oder zumindest pflegen kann (z.B. an neue Betriebssystem-Versionen anpassen). Von Algierlib ist jedenfalls der gesamte Sourcecode und Dokumentation bei Tigris verfügbar! Falls ich morgen weg sein sollte, kann jeder weiter machen... ob für sich privat oder öffentlich ist egal.

Ich selber bastel jetzt über drei Jahre daran. Habe damals nach dem ersten Jahr alles über den Haufen geworfen und neu angefangen. Dann später wieder das Design geändert (speziell die Smartpointer-Geschichte). Dann ist noch das MVC dazu gekommen. Die Doku/Manual wird von mir meiner Meinung nach recht gut gepflegt, was mir auch wichtig ist.
Zur Zeit werden fünf Compiler von mir unterstützt, d.h. ich teste jedes Release mit diesen Compilern.
Auch sind jetzt Unittests für TDD dazu gekommen, auch wenn noch nicht alles abgedeckt wird.

Also, das macht schon alles Arbeit, und bisher habe ich noch nicht aufgegeben. Vieles geht auf Design und wie du sagst "seriösität" drauf, so das die Widget-Anzahl leider leiden muß. Aber ich finde, es bringt nichts, wenn ich alles mit Widgets voll stopfe, aber die "seriösität" leiden muß.

Vor sechs Monaten hatte ich die Lib hier vorgestellt, und es gab überwiegend gute Kritik. Ein paar Änderungswünsche sind auch schon eingeflossen. Es geht also immer weiter. Ich weiß aber auch in etwa, was noch alles an Features fehlt, um eine breitere Anwendermasse zu erreichen. Deshalb habe ich auch eine Roadmap, in der ich das geplant habe. Wenn diese Anwendermasse erreicht wird, wird auch das Risiko kleiner, das das Projekt stirbt.

Vielleicht haste auch die Chance, nach Fertigstellung der V1.0, dass du noch mehr Unterstürzung von guten Entwicklern erhälst. Ich gebe dir recht das die Qualität nicht zugrunde der Quantität aufgegeben werden sollte. Ich drücke dir das auf jeden Fall feste die Daumen

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ß,
Qtianer

Gebe dir Recht. Das ist aber auch der Grund weshalb Qt keine Exceptions verwendet; um die Kompatibilität zu älteren Compilern zu wahren.

l'abra d'or

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.

Scorcher24

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.

l'abra d'or

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.

Artchi

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?

Artchi

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.

l'abra d'or

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.

Scorcher24

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

l'abra d'or

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...)

Artchi

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.