GNOME.org
 

Re: inaccessible treeviews and tables


On 07/10/2014 08:25 AM, Peter Vágner wrote:

Hello,
Definatelly calling set_accessible_type is working well over here. I
have tried to append a randomly generated number to the string I am
getting and I got different results for different entries in the
get_name method on my custom GTKRendererCellAccessible subclass.
Also I have tried to examine if the results are all right while
drawing on the renderer and they definatelly are.
Do I have to have implement something more on the
GTKRendererCellAccessible subclass to make it work? Currently I do
only have get_name in there. I assume GTKRendererCellAccessible has a
property named renderer and that is the reference to coresponding
GTKCellRenderer object.
I am trying to compare my implementation to that found in the
gtktextcellaccessible.c however I am really confused as none of the
GTK_Text_Cell_Accessible... methods are accessing renderer property so
how do they access the renderer data?


After taking a look to the code of gtktextcellaccessible and
gtkcellaccessible. GtkCellAccessible defines a method called
update_cache. The treeview will call this method each time it concludes
that the info would change. Each cell accessible subclass are supposed
to redefine this method, in order to update the info of the accessible.
Then all the accessible methods (get_name, etc) would use the
information gathered at update_cache.

So, about the lack of methods accessing to the renderer property. If you
take a look to the update_cache method at gtk_text_cell_accessible, this
method gets the cell, ask for the renderer, and then it asks for the
text property. With that it updates a private property. As this is the
point where it is getting the data, it also send the usual accessible
notifications (like changes on accessible name). Then, get_name on this
accessible, uses the information stored (cached) on the private structure.

Taking into account that all the cell renderers redefines this method,
you would need to redefine it as well.

Best regards


Greetings

Peter

On 09.07.2014 17:55, Peter Vágner wrote:

Hello,
I am reading a bit on vala ownership and I am afraid that's not my
issue here.
Now a speculation.
Do I have to pass Gtype of a class to the set_accessible_type or do I
have to first instantiate an object of that class?
In vala all this is just a bit of code that generates quite a lot of
c code. Heh but in order to make it work it has to be understood I am
afraid.

Thanks and greetings

Peter



On 09.07.2014 17:50, Piñeiro wrote:

Good to see that you are advancing here. It is also good that for for
the first time someone is facing implementing extra accessibility
support on vala, and you even found a problem (lack of some gtk-a11y
headers on vala)

Thanks for your interest and your work on fixing this 3rd party
applications and vala.

Best regards

On 07/09/2014 05:03 PM, Peter Vágner wrote:

Hello,
Awesome It did not take methat long to add another bit of the puzzle.
Again this is a vala specific issue. It appears I need to cast
renderer property inside my derived RendererCellAccessible class to my
derived CellRenderer class.
Now I am getting the same return value for all the treeview entries.
Again to sum it up there is a treeview, that treeview has a
treeviewcolumn which has a cell renderer. I am trying to implement a
proper RendererCellAccessible so the same data that is drawn using the
cellrender will become accessible.
I suspect this has something to do with the fact name property on the
accessible is a weakref. In vala that's called the ownership. I have
created a local variable holding the result and maybe that is not
getting cleaned or something. This is really something I need to
understand better.

Greetings

Peter



On 09.07.2014 14:33, Peter Vágner wrote:

Hello,
Okay now I have got it working to some degree.
My recent issue was that I had put the constructor of my derived
RenderCellAccessible class wrong thus set_accessible_type was never
called on my CellRender subclass.
Heh guess what, now I am facing another issue.
I am unable to get a reference to the coresponding CellRenderer
object. There is a renderer property on my resulting accessible
object but it most likelly points to some generic CellRenderer
instead of my custom derived one. Shouldn't I be able to get that via
its constructor for free?

Thanks and greetings

Peter




On 08.07.2014 23:18, Peter Vágner wrote:

