Re: Wiki for atk best practices

[Aaron Leventhal <aaronlev moonset net>]

Even if you can't specify something, saying what the best practices are, 
or explaining where there is more/less flexibility helps everyone.

- Aaron

Peter Parente wrote:
> 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
> _______________________________________________
> gnome-accessibility-list mailing list
> gnome-accessibility-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
>
>