Calendar is not accessible.
Transfer bug to gnome-panel clock-applet.

Agreed, looking at the calendar with at-poke shows that there is no useful a11y
information available, it looks as though it's just a GailWidget implementation.

Calendar is a stock GtkCalendar, so it's not a panel bug. Moving to GTK+.
(do not forget to reassign bugs when changing the product ;-))

Apologies for spam... marking as AP2 to reflect accessibility impact.

Looks like a gail bug - since there is a gailcalendar.c AtkObject implementation, but it's 90% no-op, i.e. it doesn't override any methods from GailWidget.

Not exactly a small job to fix, but potentially an EXCELLENT task for a new gail committer to take as a learning example.

*** Bug 375847 has been marked as a duplicate of this bug. ***

I take a little look to gtkcalendar.c, and I think that in fact, it is a complex task with several problems.

I got some conclusions, please correct me if you see any error:
  * The calendar has 4 sections:
     * Header ( with the arrows)
     * Main section (with the day numbers) 
     * Week numbers section (a column) -> optional
     * Day names (a row)               -> optional
  * To the implementation of this accessibility object I think that is required to implement the interface AtkTable, but I see two options:
     * gailcalendar implements itself this interface, and manage all elements
     * Create a flyweight object (gailcalendartable or something like that) and add to the gailcalendar the required children (as is a variable number) to split the functionality required (a gailcalendartable for the main section, one for the week numbers, other for the day names)
  * Each day, day name and week number should be flyweight objects too, subclasses of gailcell (so gailcalendar and the possible gailcalendartable need to implement gailcellparent).
  * The arrows could be implemented too as a flyweight objects, and manage the click on it to call the gtk_calendar_select_day from gailcalendar.

One of the main problems of all this flyweight object (and the main reason I ask here for some wisdom) is implement the AtkComponent interface, ie, get the real position of this elements.
   
gtkcalendar made the drawing using a lot of private gdk windows, with a lot of calculations based on other private elements and in some global gtkcalendar.c variables (so we can't reproduce the calculus with the public data).

I was tempted on copy the gtkcalendar private structure definition on gailcalendar and simply ask for this private structure here, to get the position values of each gdk_window (although the position of each day cell still requires to calculation, based on this private values and the painting method). Anyway, this is a real ugly hack, with a lot of sync problems, and seems a very bad idea.

So... any idea, correction or hint to go with this ?

Thanks in advance for your attention.

I haven't though this through. Maybe you can get the gtkcalendar's window first, and try gdk_window_get_children to get the children list.

This is a good point, although I see a little problem: you could get the children list, but probably you couldn't identify it. I mean, there are a window for the main section, other for the weeks number, etc. The only way to know that the children 0 is the main section or not is see the gtkcalendar code (or use any kind of postion heuristic).

But this is better that nothing. I only hope that the children order can't change dinamically. I will try to check if I can go with this.

I have been working a little with these. I can know which gdkwindow I am at each moment using a little positioning heuristic. 

Anyway, this doens't solves other problem. Each gdkwindow is used to draw different sections, but now I need to identify each individual element.

The best example is the day: each day is being modeled as a gailcell, it is, there are a individual element for each one. But the real width and position inside his gdkwindow is computed used a lot of formulaes and internal private values. At this moment I'm using and aproximation, as the total gdkwindow were splited equally between their cells. This is really "hacky" and don't work very well for the week number column.

Other option could be compute again this values on hailcalendar. But this copy&paste could cause sync problems. There are a lot of complex formulaes and constant values, so any change on gtkcalendar could outdate gailcalendar.

Anyway I will ask on gtk mail list about this.

I think we can try to implement gailcalendar in gtkcalendar.c, because gail have been moved into gtk+'s trunk.

Hi Matthias, is there any chance we can do this in gtkcalendar.c? Because we need some private information from gtkcalendar.

Sure, that was one of the reasons for merging gail in the first place.
I'd be happy to review a patch (even though I am somewhat disillusioned by the fact that the icon view a11y implementation that resides in gtk has been broken for so long...)

Ok, when I had a free moment I'll try that, although I suppose that the big issue is how make that without mess all. At this moment I have the next files:
   * gailcalendar.[ch] --> the code at gailcalendar.c will go to gtkcalendar.c
   * gailcalendartable.[ch] -> auxiliar object that models each section
   * gailcalendarcell.[ch]  -> auxiliar object that models each textual element
   * gailcalendararrow.[ch] -> auxiliar object to model the arrows

GailCalendarArrow, GailCalendarCell and GailcalendarTable extents GailCell. 

I think that GailCalendarTable may need a little refactoring to extents GailContainerCell instead, although it is not really important as it is very focused on calendar, so it will be very difficult to be used outside.

So, one option should include the code of all this sources files on gtkcalendar.

I only have a question: I need to extents GailCell (well, this class exists just for this things). But to do that I need more than use the anonymous (run-time) inheritance from GAIL how gtkiconview does: http://developer.gnome.org/projects/gap/presentations/GUAD3C/making-apps-accessible/anonymous-inheritance-1.html

as I require to call functions declared and defined in gail, that it is not public , like gail_cell_parent_get_cell_extents.

Can I do that with this approach? Can gtkcalendar.c at gtk+/gtk make an include to gailcellparent at gtk+/modules/other/gail? Could be any link problem?

Ideally gtk should not include any gail header file... If include gailcell.h is necessary, I guess we have to implement gailcalendar in "gail" first. Merge gail's code into corresponding gtk class is our goal, the component problem can be fixed that time. (Actually we have some other bugs waiting the merger.)

Indeed I use gailcell.h because was convenient, I mean, I needed to model a cell-type element, and it exists gailcell, with a lot of functionality yet implemented, so it has sense to me to use it.

( Well, this is one of the goal in OOP, create classes that define common functionality, and then extents it your concrete cases no? :) )

