
"Peter Dimov" <pdimov@mmltd.net> wrote in message news:038301c40150$3f870040$1d00a8c0@pdimov2...
Not a problem. You can always serialize your widget and capture its current state into XML.
Looks to me like this is all about tradeoffs. A runtime UI data repository (DOM-based, perhaps) simplifies widgets (well maybe not, it is all a matter of the right wrapping of the interfaces after all - what is easier, writing marshalling code or using property mechanism to expose your essential data?) and promotes flexibility: with serialization-based approach your RAD tool may have to re-create all or large part of application's windows every time a change is made, same applies to user-customizable UI elements (menu editing, stylesheets etc.). Also, the ID tag example may be extended to allow XPointer/XPath addressing at which point you'll have to give up the serialization approach for sure :) On the other hand, XML marshalling is much more lightweight, it may not even require a DOM parser (you'll still want an XSLT engine to support stylesheets, but at least this way you can invoke it in a child process). For a Boost library this is a big advantage since we'll have to provide a DOM parser as part of Boost otherwise. In fact, compiling XML to source code provides another benefit aside from C++ code embedding: it can be implemented fully outside of the library. You can pretty much generate C++ code with XSLT and with good library primitives/syntax the actual "compiler" may turn out to be small enough to be easily customizable by users. And this way we are not tied to a specific engine either because XML parsing is never even required at run time. It just so happens that in _my_ mind the benefits of DOM outweigh the liabilities. Therefore I am rather skeptical about adding a GUI library to Boost: one compact enough to be there will not be enough things to enough people to get wide acceptance. Yet I'd be glad to participate in design/development of an open source GUI library that would promise to significantly improve upon the likes of Qt. ...Max...