RE: [boost] Re: GUI Library Proposal for a Proposal

From: Jared McIntyre (jmcintyre_at_[hidden])
Date: 2004-11-05 13:47:33

>If you have a good abstraction - then the ability to "plug in" the
>underlying implementation (through various mechanisms) means you are not
>tied to WxWidgets. This also means that conversely, you CAN take
>advantage of something in WxWidgets (or qt, or win32 or whatever) if you
>so desire.
>
>Boost::gui should not be trying for a kitchen sink approach (like
>WxWidgets or Qt), but instead would provide a simple and clean
>abstraction for common functionality.
>
>I will always (or frequently) have to write WxWidgets specific code or
>os specific code, but having a abstraction available from boost would
>mean most of my code would be portable across framework.

Agreed, but I'd like to add a few extra thoughts on how I'd want it to work.

When I'm programming my apps, I want to think about actions that I 
want to expose to the GUI.  I want to code in terms of PingServer() 
instead of OnPingServerButtonPress(), and then have an easy way to 
programmatically tie a button action (or some other control's action) 
to triggering my PingServer() functions.  These actions are cross 
platform, but in most platforms, I have to write that tieing code, 
but its a highly repetitive, pattern based process, so I shouldn't 
have to 
(<http://developer.apple.com/documentation/Cocoa/Cocoa.html>see Cocoa 
docs).

I also want to expose the data in my models to the GUI in such a way 
that I can bind them easily to the GUI.  This is next to impossible 
to do cross platform since every GUI has their own concept of string, 
etc. So, I end up writing all  the code to do that as well, which is 
also very repetitive and pattern based and should be abstractable 
(which the Lit Window library seems to do, though I haven't played 
with it yet).

If done properly, the abstraction layer shouldn't require me to think 
about buttons, comboboxes, layout, etc.  I'll do that in the platform 
specific GUI API that I choose to develop in.  Instead, it should 
connect the platform specific GUI I've developed, to the 
cross-platform processing and data layer I've developed.  It should 
really just focus on handling binding data between the two and tying 
user generated GUI actions to my own processing.

I will always want to think platform specific code when I am thinking 
about form layout, new control development, etc, but I shouldn't have 
to think about it when I am tying my processing and data layers, 
because unlike the GUI, the processing and data layer do the same 
thing on each platform.

Jared McIntyre