[Gtk-sharp-list] Serialization Compliance Problems

John Luke jluke@users.sourceforge.net
Sun, 15 Aug 2004 17:49:46 -0400


Hello,

As far as I know, the things you mention are all closely associated
with either System.Drawing, gdiplus, or System.Windows.Forms.  In my
opinion, that means they are all likely to have the same assumptions,
like the Items property or similar idea you mention. That is what I
meant by SWF specific (your architectural guidelines), not that it is
tied to SWF classes.  It would be much more interesting if you could
say, "It works also with Avalon, SWT, AWT, Swing, wxWidgets, QT, but
not Gtk." if you really intend for it be a cross-toolkit tool.  I
would be happy to find out I am wrong.

So I think someone should be able to add support for what you need,
but I'll have to let others speak on the details of what it will be. 
I agree at least some similar ideas will be needed for a Gtk#
designer.

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.
> 
> 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
> >
> >
> >
> >
> 
>