Re: [boost] Re: Java style GUI in C++

From: Mathew Robertson (mathew.robertson_at_[hidden])
Date: 2004-08-18 19:56:44

> >>>did you know of the existence of the following list of C++ GUI frameworks?

[snip]

>>>http://www.fox-toolkit.org/

[snip]

> I would strongly recommend that you take a look at how the GUI is done 
> in Tcl/Tk (Tkinter in Python is also based on it). It is a complete 
> different language and technology, but using the packer interface is 
> extreme fun and may give you some ideas for your own library development.
> IMHO, porting Tk to C++ (and I mean extensive use of templates and 
> operator overloading to achieve minimal syntax, not just thin class 
> wrappers) would result in *THE* GUI library for C++.

[Note: I subscribe to one of the mailing lists mentioned in this thread - ie the one mentioned above...]

On the FOX mailing list, a number of people subscribe to quite a few of the GUI toolkit mailing lists that have been mentioned.  The general consensus was that a templated approach to building GUI's, just doesn't work... and it has been tried a number of times...  The main reason is that GUI's require dynamic / run-time binding between different widgets/components.

For example:

- To bind a mouse click to an onscreen button, you may use a templated approch to the binding.
- Then you would like a keyboard shortcut to be bound to the same event

-> no problem, as both of these cases can be coded by end-programmer. In particular, it works because the library knows about these event types.

What happens if you decide to embed the Gecko HTML redering engine inside a window frame (ie so that it saves you from having to build your own HTML rendering engine)?  The problem is that you have to dynamically route messages from the foreign window, into you own event processing mechanism - which simply doesn't work with a compile-time approach.  Admittedly, this is a contrived example, but the premise holds for a number of common usage scenarios.

Also, static event mapping systems result in a N x M mapping of events to widgets.  If you have say 20 event types and 100 widgets, you end up with 200 combinations of actions that need to be coded by the end-programmer. Dynamic binding allows some toolkits to make this an N + M problem, which greatly reduces the size of your end-programmer code that needs to be written.

All that said, we are welcome to try as there are definately some pieces of widget functionality (eg event map creation) that are currently done a runtime (usually application startup), which could probably be moved to compile-time.  I personally wouldn't mind seeing a toolkit which uses templates.

On a slightly different note, as someone else mentioned, and I would aggree with, programming GUI's using listeners (Java style) is more work than using an event handling mechanism.

regards,
Mathew Robertson