"Felipe Magno de Almeida" <felipe.m.almeida@gmail.com> wrote in message news:a2b17b60906121714g6d209b47sd77f6c2d1a7aece6@mail.gmail.com...
I've been working the past two years, on and off, unfortunately more often not, in a GUI library. But I have gotten back to it. And I wanted to make it usable. I believe there are some great things in it. This library has a named parameter interface which is extensible by the backend implementation. I've been working on a QT port, which have been fairly easy so far. My intention is to rework some parts of it, finish most widgets and the surface concept I've been working on and submit to review to boost.
The library is in http://www.assembla.com/wiki/show/cppgui There's a svn and trac there that I use. The library requires the boost/funcitonal/factory.hpp library reviewed and accepted (?), which is not yet part of any boost distribution to compile. You will also need fusion to compile. I've tested with GCC 4.4.0/4.3.3 with QT and win32 with visual C++ 9.0. But should be pretty portable, including qt in visual C++.
hi, my first post here so an in-advance-apology if i "step on a 'house rule or two'" ;)
... But I wanted some ideas on the controller interface and whatever might be useful too in improving the design before submitting.
i'm sorry i'm a bit late but... ..after a long, exhaustive, and frustrating, search for a 'proper' cross-platform gui framework this post was a real sign of hope (finally, a "booster" doing gui :)...your library is, with the exception of the windows-only wtl, the only one (i found) using the crtp so an immediate thumbs up for that one as with any _c++_ library i expect/want it to be 'properly designed' in both the 'effectivness' and the 'efficiency' fields (while i found no existing library that would be even remotly satisfying...the worst 'offender' probably being wx and qt with macros, 'exception-agnosticism', "reinventing-the-universe" and binary sizes approaching/breaching the 10MB mark)... with that said i have a few wishes/suggestions: - make the library more configurable with a policy based design (oh the buzzwords :)...some of the following points will give examples... - do not 'force'/'hard code' the use of boost::signals: i would argue that the vast majority of guis "out there" are static in nature in the sense that dynamic/runtime attachment/dettachment of possibly-multiple observers/handlers is simply not necessary...making boost::signals an overkill for that 'majority of cases' (if i remember correctly, adding a single boost::signal added ~50kB to my binary, with all the optimizations available in msvc-9.0, and, as it was previously mentioned, using the signals method can be overly verbose in cases where it is not needed)...it would be ideal if it could be made to be a matter of policy whether to use boost::signals, 'plain' boost::functions, functors/function pointers as template parameters or, the 'old school', deriving (static/crtp or dynamic polymorphism) - similar thing goes for child/parent "holding policy"...again i'd argue that 'most guis are static in nature' in the sense that their children or parent do not change dynamically (their number and type, not that they themselves, as in their internal state, do not change)...so it would be great if children could be, for example, specified and/or held with mpl/fusion compiletime/static containers as well as boost/stl runtime/dynamic containers/ranges - duplicating os provided functionality should be avoided as much as possible: - most (if not all) os gui implementations already use the handle/body idiom (the C variant of the interface/implementation idiom) coupled with a messaging system and/or a system of global functions that 'do' something on a handle (the C variant of virtual functions, e.g. the SetWindowPos() win32 call that sizes/moves any window, regardless of its 'type'/'class')...that makes the typical/'traditional' 'c++' gui library approach of duplicating all that by (always/'as a rule') 'newing' all widgets and accessing them through pointers and virtual functions ('mostly') unnecessary and ('very') inefficient (if anything stops/kills a compiler's and linker's optimization oportunities then those are surely function pointers/virtual functions/collections of those like signals and heap allocated 'forests of pointers').....with that said, even if a particual ui requires access to widgets through a base class interface it still does not imply that the interface must (always) be virtual (because the underlying os api already made it that way)...in any case it would be nice if it could, again, be a matter of policy whether to use an abstract base/interface for a widget/widget set/hierarchy of widgets or not... - child/parent lists should not be separately maintained (like in member containers) when that housekeeping information is already being maintained by the os (e.g. win32 EnumChildWindows() ) - thunks (like wtl) and extra 'user memory' for window classes (win32 WNDCLASS.cbWndExtra) can be used to avoid dual memory allocation (one by the os when it creates the window and the other by the 'framework' for its os window handle wrapper class) - stack allocated/local/temporary windows/widgets should be possible...for those that must always be, from a design perspective, heap based/non local intrusive_ptr should be used instead of shared_ptr when shared semantics is also a must-by-design (making the design both more obvious and light(er)weight) - related to the above point is the welcome existence of both 'proper'/full/implementation window classes as well as 'attachable/hwnd wrapper' classes (like in wtl) that have most of the same interface but different usage scenarios - issues with basic types and structs (like Point and Rect) differing between different OSs could perhaps be solved by using a wrapper class (for example class boost::gui::rect : private RECT {..} on win32) which use the native type(s) for storage and thus a no-op conversion to the native type when calling os functions while providing member getters and setters for different types (rect.size<int>(), rect.size<float>, rect.size<native_type> or something along those lines)... - along with native implementations there could also be a universal opengl implementation...and/but opengl windows/widgets/functionality 'should' also be available when using a native implementation (for mixing/embedding opengl windows in/with 'normal' ones)... - the library and/or its widgets should be able to work in plugin like applications where you get a native handle for your (parent) window from the host application and have to work from/with that... - a knob/dial widget please ;) - (std::)streams, as a horrible horrible example of bloat and inefficency (i dare anyone to step through a simple declaration/default construction of a std::xstream object in release mode looking at the asm output), should be avoided at all cost...if they are used somewhere care should be taken that the compiler and linker can freely remove std::xstream crt code from the binary if that particular (gui) library functionality is not used (not using them in virtual functions and avoiding 'spaghetti' code is usually enough) - xml/layout/designer files and dynamic runtime ui construction functionality is by all means very welcome as a powerfull feature but, as in the previous remark, it should be implemented so that if one does not use it one also does not end up with xml&co. code in one's binary - it would be welcome if the library's error handling/sensitivity/paranoia could be configured. for example that the paranoid/'defensive programmers' can say 'throw on even the least sign of trouble' while other can say throw/check-for-and-report-an-error only when it is reasonable to expect that it can actually happen (e.g. getting the string contents of a list box item with a known valid index and a known valid list box handle into a preallocated buffer 'cannot'/has no reason to fail even though the functions used to perform the said action can return an error code...such cases should be 'handled' with an assert imho) - furthermore it would be very welcome if the library could also properly work with BOOST_NO_EXCEPTIONS (and use error codes for error reporting)...for example if i'm writing a small utility and just want to bring up a simple dialog i do not want to be forced to link with the crt, and double my binary size, only to get exception handling... - ...as always..."you do not pay for what you do not use" ;) -- "That men do not learn very much from the lessons of history is the most important of all the lessons of history." Aldous Huxley