Re: inaccessible treeviews and tables

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
>>>>>> [email protected]
>>>>>> https://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
>>

_______________________________________________
gnome-accessibility-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/gnome-accessibility-list