Re: inaccessible treeviews and tables

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
>>>>>>> [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