Re: [gtk-list] Re: Serialization (was: Re: GTK questions)
- From: Andrew Thomas <andrew cogent ca>
- To: gtk-list redhat com
- Subject: Re: [gtk-list] Re: Serialization (was: Re: GTK questions)
- Date: Thu, 22 Jul 1999 10:09:39 -0400
Tim Janik <timj@gtk.org> writes:
> > I want to create a serialization library (like Java's
> > java.io.serializable or Python's pickles) for GTK objects. It
> > seems like the best I can do is to create my own object inheriting
> > from GtkObject and make everything that inherits from that
> > serializable.
> >
> > 2) a convention that all serializable objects must use GTK
> > arguments for their
> > properties.
>
> yes. unfortunately, gtk arguments are still not thoroughly
> implemented throughout the toolkit, and another drawback of the arg
> system is that object modifications are usually not routed through a
> single point, so you don't get notification upon certain object data
> changes and thus can not reliably implement supression of default
> value serialization.
.... and another problem is that much of the information regarding the
state of contained objects is not available outside of the private
representations of the container objects, and even then, that
information appears to be contained in code, not data. For an example
of this, GtkContainer has a "child". GtkHBox is-a GtkContainer, but
it implements a "child list" and ignores its "child". Only in code is
this fact available. I think that GTK would need a substantial (and
much deserved IMHO) re-thinking of the data/code division before you
would be able to serialize objects and object hierarchies with any
completeness. I know that this would generate an "incompatible" GTK+,
but I for one would be willing to bite the bullet to get a better
architecture out of it.
> pretty much, though it sounds like you end up duplicating a bunch of
> code that is already contained in gle. it might be worth looking into
> splitting up some of gle's code, if you end up really implementing
That does not sound like it would fit the needs of non-C language
bindings, if gle is really writing C code to address some of the
issues.
Andrew
-----
Andrew Thomas, President, Cogent Real-Time Systems Inc.
2430 Meadowpine Boulevard, Suite 105, Mississauga, Ontario, Canada L5N 6S2
Email: andrew@cogent.ca WWW: http://www.cogent.ca
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]