Hello,
This is really strange. I thought I have more or less understood how
this should work finally.
Then I have found out that vala hides all the GLib stuff because in
most cases it's not really usefull but still there is a simple
typeof() method which creates GType of a given class. Then I have
managed to talk to helpfull guys at #vala and finally found out
vala-0.24 does not include gtk-a11y.h so I had to tweak that locally
until I try to report a bug and it'll get adressed.
Now it all compiles fine but unfortunatelly it appears not to work
as intended. Also I assumed that renderer property on my custom
GTKRendererCellAccessible subclass will point to the corresponding
CellRenderer. Unfortunatelly it does not.
So I  have tried to just return plain statically typed string as a
result of get_name method on my RendererCellAccessible subclass.
That is not seen when testing with orca.

Here is the vala code: http://pastie.org/9369194
And here is the resulting c code: http://pastie.org/9369215

I know that's not verry clever way posting automagically generated c
code but now I have verry mixed feelings and hopefully I only need
to take a break. Might this be really that unintuitive or is it
likelly I am too .... You know what I mean.
Or alternativelly might the vala bindings be somewhat buggy? I am
afraid that's not verry likelly at least not in this case.

Greetings

Peter


On 08.07.2014 14:38, Piñeiro wrote:

Hello,

no, your problem is not related at all with that thread. The
problem I
pointed on that thread was solved (take into account that that
thread
has almost 2 years old).

On Glib every class (GObject) has a given GType (see [1][2]).
For the
task that you are doing, take as reference gtkcellrenderertext and
gtktextcellaccessible.h. In this case "text" is the "custom" cell
renderer I was talking about. As usual (usual glib boilerplate for
C-code), gtktextcellaccessible define some macros related to the
new
type. One is GTK_TYPE_CELL_ACCESSIBLE, that points to an also new
method
gtk_text_cell_accessible_get_type. In general, when you declare
a new
GType, you need to provide a method that returns this new GType. In
order to provide the implementation of that method, right now
there is
some utility macros like G_DEFINE_TYPE [3].

In summary, what GtkTextAccessible does is declare
GTK_TYPE_CELL_ACCESSIBLE and gtk_text_accessible_get_type on his
header,
use G_DEFINE_TYPE to implement the get_type method on his source
code.
Then GtkCellRendererText calls
gtk_cell_renderer_class_set_accessible_type using
GTK_TYPE_CELL_ACCESSIBLE.

So, for the case of C, you have some examples of how to do this.
The
different is that custom cell renderer is written on Vala. Being
as it
is Vala, when created the equivalent C-code, all this would be the
same,
so it is really likely that you would be able to get the GType
from a
class that you are defining (in this case this
ContactListCellRenderer
accessible class). Unfourtunately, my experience with Vala is
zero. I
just know what it is. So I would not be able to tell you how to do
that.
In any case, #vala channel at Gimpnet seems full of people.
Probably
they could help you.

About your question in relation to init methods: GObjects are an
Object
Oriented add-on to C, so they need to do some manual handling in
order
to register the type and create the new object and class. You can
find a
detaile information here [4], but probably for now you can just
forget
that, and just follow the rules. That method needs to be called
on the
class_init method. Take a look to what GtkTextAccessible and
GtkCellRendererText are doing. Those are an example of a custom
cell
renderer and his accessible object.

Best regards

[1] https://developer.gnome.org/gobject/stable/
[2] https://developer.gnome.org/glib/2.40/
[3]
https://developer.gnome.org/gobject/stable/gobject-Type-Information.html#G-DEFINE-TYPE:CAPS


[4]
https://developer.gnome.org/gobject/2.40/chapter-gobject.html#gobject-instantiation



On 07/08/2014 08:36 AM, Peter Vágner wrote:

Hello,
I have subclassed GTKRendererCellAccessible, implemented basic
get_name method in my subclass taking advantage of reference to
the
CellRenderer.
However what I am unable to workout is how do I get a proper
GType of
my subclass so I can pass it to the
gtk_cell_renderer_class_set_accessible_type () on my CellRenderer
subclass. I assumed I am missing something verry obvious but I
then
went back to the earlier discussion you pointed me to a while
ago...
https://mail.gnome.org/archives/gtk-devel-list/2012-August/msg00050.html


