Re: inaccessible treeviews and tables

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