Re: Wiki for atk best practices

["Peter Parente" <parente gmail com>]

Thanks for the quick response, Bill. More comments below.

> >which interfaces should be implemented (though this may be obvious),
> >
> >
> Perhaps not, but examples of how the theoretical guidelines in the Atk
> and at-spi docs are applied seem useful.

Agreed.

> >when events should be fired, in what order they should be fired,
> >
> The above may not be feasible to specify.  We avoid specifying it
> because we really cannot guarantee what an implementation may/will do;
> our experience has been that we are mostly at the mercy of the toolkit's
> implementation details here.

True. Still, documenting a preferred approach and paths to other less
desirable, but still respectable, solutions might be helpful. The idea
is to minimize discrepancy when we can't completely eliminate it. When
a developer must deviate from the norm, the wiki is there to catalog
the difference for others to note.

> >what
> >data they should carry,
> >
> That should go in the main API docs as part of the spec IMO...

I agree that some of this information should make it back into the API
spec. Perhaps the wiki could be a proving ground. Consensus on the
wiki might suggest promotion to the spec.

> >how the accessible objects should be arranged
> >in the hierarchy,
> >
> Again, possibly not something we can specify.  Our experience has been
> that this can and does change from release to release of a toolkit, and
> so little can or should be guaranteed.  Thus little should be assumed by
> the client about the ordering of children (unless a specific order has
> been requested, in the Collection API future).

I was vague here. I was more specifically talking about the use of
relations to specify tree parent/child relationships in an otherwise
flat accessible hierarchy for tree tables. Again, it would be nice to
at least document solutions such as this one to minimize discrepancies
across apps and toolkits.

Pete