[Gtk-sharp-list] Serialization Compliance Problems

Todd Berman tberman@off.net
Sun, 15 Aug 2004 17:36:14 -0400

The problem with this, is that there are some ctors that won't function
properly, as certain properties are only settable when the ctor is done.

Forexample, setting the WindowType in a new Gtk.Window is only possible
when you create it, so a default () ctor would not allow this to be

There are other examples of this, where there are ctors that allow you
to modify things that are not changeable later in the objects lifecycle.

This is a gtk+ issue, that we are basically unable to workaround.

How would MyXAML handle cases such as this?


On Sun, 2004-15-08 at 17:14 -0400, Marc Clifton 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.
> There is nothing in the MyXaml core parser that is SWF specific.  What 
> is required is only a compliance with some architectural guidelines 
> which I have previously written about.  These guidelines aren't 
> something that is MyXaml specific but applies to all XAML-like generic 
> parsers, and I agree with you, that it doesn't seem like it would take 
> too much work.  Doing so would actually be of benefit to GTK#, IMO, 
> because it would bring GTK# more in line with the .NET architecture, and 
> therefore would satisfy serialization requirements.
> As it is now, without writing a custom parser to support GTK# classes, 
> properties, methods and events, how would you go about implementing a 
> front-end designer, for example?  It seems like by following some simple 
> architectural guidelines in GTK#, one could avoid a lot of extra work by 
> simplifying current serialization issues.
> Marc
> John Luke wrote:
> >Hello,
> >
> >Speaking only for myself, I think your review is incomplete.  Adding
> >default constructors would be trivial, but no-one had previously
> >requested it, and you yourself seem to indicate it is a deficiency of
> >MyXAML.  The other issues, I think you will find that you are
> >depending on many things that are SWF specific, I wonder what other
> >toolkits would fit that description without some effort.  I looked
> >(very briefly) but did not find a list of toolkits supported by
> >MyXAML.
> >
> >In any manner, I think that .NET guideline support will have a
> >priority over this, unless someone takes an active role in doing so,
> >it doesn't seem to require too much work.
> >
> >
> >----- Original Message -----
> >From: Marc Clifton <webmaster@knowledgeautomation.com>
> >Date: Sun, 15 Aug 2004 13:59:25 -0400
> >Subject: [Gtk-sharp-list] Serialization Compliance Problems
> >To: gtk-sharp-list@ximian.com
> >
> > Hello all,
> > 
> > I have done a cursory review of using GTK# with MyXaml and I've found
> >it to be lacking some basic tennets of XAML-friendly classes.  I've
> >posted the review here:
> > 
> > http://myxaml.com/marcclifton/archive/2004/08/15/433.aspx
> > 
> > and I'm wondering if the GTK# group has any interest in making GTK#
> >compatible with serializing object graphs into XML using a generic
> >parser such as MyXaml.  Personally, I feel that this would be a
> >worthwhile endeavor.
> > 
> > Regards,
> > 
> > Marc Clifton
> > _______________________________________________ Gtk-sharp-list
> >maillist - Gtk-sharp-list@lists.ximian.com
> >http://lists.ximian.com/mailman/listinfo/gtk-sharp-list
> >
> >
> >  
> >
> _______________________________________________
> Gtk-sharp-list maillist  -  Gtk-sharp-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/gtk-sharp-list