Merge lp://staging/~themuso/libindicator/accessible-name into lp://staging/libindicator/0.4

Probably should make the function prototype and struct property const so that users know they shouldn't free them. Otherwise looks good.

Luke, Ted told me you didn't want to merge this in before you got other pieces. So, what is blocking this? I have a branch (https://code.launchpad.net/~rodrigo-moya/unity/indicators-a11y/+merge/48943) that is missing something like this to provide a good description for the indicator objects.

Some comments though:

The get_accessible_name seems to be related to the IndicatorObject, not the IndicatorObjectEntry's, so why do you have this:

62 struct _IndicatorObjectEntry {
63 GtkLabel * label;
64 GtkImage * image;
65 GtkMenu * menu;
66 + gchar * accessible_name;
67 };

wouldn't it be better to just have a indicator_object_get_accessible_name function for the IndicatorObject? Also, maybe just call it get_description, instead of get_accessible_name?

On Tue, 2011-02-08 at 17:26 +0000, Rodrigo Moya wrote:
> The get_accessible_name seems to be related to the IndicatorObject,
> not the IndicatorObjectEntry's, so why do you have this:

It needs to be related to the entires as those each represent an item on
the panel. The object represents a collection of items on the panel.
So for things like the sound menu there is a 1:1 ratio of objects to
entries, but for application indicators it's 1:n.

On Wed, Feb 09, 2011 at 04:26:52AM EST, Rodrigo Moya wrote:
> wouldn't it be better to just have a indicator_object_get_accessible_name function for the IndicatorObject? Also, maybe just call it get_description, instead of get_accessible_name?

Yes, I have actually renamed it in my code, now called accessible_desc, and related changes in indicator-application/libappindicator.

In terms of readiness, I was almost there, till I realised that we will likely have to add another signal, because even if an indicator updates the information that get_accessible_desc harvists, the unity panel and indicator applet still won't know something has changed, short of being signaled. Using such a signal is not a problem for indicator-application, because indicator-application sends an indicator entry pointer through to the displayer, i.e the applet/unity panel.

My problem that I am running into with this new signal is with the system indicators, as they don't deal with constructing their own IndicatorObjectEntry structure, i.e they use the default get_entries method from indicator-object, get_entries_default(Indicator Object * io). Even if another method is added to indicator-object allowing this to be worked around somehow, some indicators like indicator-sound are modular to the point where its not possible to call the accessibility description update signal from particular objects that make up the indicator, short of extending method calls to pass the indicator object pointer through to where its needed etc.

I hope what I have written above makes sense, I know what i mean in my head of course, but explaining it is something else :) so let me know if you need me to clarrify anything above. Of course I could extend the indicators as necessary to make sure the indicator object pointer is where it is needed, but I don't want to do that until I know there is no other way of doing it. If either of you have any suggestions, I'm all ears.

Luke