Re: Should AtkDocument use GdomeDocument ?



Bill Haneman <bill haneman ireland sun com> writes:

> Hi:
> 
> I think that we have completed our definitions of interfaces needed
> for accessibility support, with one exception: we have received much
> support for an AtkDocument interface that exposes a w3c-type DOM, for
> those accessible components that naturally deal with DOMs internally
> such as widgets displaying XML/HTML content, possibly others. 
> Probably an HTML plugin of any sort will want to implement
> AtkDocument, the Mozilla gecko engine will export something that will
> be bridged to the same interface in the GNOME Accessibility SPI.
> 
> So, my question has to do with the best way to do this in GTK+.  I am
> a little reluctant to introduce a dependency on gdome, though gdome
> seems the natural way of exposing DOM in Gnome.  I am soliciting
> opinions on how we should define the datatypes and methods in
> AtkDocument - if we had access to a C definition of DOM, we could just
> have a single method, getDocument (), and have all the rest of the
> functions defined elsewhere.  I suppose my question is, what level of
> dependency on gdome2 is deemed acceptable, should we use libxml2
> instead (somehow?), and to the extent that we need to hide our use of
> gdome2 in our implementation library, how can we do this in the ATK+
> headers ?

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

Regards,
                                        Owen




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]