Re: [g-a-devel]GtkTextView and images



On Mon, 2003-01-13 at 13:25, Padraig O'Briain wrote:
> The GtkTextBuffer in a GtkTextView may contain images. See the GTK+ test program 
> testtext with Test Example.
> 
> It is not clear to how how we should present the images using the ATK API. 
> Should these images be children of the GailTreeView?

We should follow the convention discussed for other types of text
content, for instance HTML pages and Star/OpenOffice documents.

There is a previous email threads somewhat relevant to this topic:
http://mail.gnome.org/archives/gnome-accessibility-devel/2002-November/msg00007.html

The approach we have proposed for HTML and 'word processing' documents
is that each paragraph (generally) be a separate 'accessible', where
possible.  In the case of embedded images, there are to possibilities:

* images that text flows around

* images that are anchored to a particular offset in the text.

In the first case, I think the images should be siblings of the text
objects, and the EMBEDDING AtkRelations would handle the relationship
between them.  In the second case (which is, I believe, the GtkTextView
case), we discussed using AtkHypertext + AtkHyperlink instead, within an
attribute on the hyperlink object indicating that it is 'inline'.  I
need to look again at AtkHyperlink to see if we already have support for
determining whether a link's object is 'inline' or not.  (Hyperlink is
the only interface we have for associating one object with a particular
text offset). 

In the case of a GtkTreeView with a treecell containing both text and
images, I suggest that either the text and images be siblings, or that
the cell implement both AtkImage and AtkText.

-Bill

> 

> Padraig
> 
> _______________________________________________
> Gnome-accessibility-devel mailing list
> Gnome-accessibility-devel gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
-- 
Bill Haneman <bill haneman sun com>




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