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/9369215I 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 callsgtk_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-instantiationOn 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 thename. On render_userstatus it uses that variable to render the status. AContactListCellRendererAccessible 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 forhttps://developer.gnome.org/accessibility-devel-guide/stable/gad-custom.html.enhas two problems: * It is outdated.* It is intended as a guide to extend widgets accessibility. A cellrenderer is not a widget.What do you mean for gtk_get_accessible? AFAIK, that method call doesn'texists. 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 isthe 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 herehttps://github.com/naxuroqa/Venom/blob/master/src/ui/ContactListCellRenderer.vala. I can see they are also using GtkCellRendererText in order to changea GTK_COMBOBOX which remains accessible herehttps://github.com/naxuroqa/Venom/blob/master/src/ui/ContactListWindow.vala. While creating my CustomCellRendererAccessible do I really have to do everything that is recommended herehttps://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 tomanipulate that accessible and set its name and description however by testing with orca I have discovered changes I am trying to make resultin 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 problemhowever I think It is just not possible to instantiate ATK_Object likeall the other objects using new operator. So Now I am lost again and I have no idea on how to possibly moveforward. Frankly I don't feel confortable following the article MakingCustom 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 customcell renderer in order to add some new visual stuff. The accessibilityrelated are not skipped. The already in place cell renderer accessibility is used. But if the new cell renderer uses somethingtotally different to render text, then the gtk+ cell render accessibleobject 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 thatrelates a cell renderer with his accessible method. Is just a utility method to avoid the need to redefine the method get_accessible for anycustom 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 tofocus 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 seeany 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 meto some docs and bugzilla entries describing the current situation. Unfortunatelly I haven't still mastered that. I have at least realizedand hopefully understood at least some verry basic things related tothis. For example currently I am able to set accessible labels and I am ableto add / tweak relations between labels and the interactive controls they are supposed to label. I know this is not a big deal but I havealready 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 oftenreported 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. Inthis case if I understand correctly the content is directly drawn tothe 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 moveforward and try learning how to implement accessibility for a widgetwhere 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 theaffected 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 inaction? 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 thetransmission-gtk svn://svn.transmissionbt.com/Transmission/trunk and the other is a contact list widget in a gtk3 based tox client calledvenom https://github.com/naxuroqa/Venom .I will be looking into this some more, it may take me a while like ittook 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
_______________________________________________ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
