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
>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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk