[Gtk-sharp-list] Serialization Compliance Problems
Kris Luyten
Kris Luyten <kris.luyten@gmail.com>
Mon, 16 Aug 2004 00:20:03 +0200
Hi Marc,
On Sun, 15 Aug 2004 17:14:16 -0400, Marc Clifton
<webmaster@knowledgeautomation.com> wrote:
> Hello John,
>
> Yes, the default constructors would appear to be trivial, but no it's
> not a deficiency in MyXaml. As to other MyXaml supported by other
> toolkits, many toolkits by their very nature work well with MyXaml
> because they are implemented so as to support serialization. In
> particular MyXaml works 100% with VG.net, a vector graphics engine and
> which serializes to MyXaml, and near 100% with other third party
> toolkits such as DevExpress, DevComponents and Infragistics.
I also posted a comment on you blog entry. I'll repeat it here. First
of all I am not a Xaml expert, and maybe somewhat biased in my opinion
because I implemented something similar. Feel free to correct me when
I am wrong.
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.
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.
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.
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?
[1] https://sourceforge.net/projects/uimldotnet/ ,
research.edm.luc.ac.be/kris/projects/uiml.net/
Regards,
Kris