Re: About making public gtk accessibility headers

[Piñeiro <apinheiro igalia com>]

On 08/07/2012 11:02 AM, Emmanuele Bassi wrote:
> hi;
>
> On 7 August 2012 09:49, Piñeiro <apinheiro igalia com> wrote:
>> This thread didn't take too much attention, but I assume that it is due
>> the post-GUADEC back-to-home trip. Anyway, I want to add some extra
>> information here.
>> So the options are:
>>   a) Make gtk accessibility headers public (my preferred option)
> this would obviously be the preferred option, from the perspective of
> third party developers; it obviously adds constraints on the whole
> accessibility API, 

But as I mentioned on the original mail, the API of most of the current
48 accessibility related headers are minimal, as most of the
accessibility functionality is already defined on ATK. The only ones
defining some kind of API are:
gtkaccessible (already public)
gtkcellaccessible (have some methods, have some virtual methods)
gtkcellaccessibleparent (it is an iface)
gtkcontaineraccessible (have some virtual methods)
gtkiconviewaccessible (some methods)
gtklockbutton (have some methods)
gtknotebookpageaccessible (have some methods)
gtkrendercellaccessible (have some methods)
gtktextcellaccessible (have some methods)
gtktextviewaccessible (have some methods)
gtktreeviewaccessible (have several methods)
gtkwidgetaccessible (have some virtual methods)

But in general, most of those methods should be kept private, as are
used for the internal implementation of those objects. Initially I
wouldn't expose those.

Additionally, there are some that have public variables on the instance
struct, so it should be needed to add a private struct. Although this
should be done for all the accessible classes as part of a little header
cleaning task (in addition to adding pads as I mentioned on the original
mail).

> but if it removes the need to create hacks inside
> gtk+ to allow third party code to make custom widgets accessible then
> it's a reasonable burden.
>

Exactly.

BR

-- 
Alejandro Piñeiro Iglesias