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

[David Bolter <dtb gnome org>]

At risk of seeming like all we do is agree with each other, I have to
say I agree with Will regarding the goal of representing what is on the
screen in a way that photon and non-photon dependent people can
collaborate.  I'm also wondering if my suggestion (of a list of tables)
might be confusing when cell navigation (or column ordering) is
considered... for example when down arrowing from the last row in the
"first table"... we jump to the first row in the "second table"... which
would be odd perhaps.  And doing things like reording a column would
affect all "tables" which might not be user-expected.

... but there I go thinking functionally again ;)

cheers,
D
Willie Walker wrote:
> 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
>
> _______________________________________________
> Gnome-accessibility-devel mailing list
> Gnome-accessibility-devel gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel