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 >>>>>>>>>>>> [email protected] >>>>>>>>>>>> https://mail.gnome.org/mailman/listinfo/gnome-accessibility-list >>>>>>>>>>>> >>>> >> > > -- ---- Alejandro Piñeiro _______________________________________________ gnome-accessibility-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
