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

From: Peter Dimov (pdimov_at_[hidden])
Date: 2004-03-03 16:58:28

Max Motovilov wrote:
> "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 :)

Hmm, it looks like you have a DOM hammer and you see a GUI nail. ;-) A
widget graph can be represented as a DOM but from where I sit it's simply
not needed. No, my RAD tool does not recreate anything (note present tense
here), when you change (the equivalent of) a label's text it just calls (the
equivalent of) l->set_text. It only serializes (to XML, binary, or whatever
the archive du jour is) when I save the widget graph to a file. With an
appropriate query engine, you should be able to do XPointer/XPath on a
widget graph directly if you feel so inclined, although I'd probably prefer
a visitor approach.

Anyway, I have tried the serialization approach and it works. I haven't
tried a DOM-based graph representation (probably because I haven't grown
accustomed to the DOM hammer yet), so I can't say how well it would perform.