Anyway, if I understand you properly, you ask to get back to the initial approach, implement gailcalendar on gail, so we have again the initial problem: a lot of calculations and data are private in hildon-calendar. 

At this moment I see three options:
   * Copy&paste all the calculations on hailcalendar (at this moment some are copied yet)
   * Modify gtkcalendar, to expose the required information: although this could be something strange, as are data very tight related to the current calendar paint implementation
   * Not include gailcell.h from gail, instead of extends gailcell to create gailcalendarcell, copy and modify gailcell to create gailcalendarcell (and define all this types on gtkcalendar.c)

(In reply to comment #15)
> Anyway, if I understand you properly, you ask to get back to the initial
> approach, implement gailcalendar on gail, so we have again the initial problem:
> a lot of calculations and data are private in hildon-calendar. 

Is component interface the only one needs the calculations? If so I think we can work on the rest part of gailcalendar first and work on component interface when gail merge into gtk+ completely.

Yes, at this moment I only have problems with the component interface. I have implemented it, but the individual cells compute his size using only and aproximation.

I will try to clean up my implementation a little, and then upload the first provisional patch, if christmas let me a free moment.

This bug is still present for me
Any updates? Looks like your patch didn't make it

(In reply to comment #18)
> This bug is still present for me
> Any updates? Looks like your patch didn't make it

Well, yes, in the end no patch were created, so yes, the bug is still present.

As I said on previous comments, I were able to get a GailCalendar inside Gail, that allow the interaction with the Calendar from a ui test automation POV, but was computing wrongly the position of each day-cells, because the widget used private data to compute it.

And as I said, the problem with implement it directly on GtkCalendar was that you should access to gail, so you weren't able to reuse gailcell and so on.

Sorry, right now my implementation is in a idle, and in fact, there are several months that I don't try anything about that, and I can't give any hypothetical date for a final patch.

*** Bug 570025 has been marked as a duplicate of this bug. ***

Ping? (GtkCalendar is still completely inaccessible: No children, no events when the selected date changes, etc.)

considering that no forther patches were created in the past 5 years, I'd say that we're waiting for somebody to pick this up.

(should probably remove the ASSIGNED state).

We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.

As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla.

If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab:

https://gitlab.gnome.org/GNOME/gtk/issues/new