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

Subject: Re: [boost] Thoughts for a GUI (Primitives) Library
From: Alexander Lamaison (awl03_at_[hidden])
Date: 2010-09-07 17:38:56

> On Tue, 7 Sep 2010 12:50:50 -0700, Cory Nelson wrote:
> 
> > On Tue, Sep 7, 2010 at 11:41 AM, Alexander Lamaison <awl03_at_[hidden]> wrote:
> > On Tue, 7 Sep 2010 10:19:23 -0400, Gwenio wrote:
> >
> >> On Tue, Sep 7, 2010 at 8:40 AM, Alexander Lamaison <awl03_at_[hidden]>wrote:
> >>>
> >>> I hope that, for starters, the end-result would look nothing like that
> >>> produced by gtkmm.  GTK-based GUIs on Windows just look 'wrong'.  I'd hope
> >>> that any solution we envisage would use the platform native widgets to
> >>> render itself just as SWT does for Java.
> >>>
> >> Getting a native look would be difficult;
> >
> > Why?  It's been done well in the past.  Just not for C++ (if you exclude
> > the C++ 'port' of SWT)
> >
> >> ideally you would have a set of
> >> functions that provide the functionallity to draw in the native style.
> >
> > Yuk.  This approach doesn't work well.  Every time the native style changes
> > you have to update your fakes widgets.  Maintainence nightmare!  Not to
> > mention that it's almost impossible to simulate native widgets faithfully.
> 
> And yet many people do want a native look, so if it's not using native
> controls already, I think building it with enough theme support to
> make this work is imperative.

Absolutely!  I simply wouldn't touch a GUI library that didn't render
native widgets.  I'd be too embarrassed to release software that had an
amateur look&feel.

> >> The
> >> other way would to have a wrapper for native controls and some method to
> >> adjust how they function.
> >
> > This is how SWT, Adam/Eve, etc. work though I'm not sure what you mean by
> > adjust how they function.
> 
> I think that using native controls, while much simpler, would severely
> handcuff us in terms of how great we could design the library.  A
> clean break from any native controls would give us many more options.
> 
> I know that saying "WPF" will turn some people off immediately

Not me.  But by all accounts the effort involved in developing the
'windowless' WPF GUI library wass extreme.  Possibly as great as all other
Boost libraries combined.  (If I had time I'd find the quotes from MS
insiders to back this up.  Raymond Chen said something pertinent to this at
one point.)

> > If there are native controls why bother with custom controls. (I also don't
> > see what 'branches' have to do with anything - do you mean 'option')?
> 
> Not all native controls exist on all platforms, and not all native
> controls have the same functionality.  If we didn't want to limit the
> library to the small subset of controls and functionality that exist
> on all platforms, we'd eventually need to write some custom controls.

The overlap is greater than you think but you have a valid point.  SWT's
approach to this to to custom-draw a control if and only if it doesn't
exist on the platform in question and can't be created by aggregating two
or more other controls.  This is an acceptable approach as it it _not_
simulating a native control: there is no native control to simulate.

I know I keep harping on about SWT but it really is a *fantastic* GUI
library that gives cross-platform, best-of-all-worlds, native GUIs rather
than lowest-common deminator support or custom-drawn nonesense.  My idea of
the ideal Boost.GUI library would be something in the vein of SWT but with
a much nicer interface.

For those of you who hate the idea of manipulating individual controls and
want to program at a higher level look at the relationship between SWT and
JFace.  JFace create common UI elements in a model-based manner and is
built on top of SWT.  SWT in no way depends on any aspect of JFace.  The
same should apply to any higher-level GUI framework in Boost.  It should
build on top of an SWT-style layer and, in my opinion, they should be
separate libraries.

Alex

-- 
Easy SFTP for Windows Explorer (http://www.swish-sftp.org)