On 07/09/2014 05:55 PM, 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? You need to pass the GType. No it is not needed to instantiate an object of that class first.
> 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 >>>>>>>>>>> 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