. I can find no method get_type or similar on
GTKRenderCellAccessible
either directly implemented nor inherited. So either I am missing
something simple or this is more complicated than I might imagine.
Also the help text for
gtk_cell_renderer_class_set_accessible_type ()
states it's advised to call this from the init method on the
CellRenderer. I am afraid this is really basic and I might be
able to
research it else where but what is an init method in this case? Is
that a constructor or a method called init? I haven't see no
method
like this while looking at the GTK docs.

I apologize for taking your time but I am really interested in
being
able to do this.

Greetings

Peter

On 07.07.2014 16:47, Piñeiro wrote:

Good catch, I didn't realize that ContactListCellRenderer. Sorry,
I'm
not used to search through Vala source code.

Looking at that code, there is a variable called "entry", that in
most
cases is the contact. On render_name it uses that variable to get
the
name. On render_userstatus it uses that variable to render the
status. A
ContactListCellRendererAccessible would need to use this "entry"
variable to expose the name and status on a custom
implementation of
AtkObject.get_name and AtkObject.ref_state_set.

Looking for
https://developer.gnome.org/accessibility-devel-guide/stable/gad-custom.html.en



has two problems:
      * It is outdated.
      * It is intended as a guide to extend widgets
accessibility.
A cell
renderer is not a widget.

What do you mean for gtk_get_accessible? AFAIK, that method call
doesn't
exists. There is a public gtk_widget_get_accessible that
returns and
accessible type, and a private one
_gtk_cell_renderer_get_accessible_type, that returns a type.

Subclassing GtkTreeViewColumn will not get anything. As
explained, it is
the cell renderer the one that gets the focus and renders the
content,
the problem there is about the custom cell renderer.

So, in summary, and based on your comments and a quick look on
the code,
what it is needed to do here is:

    * Create a new subclass of GtkRendererCellAccessible
something
like,
ContactListCellRendererAccessible
    * Call gtk_cell_renderer_class_set_accessible_type on
ContactListCellRenderer class_init method.
    * Reimplement AtkObject.get_name and
AtkObject.ref_state_set on
ContactListCellRendererAccessible, using that "entry" variable to
get
the information

Thanks for all this work

Best regards

On 07/07/2014 04:07 PM, Peter Vágner wrote:

Hello,
Issue in transmission-gtk is just my guess I haven't yet
tryed to
tinker with its source code so I may really be absolutelly wrong
with
my assumption.
Venom developers are subclassing GTK_CellRenderer here
https://github.com/naxuroqa/Venom/blob/master/src/ui/ContactListCellRenderer.vala



. I can see they are also using GtkCellRendererText in order to
change
a GTK_COMBOBOX which remains accessible here
https://github.com/naxuroqa/Venom/blob/master/src/ui/ContactListWindow.vala



.
While creating my CustomCellRendererAccessible do I really have
to do
everything that is recommended here
https://developer.gnome.org/accessibility-devel-guide/stable/gad-custom.html.en



? As I said I have tried to retrieve a coresponding
accessible by
calling gtk_get_accessible(MyCustomCellRendererObject). I was
able to
manipulate that accessible and set its name and description
however by
testing with orca I have discovered changes I am trying to make
result
in changes to the parent object treeview in this case not
individual
rows which as I understand are represented by the
CustomCellRenderer.
Then I have tried to subclass a GTK_TreeViewColumn where the
CustomCellRenderer is connected to by trying to create empty
ATK_Object, overridding Get_Accessible() in my subclass. Of
course
this does not work. I haven't really understood where is the
problem
however I think It is just not possible to instantiate
ATK_Object like
all the other objects using new operator.

So Now I am lost again and I have no idea on how to possibly
move
forward. Frankly I don't feel confortable following the article
Making
Custom Components Accessible on the gnome developers wiki, it's
why I
have started exploring these things on my own hopefully
asking more
concrete questions. The only lesson I have learned so far is
that I
really need CustomCellRendererAccessible. But I don't have an
idea on
how to do that.

