[Gtk-sharp-list] Serialization Compliance Problems

[Marc Clifton]

Hi Kris,

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[1], 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)?

Marc

>[1] https://sourceforge.net/projects/uimldotnet/  ,
>research.edm.luc.ac.be/kris/projects/uiml.net/
>
>Regards,
>Kris
>_______________________________________________
>Gtk-sharp-list maillist  -  Gtk-sharp-list@lists.ximian.com
>http://lists.ximian.com/mailman/listinfo/gtk-sharp-list
>
>
>  
>