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