Re: [g-a-devel] need help implementing a widget in atk

[Willie Walker <William Walker Sun COM>]

Hi Mike:

As was suggested by Li Yuan, the first view looks a lot like one of the 
gtk-demo demos.  In particular, the "Tree View"->"Tree Store" demo: 
http://master.gnome.org/~wwalker/Screenshot-CardPlanningSheet.png

In accerciser, this shows up as a "tree table" with a very flat 
hierarchy.  The column headers are direct children of the tree table, 
and they have a role of "table column header".  The individual cells 
are also direct children of the tree table, and they have a role of 
"table cell".  For the entries which group things, your instinct was 
correct - the first cell in the row holds the name and the rest are 
blank.

For the second view, it looks a lot like a list of labeled "layered 
pane" objects.  You can see an unlabelled layered pane object in the 
gtk-demo application via the "Icon View"->"Icon View Basics" demo: 
http://master.gnome.org/~wwalker/Screenshot-GtkIconViewDemo.png.

I do agree with David Bolter that these are logically a lot like a list 
of tables.  As a screen reader developer, however, I constantly wrestle 
with the notion of reading the screen versus accessing the data model.  
I tend to err on the side that it's important for the user to get at 
both the data *and* how the data is represented on the screen.  My main 
use case is where a blind person and a sighted person are collaborating 
at a distance and/or a blind person is teaching a sighted person how to 
use the GUI.  With these, the language used to describe the GUI is kind 
of important, and should closely resemble what is being displayed.

Will

On Oct 28, 2008, at 10:00 PM, Mike Gorse wrote:

> Hi all,
>
> I am trying to map the MWF ListView control to atk (via UI 
> automation). I don't believe there is a gtk control equivalent to it, 
> and I want our code to work well with Orca for instance, so I wanted 
> to ask if anyone wanted to give input as to what I should do to map 
> it.  It has several "views," so a program can dynamically change the 
> appearance by changing the View property.  So it is effectively 
> equivalent to having several types of widgets to consider.
>
> The Details view is a lot like a GtkTreeView.  I put a screen shot (at 
> Will's request) at http://mgorse.freeshell.org/listviewdetail.png.  It 
> has a table of books with three columns (title, author, and copyright 
> date). The books are divided into "groups" based on the first letter 
> of the title, so there are three groups ("C", "M" and "P").  I'm 
> thinking that there should be a control with a role of 
> ATK_ROLE_TREE_TABLE with the data represented as table cells, but then 
> I'm not sure how to represent the group names.  Should they just be 
> given rows in the table with the name as the first column and other 
> columns on the row being blank?  Also, based on some testing that I've 
> done, gail returns -1 when get_row_at_index is called for an object 
> that is not at the root level of the tree view.  Is this expected 
> behavior that we should emulate (in which case all of the actual data 
> would have a row of -1 if groups are used)?
>
> There are other views that display list items in grids 
> (http://mgorse.freeshell.org/listviewlargeicon.png), each "group" 
> having a separate grid.  UIA exposes a List control which can contain 
> multiple Group controls, each of which contain ListItem controls.  The 
> Gropu controls implement an interface similar to AtkTable.  It would 
> probably be simplest for me to implement a hierarchy such as the 
> following in atk, since there would be a one-to-one correspondance 
> between UIA and ATK objects:
>
> ATK_ROLE_LIST
>   ATK_ROLE_TABLE
>     ATK_ROLE_TABLE_CELL
>     ...
>   ATK_ROLE_TABLE
>     ATK_ROLE_TABLE_CELL
>     ...
>   ...
>
> Let me know if any of you think that something else makes more sense. 
> Role names are easy to change.
>
> Thanks,
> -Mike G-
> _______________________________________________
> Gnome-accessibility-devel mailing list
> Gnome-accessibility-devel gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel