[boost] Re: Re: GUI library - another one

From: Max Motovilov (max_at_[hidden])
Date: 2004-03-03 16:05:08

"Peter Dimov" <pdimov_at_[hidden]> wrote in message
news:038301c40150$3f870040$1d00a8c0_at_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...