[boost] Re: GUI sublanguage ?

From: Bohdan (gejrlaug_at_[hidden])
Date: 2003-08-06 18:46:26

"Brock Peabody" <brock.peabody_at_[hidden]> wrote in message
news:002401c35c59$465e0f40$580a10ac_at_npci.com...
>
> Because for a pretty large number of applications you can really
> simplify your code a lot by relying on the GUI system to 'do the right
> thing':
>
>    using boost::gui;
>
>    void my_action() {...}
>    void progress_action(int tick) {...}
>
>    gui::show( "sample boost application",
>               column ( button ("click it", &my_action),
>                        progress (100, &progress_action)));
>
>
> 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 ?

> I want my applications to be as simple as possible, and
> to all look the same.

Generally GUI applications are semantically complicated.
Forget about "universal cure" from this. Everithing you can
do is to symplify development in some cases.

> If the GUI library picks the 'best' settings for
> the platform automatically, the individual programmer doesn't have to
> think about it.  Everything just works like it should.  To take a few
> things from your snippet that are suspect to me:
>
> >     w.width( 400 );
> >     w.height( 200 )
>
> Where do 400 and 200 come from?  This seems arbitrary to me.  The GUI
> system should be able to tell how to size itself.

Have you invented universal algorithm for window size/position ?

>
> >     b.align( alignment::vcenter | alignment::hcenter );
>
> 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.

>
> >     pb.min( 0 );
> >     pb.max( 100 );
> >     pb.step( 5 );
> >     pb.smooth( true );
>
> 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 :))

>
> 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.

> Where you can have specified such things as whether or not your progress
> bars are smooth and what the step size is.  Maybe you could even do it
> at run-time.
>
>       get_my_company_gui_traits().show("sample boost application",
>          ...
>
> My motivation for the design of this again:
>
> - 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.

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.
      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.

>
> - 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.

> 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.

regards,
bohdan