Re: inaccessible treeviews and tables

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