NazGUl - Nice and zealous GUI library
-
Da ich bis jetzt kein GUI-Toolkit für C++ gefunden habe, das mir einigermaßen gefällt, habe ich vor ein paar Monaten angenfange, mir auf Basis von FLTK ein eigenes sehr kleines Toolkit zu schreiben.
Es würde mich interessieren, was ihr davon haltet/ob ihr Anregungen habt/Bugs findet (bestimmt) ;). Das einzige was benötitgt wird, ist FLTK 1.1.7 und ein halbwegs aktueller C++-Compiler (der aktuelle g++ funktioniert auf jeden Fall). Getestet wurde unter Linux, Mac und Windows.
Ich hoffe, an der main.cpp wird halbwegs klar, wie das Ganze funktioniert.
Vielen Dank fürs Testen,
Felix
Link (Source-Code): http://www-users.rwth-aachen.de/Felix.Voigtlaender/Nazgul.tar.gz
-
Ich hab nur ganz kurz reingesehen, aber die paar Dinge die mir gleich aufgefallen sind will ich dir nicht vorenthalten (vielleicht interessiert's dich ja - wenn nicht is auch OK
):* Verwende "explicit". Das spart Ärger durch ungewollte Konvertierungen.
* Die Raw-Pointer überall finde ich nicht so toll (manuelles Memory-Management - *würg* - gerade bei GUI Libraries kann man sich fast immer den minimalen Overhead leisten den shared_ptr o.ä. mitsich bringen).
Wenn du trotzdem mit Raw-Pointern arbeiten willst (z.B. einfach weil du das so magst) dann dokumentiere die Regeln klar und misverständlich, und guck zu dass diese Regeln möglichst "uniform" sind (also dass es überall nach dem gleichen Schema abläuft meine ich).
* Einige Teile könntest du dir vermutlich einfacher machen wenn du einige Boost Libraries verwendest (shared_ptr, function, bind, ...).
* Wo ist der Namespace? Ich persönlich hasse Libraries die im Global-Namespace rumsauen.
* "__FILENAME_H__" -> "INCLUDED_FILENAME_H" (Identifier die __ enthalten sind reserviert)
* "getter" und andere Funktionen die per Definitionem den logischen State eines Objektes nicht verändern sollten "const" sein ("unsigned int Rows()" -> "unsigned int Rows() const" etc.).
* Trenne die "public include files" und die Source Files auf, üblich wäre "/include/LibraryName/xyz.hpp" für die "public include files" und "src/xyz.cpp" für die Source Files + "private include files".
----
Ansonsten: schreib mal Doxygen Kommentare oder sowas, generier ein CHM daraus, und lade die Library irgendwo hoch. Sourceforge oder sowas. Version Control ist immer gut, und so ist es für andere auch einfacher den Code durchzusehen.
Und wenn du willst dass die Library auch auf anderen Compilern verwendbar ist solltest du auf jeden Fall parallel zum GCC Projekt wenigstens ein 2. pflegen welches einen anderen Compiler (z.B. MSVC) verwendet. GCC und MSVC sind ne gute Kombination wie ich finde. Wenns mit den beiden geht hast du nen sehr grossen Teil aller potentiell interessierten User abgedeckt. Vor allem wenn du die GCC Version unter Linux/BSD verwendest. Mit nur einem Compiler übersieht man schnell Dinge wo ein anderer dann Zahnräder spuckt.
Build Files für MSVC führen auch dazu dass Windows Programmierer eher geneigt sein werden die Library zu verwenden - die meisten verwenden halt doch MSVC (und viele sind vermutlich zu faul eigene build Files zu erstellen, auch wenns nur ein paar Klicks sind).
