RE: [boost] Re: GUI/GDI template library

From: Brock Peabody (brock.peabody_at_[hidden])
Date: 2003-07-30 09:15:59

> -----Original Message-----
> From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]]
> On Behalf Of Beman Dawes
> Sent: Wednesday, July 30, 2003 7:09 AM
> To: Boost mailing list
> Subject: Re: [boost] Re: GUI/GDI template library
> 
> At 02:24 AM 7/30/2003, E. Gladyshev wrote:
> 
>  >...[compile-time or run-time?] I don't know what is the best way to
go.
> 
> It is always hard to know the best way to go if you don't know where
you
> are going.
> 
> A GUI/GDI library might fill one or more needs:
> 
> 1) A conceptually clean library, easy-to-use, good for teaching GUI
> principles, and useful for real applications where the emphasis is on
> portability. Controlling the look-and-feel on different platforms not
a
> concern. Access to platform specific features not a concern.
> 
> 2) An adaptable library for applications which do need a certain
amount of
> control over look-and-feel on different platforms. Portability is
quite
> important, but so is ability to adapt look-and-feel to different
> platforms.
> Access to some platform specific features may be a concern.
> 
> 3) Totally controllable library for applications which need to manage
> every
> aspect of look-and-feel, and need access to every feature the platform
> provides. Portability not a concern.
> 
> (That's an oversimplification, but good enough for discussion.)
> 
> Baring a stroke of genius (although on Boost that isn't totally
> impossible), it seems very hard to fill all of those needs.
> 
> It seems to me that most people who need (3) (or think they need (3))
> aren't going to use a portable library anyhow. I'd write-off (3) as a
> target.
> 
> Once you get over the mental hurtle of being willing to say "this
library
> doesn't try to fill every possible need", then (1) starts to look very
> attractive. It is a niche many other GUI libraries seem to have
ignored.
> If
> you concentrate on a conceptually clean and elegant design, then it
may
> turn out that it can also accommodate (2) fairly well.
> 
> --Beman

I agree completely.  Just getting (1) done will be enough work and we'll
learn a lot.  I think the focus should be on a clean and elegant
interface.

My suspicion is that applications generated with (1) will look more
'typical' for their platform than those making applications that need
(3).  They'll be portable, and at the same time exhibit more platform
specific run time behaviour.  Programmers using (3) need more control
because they are not making an application that has a GUI typical for
their platform.  If you want all of your application's list boxes to
behave exactly the same on all platforms, you are going to have to do a
lot more work than if you want windows list boxes to behave like windows
list boxes, and Mac list boxes like Mac list boxes, etc...

We had a programmer who was resistant to using our GUI libraries because
they limited his ability to add his own custom look and feel to each of
his applications.  His applications looked cool - but not like standard
windows programs.  They also tended to take a long time to produce and
debug.  The code was complicated and his custom logic had to be
reimplemented for each new application.  We don't want complicated
applications with a custom look and feel.  We want simple applications
with a uniform look and feel.  This need can be filled by (1) and I
suspect many others will feel the same.

 
Brock