[boost] Re: GUI Library Proposal for a Proposal

From: George van den Driessche (grebe_at_[hidden])
Date: 2004-11-08 10:17:42

> From: John Torjo <john.lists_at_[hidden]>
> Subject: Re: [boost] Re: Points vs Vectors / GUI Library Proposal for
>
> To: boost_at_[hidden]
> Message-ID: <418F48F8.9050002_at_[hidden]>
> Content-Type: text/plain; charset=us-ascii; format=flowed
>
>
> > Back on the subject of a GUI library: I understand the motivation -
> > that's where wxWindows arose. And I realise that nowadays a GUI library
> > could be done in a much more modern C++ style. But my question is: is
> > C++ the right language? I don't want this to descend into a religious
> > war - C++ is my favourite language, but it isn't the best language for
>
> I would say so ;) For instance, you can abstract away a lot of stuff
> (true binding of data to GUI controls):
> http://www.torjo.com/win32gui/save_dlg.html
>
> Also, I want to allow, in the future, to bind STL containers directly to
> GUI list controls.
>
> So, I would say a higher level language won't be of help here - because
> you would need to convert your data and send it back and forth.

Yes - this was the one major benefit that I could think of when I wrote my
original reply. But once you've exposed the data in question to the
scripting language of your choice, you gain quite a bit:
- By attaching validation routines and the like in your scripting layer, you
can tune these without having to rebuild your program, or even restart it if
you're lucky.
- You can plug data and validation routines into UI elements using your UI
design tool!
- You can also expose the resulting bindings at the application level for
things like scripting support.

> I remember the days when I used to do the UI in VB - it was quite a
> mixed feeling...

Yes, I can see how that might put one off 'higher-level' languages :)

> > every task. Would a higher-level, more dynamic language be more suitable
> > for GUI work? In a perfect world, I'd do all my back-end stuff in C++
>
> sometimes, certainly
>
> > and all the front-end development in, say, Python. By doing all the GUI
> > work in C++ instead of an interpreted language, you:
> > a) spend a lot more time recompiling.
>
> that is unfortunately true :(
>
> > b) can less easily tweak a running program to try out different ideas.
>
> We're missing a good GUI designer... But we're slowly getting there ;)

The GUI designer can't help with attaching data, validation routines or
anything else, unless those things are exposed to script.

> > c) have to spend a lot of effort to construct a domain-specific language
> > (c.f Spirit; see (a)).
>
> Not sure what you mean...

Spirit goes to great lengths to make C++ look like a language for declaring
grammars. It's a huge chunk of beautifully crafted template magic, that's
clearly taken much time and effort. Because of its size, recompiling the
parser you build with spirit takes a very long time (hence the reference to
(a)). A parser generator such as ANTLR does the same job much quicker[1].

Similarly, you've constructed an elegant way of linking data, validation
routines and UI elements together, from C++. Your usage examples are concise
and expressive. But does that justify the sheer weight of header files that
they require? One could write probably less than half as much code to
deliver similar results using Pyrex and Python. It wouldn't run quite as
fast as your code. But it would give a smaller, more versatile runtime. In
fact, there's an embryonic project to do just that at:

  http://nz.cosc.canterbury.ac.nz/~greg/python_gui/

> > d) probably end up with a bigger codebase.
>
> why so?

Because C++ isn't the tersest of languages :)

George