Re: Should AtkDocument use GdomeDocument ?

[Owen Taylor <otaylor redhat com>]

Bill Haneman <bill haneman ireland sun com> writes:

> Owen Taylor wrote:
> > 
> > A dependency on libxml2 is not acceptable for GTK+-2.0, no. In fact,
> > any required dependency on another external library really can't
> > be feasibly added at this point; that would apply to gdome2, even
> > if it didn't depend on libxml2.
> > 
> > (gdome2, from a quick glance, seems to be a much more straightforward
> > implementation of the DOM than the original gdome, which is a good
> > thing. However, I'm not sure if it is useable for something like
> > Mozilla without having to try and maintain a mirror of the entire DOM
> > tree.)
> 
> Mozilla has their own problems in implementing this ;-) but they will
> be exporting the DOM in some form.

It seems that what is wanted (but what I really don't believe belongs
in ATK) is a representation of the DOM, not as concrete objects
as gdome2 is, but as set of GObject interfaces that are the 
mappings of the IDL fike.
 
> OK, so how should we do this, if not via gdome2 ?  We do need to do it
> somehow, though arguably the set methods of the API don't need to be
> exposed to GTK... should we rely on an anonymous struct of some sort,
> whose contents is opaque to GTK?  What's the best way to pass
> typed-but-opaque "somethings" around in GTK+ ?

Well, for all practical purposes, the root node of the typed object
heirarchy is GObject, so I'd consider a "GObject *" equivalent to
"Object" in Java.

(Not quite true, you can have parallel heirarchies to GObject, so
GTypeInstance is sort of a base-of-the-base instance. But that
is best ignored in most cases.)

The more generic conception of "a typed something" is GValue:
GObject's variant type, which allows the something to be a integer, a
string, a boxed type like a rectangle, etc. But that doesn't seem to
quite right here.

Regards,
                                        Owen