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