RE: [boost] Re: GUI sublanguage ?

From: Brock Peabody (brock.peabody_at_[hidden])
Date: 2003-08-06 18:26:53

> -----Original Message-----
> From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]]
> On Behalf Of Bohdan
> Sent: Wednesday, August 06, 2003 5:46 PM
> To: boost_at_[hidden]
> Subject: [boost] Re: GUI sublanguage ?
> 
[...]

> > There are a lot of good reasons why we would not always want to have
> > total control.
> 
> "Not always" means "sometimes not" ?
> According to this logic your gui language is
> layer built on top of interface proposed by me
> ... just for convenience. Right ?

Yes, but I wouldn't underestimate the value of 'convenience' in the form
of simpler code.

[...]

> Have you invented universal algorithm for window size/position ?

It works surprisingly well.  I know I described it in detail in an
earlier post, I can sum it up again if you like.  It works well
especially if you need complete resizability.

Anyway, it would be easy to write your own algorithm.  The point is that
every programmer shouldn't have to implement one for every window.

[...]

> > A real world application needs much more sophisticated positioning
> > mechanisms than this.  The tiny snippet above (in my code) hides
some
> > pretty good positioning logic.
> 
> Don't be boring, this is just simple example ... without details in
mind.
> "sophisticated positioning mechanism" can be implemented by
> control/window class methods too. Even more, such interface allows
> changing behavior in runtime.

Sorry if I didn't state that well.  My point is just that part of the
purpose of the sub-language would be to make it much simpler to specify
positions. 

> > Again, these values should be picked automatically.
> 
>  Only if you are satisfied by default values. Believe
> me, this is very rare situation. Especially for "progress bar"
> control :))

But there has to be some sort of logic in what values you pick.  Is the
step size related to the number of ticks?  You could codify your logic
as the default behaviour in your applications.

> 
> >
> > Now, it might be cool to be able to change my above code to:
> >
> >       gui::show<my_company_gui_traits>( "sample boost application",
> >          ...
> 
> Generally runtime gui styles (flat, 3d ...) can be more helpful,
because
> changing look-and-feel in "application options" is very frequent
situation
> for serious GUI applications. Please don't be too obsessed by compile
> time, it is not very good way for GUI toolkit.

I agree that we need to be able to change look and feel at run time.  It
might be easier to do compile time only in the earlier phases of our
design.

[...]

> > - GUI code is difficult, tedious, and error prone even for simple
tasks,
> > I want to make it simple (for simple tasks)
> 
> Agree! But only for simple tasks.

Right now it can be complicated to develop large GUIs even if the actual
logic is pretty simple.  Furthermore, it might be possible to simplify
complicated tasks that are common (like positioning).

> 
> Now things are clear. My conclusion is following :
>       1. Such interface is ok for no-so-compicated gui and/or
controls.
>           I mean situations when you are satisfied by default values
>           for properties or properties differ from default ones not so
> much.

Yes.  You couldn't write MS Excel with it, but you could write a pretty
large number of business applications.

The programmer will be able to specify most of the default behaviour,
the usefulness will be determined by how frequently he needs behaviour
that differs from his own defaults.

>       2. It should be implemented on to of more functional, runtime,
>           interface ( used in most gui libs).
> 
> >
> > - control positioning is especially difficult
> 
> If you mean MFC or pure win32, most probably it is true. But don't
> forget there are a lot of other GUI libs around which can handle this
> problem without significant problems.

Maybe so.  The only other systems I've seen are VB, BCB and Java, each
of which have built in positioning mechanisms that are better than MFC's
on the surface, but which still fail (as in need much manual coding) for
real world applications - especially when the windows may be sized
dynamically.

> 
> >
> > - Consistency in GUI applications is difficult.  Give ten
programmers a
> > lower level GUI API and they'll turn out ten applications each with
a
> > different look and feel.  I don't want to have to remember that step
> > size for our company is always '5', for instance.
> 
> Interface proposed by me can and should have default values as well.

That is where I was headed with the traits mechanism.

> 
> > If we head in the direction we've been talking we would also provide
a
> > cross platform lower level API where you could get more control and
do
> > things like what you describe below.  I hope that most programmers
would
> > find it unnecessary though.
> 
> IMHO this interface is must.

I think it will also be important that elements of this low-level
interface integrate seamlessly with the upper level on - you can use the
higher level abstracts but do some things manually. 

Brock