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

From: Peter Dimov (pdimov_at_[hidden])
Date: 2004-03-03 17:45:33

Max Motovilov wrote:
> "Peter Dimov" <pdimov_at_[hidden]> wrote in message
> news:040801c4016a$abe26a80$1d00a8c0_at_pdimov2...
>
>> not needed. No, my RAD tool does not recreate anything (note present
>> tense here),
>
> Duly noted. Is it something I can look at?

No, sorry.

>> when you change (the equivalent of) a label's text it just calls (the
>> equivalent of) l->set_text.
>
> Which means it knows about SomeInterface::set_text(). Will it handle a
> custom widget with a custom property just as smoothly? How much
> effort on part of a custom widget developer is required?
>
>> appropriate query engine, you should be able to do XPointer/XPath on
>> a widget graph directly if you feel so inclined,
>
> That won't give me a pointer to the run-time instance of a widget,
> would it?
>
>> 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.
>
> HTML GUIs. We can argue all night what "well" is, but you have to
> agree it's been tried very extensively.

I have to admit that you do raise some interesting points. A widget graph
can indeed be given a (restricted) DOM interface (it does not need to be
implemented as a generic DOM graph) so that a XPointer/XPath engine can
traverse it. The UI editor/builder can use an XSD schema to enumerate a
widget's properties and perform validation. XSLT can rewrite a GUI graph.