Thanks your patience and helpfull hints.


Greetings

Peter

On 07.07.2014 14:02, Piñeiro wrote:

Hi,

I will try to answer your question as best as I can.

As you say, sometimes a 3rd party gtk app developer creates a
custom
cell renderer in order to add some new visual stuff. The
accessibility
related are not skipped. The already in place cell renderer
accessibility is used. But if the new cell renderer uses
something
totally different to render text, then the gtk+ cell render
accessible
object would not be valid. In that case you would need to
provide a
custom accessibility object for that custom cell renderer.
For the
rest
of this email, I will call them CustomCellRenderer and
CustomCellRendererAccessible

gtk_cell_renderer_class_set_accessible_type, is just the method
that
relates a cell renderer with his accessible method. Is just a
utility
method to avoid the need to redefine the method get_accessible
for any
custom object. So for this case, once you have a
CustomCellRendererAccessible, you would need to call
gtk_cell_renderer_class_set_accessible_type on your
CustomCellRenderer.

About caring on CellRenderer: as I said, there is already an
accessibility support of CellRenderer. So probably you just
need to
focus on that CustomCellRenderer, where the information about
name and
state are stored there (that would be the difference with a
"vanilla"
CellRenderer), and then try to expose it via a
CustomCellRenderAccessible.

About that transmission-gtk: after a quick look on Venom. I
don't see
any custom cell renderer being created. As far as I see,
they are
using
GtkCellRendererText, that should be already supported. Are you
sure
that
in that case you are under a custom cell renderer problem?

Best regards

[1]
https://developer.gnome.org/gtk3/3.12/GtkCellRendererText.html

On 07/05/2014 06:20 PM, Peter Vágner wrote:

Hello,
A while ago I was trying to get some understanding on how to
make 3rt
party gtk apps accessible. At that time Alejandro Piñeiro
pointed me
to some docs and bugzilla entries describing the current
situation.
Unfortunatelly I haven't still mastered that. I have at least
realized
and hopefully understood at least some verry basic things
related to
this.
For example currently I am able to set accessible labels
and I am
able
to add / tweak relations between labels and the interactive
controls
they are supposed to label. I know this is not a big deal but
I have
already tweaked an app or two this way and I know it works
fine.
Another thing what's currently on my radar are widgets that
are often
reported as tables or treeviews. Individual rows appear to be
keyboard
focusable however orca is unable to report their role and
text.
I guess the common scenario is that the app developers tend to
subclass Gtk.CellRenderer to create more visually appealing
design. In
this case if I understand correctly the content is directly
drawn to
the widget surface and proper accessibility related properties
are
skipped from the implementation entirely.
By reading gtk reference docs I have came accross a method
gtk_cell_renderer_class_set_accessible_type () . That appears
to be
only info I was able to find related to Gtk.CellRenderer and
accessibility. Can anyone please give me a hint so I might try
move
forward and try learning how to implement accessibility for a
widget
where Gtk.CellRenderer is used?
Do I need to care about Gtk.CellRenderer or should I just set
accessibility related properties such as label and description
for
the
affected widgets without looking at Gtk.CellRenderer? How do I
refer
to multiple treeview colums or table cells in such
implementation? Is
there an app or just a code example I should look into to see
this in
action?
I have seen widgets with incomplete accessibility like this in
many
apps but if my explanation is not accurate enough here are two
from
the top of my head. One is the list of torrents in the
transmission-gtk
svn://svn.transmissionbt.com/Transmission/trunk and
the other is a contact list widget in a gtk3 based tox client
called
venom https://github.com/naxuroqa/Venom .
I will be looking into this some more, it may take me a while
like it
took me ages to figure out and get used to labelling and
related
stuff
so I am just trying maybe with some hint I might master it
better
this
time.

Thanks

Peter

_______________________________________________
gnome-accessibility-list mailing list
gnome-accessibility-list gnome org
https://mail.gnome.org/mailman/listinfo/gnome-accessibility-list










-- 
----
Alejandro Piñeiro
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]