On Tue, Sep 7, 2010 at 12:49 PM, Alexander Lamaison <awl03@doc.ic.ac.uk> wrote:
On Tue, 7 Sep 2010 09:51:10 -0700, Sebastian Redl wrote:
On Sep 7, 2010, at 5:40 AM, Alexander Lamaison wrote:
On Tue, 7 Sep 2010 09:47:03 +0200, Yakov Galka wrote:
On Tue, Sep 7, 2010 at 02:16, Gwenio <urulokiurae@gmail.com> wrote:
I repeat that I am focusing on the low-level components because I do not want the discussion to get stuck on what appears to be a very difficult subject. Therefore I would like discussion of higher level parts to be limited to what would be required to implement them.
Then *please*, explain how your library will differ from e.g. gtkmm?
link: http://www.gtkmm.org/en/
I hope that, for starters, the end-result would look nothing like that produced by gtkmm. GTK-based GUIs on Windows just look 'wrong'.
The visual appearance of programs has very little to do with library design. Qt programs look great IMO, but they don't use any native widgets even on Windows. They just have a very faithful native l&f. But you can style them differently even on Windows.
On Linux I would say that GTK and QT *are* the native widgets for their respective desktop environments, Gnome and KDE. Widgets are native to a desktop environment rather than an OS and it's only becuase Windows just has one environment that people talk about native Windows widgets.
So the question is perfectly valid. IMO it doesn't make any sense to design low-level components if you don't have a high-level design.
The problem is that these are two completely separate things. Any high-level framework will be build on top of low-level widgets so at some point these will need wrapping in a portable manner so at some point this job has to be done anyway. Exposing these as a boost library in its own right means we don't force users to use the high-level concepts if they prefer not to or prefer to roll their own.
Two things: Has anyone looked at the Juce GUI framework (http://www.rawmaterialsoftware.com/juce.php)? Its license is a bit nasty (GPL), but its design is fascinating. Unfortunately it does not use native widgets, but it has a few nice features including being *very* fast, everything is vector drawn, multi-platform with no code changes needed, easy to port to other 'things (I made a test port of it to work as the menu system in Ogre3D, a 3d rendering engine, worked with OGL and D3D through it perfectly), a few down sides is it still uses the hierarchy type setup, but it did use signal/slots setup everywhere, quite a few other niceties as well, and I do enjoy using it, very simple to set up, can be integrated into other GUI frameworks with ease for a hybrid set up, and can be added in as a quick drop-in into any program. I would not recommend using its style as the hierarchy style is quite limited (I like one of the aforementioned ideas of templating personality, actions, etc...), but I love the aspect that it can be 'dropped' into a program, can be stuffed into other GUI programs transparently (its vector drawing is amazingly useful and easy to perform, could put a Juce interactive chart into an MFC program for example). Plus with the ability to write it into other systems, such as a 3d rendering context, was an absolute boon! I have been tempted to 'try' to port wxWidgets into a 3d context as well (Ogre3D), and it should be possible (wxWidgets likes more control though...). wxWidgets has the nice bit that it can use native widgets, or everything is self drawn (Universal mode, and you can theme anything how you like then), unfortunately you cannot use both at the same time, which is an obvious design flaw. I do like the Adobe Adam&Eve set up, have not tried using it yet though so unsure of how it actually 'feels'. But for a GUI library that I would use: * If big and requires things to be built around it, like wxWidgets or Qt, would be used sparingly * If could be 'dropped' into existing non-gui apps, would be used more often. * If could be 'dropped' into existing gui apps using a different framework, would be used even more often. * Should be able to use native widgets, but should not be forced, should be able to choose between native or themed, preferably you can call something like bool SetTheme(const std::string&), and if passed a keyword like "__native__" or so then it should use native widgets, else it should return false to allow choosing an actual theme (or default to a default) in case the current platform does not have native widget support for it. * If could easily be integrated into a 3d rendering context (like Ogre3D, and I could do the porting work as I know how), in addition to the above, I would use it exclusively.