[Gtk-sharp-list] Serialization Compliance Problems
Sun, 15 Aug 2004 18:53:34 -0400
Great discussion. My replies follow:
>It looks like Xaml is just to close to a particular API: it relies on
>the framework class structure, instead of abstracting the user
>interface away from the API. E.g. the tags and attribute have a direct
>mapping onto the class and properties of a particular API, which
>doesn't help in making the approach reusable for other widget sets.
This is true, but I'm not sure what the you're getting at here. In
specific, when writing GTK# code imperatively, I'm working with the GTK#
framework, classes, and class structure. If I want to work the GTK#
declaratively, I can't because it's missing certain key features that
let me construct the necessary object graphs. With imperative code,
switching to another widget set is essentially a rewrite. With
declarative code, there is the possibility that all you need to do is
apply an XSLT!
>I don't agree you need to have parameterless constructors to create a
>"declarative markup parser". If you see this as a requirement for a
>declarative way to create a UI, than you say every widget set API
>should have them.
Well, yes, I guess that is exactly what I'm saying. I don't see that as
an issue, and as I mentioned in the blog entry, I think supporting
parameterless constructors (not exclusively, but inclusively) is simply
better coding for the framework. Any stable, predictable platform
should essentially allow properties to be set in any order, and
supporting parameterless constructors is a step in that direction.
>In my experience Gtk# was easier to support with a "declarative markup
>parser/renderer" than SWF, because of its better layout management
>system. We did the exercise with Uiml.net, a .Net based UIML
>renderer that can use SWF and GTK#, SWF on compact and a tiny bit of
>deprecated Wx.Net. It is not as powerful for Gtk# as Glade-XML is, or
>for SWF as MyXAML is, but UIML provides a much better abstraction and
>could be as powerful (-; . We do have a little bit of widget-set
>specific code for each widget set, but only the absolute minimum.
Well, that's as I expected, that some widget specific code is required.
With a little bit of work, I think this could be eliminated.
>Your second shortcoming for Xaml was a little bit confusing ("how
>collections are handled"). Doesn't this indicate the close relation of
>Xaml with a particular API?
Hmmm. Perhaps, but again, why is this an issue? While it would be easy
enough to add support in MyXaml for a collection tag that knows how to
invoke the Add method of the widget's Container base object, this begs
the question, do you add to a generic parser the specific functionality
required to support a particular toolkit, or do you enhance the toolkit
to support generic parsing using standard .NET collection classes (or,
as a compromise, do you expose your own container implementations if
you're not using .NET's collection classes)?
> https://sourceforge.net/projects/uimldotnet/ ,
>Gtk-sharp-list maillist - Gtkfirstname.lastname@example.org