Re: [boost] Thoughts for a GUI (Primitives) Library

Subject: Re: [boost] Thoughts for a GUI (Primitives) Library
From: OvermindDL1 (overminddl1_at_[hidden])
Date: 2010-09-07 15:30:16

On Tue, Sep 7, 2010 at 12:49 PM, Alexander Lamaison <awl03_at_[hidden]> 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_at_[hidden]> 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.