Re: API Freeze Schedule and outstanding API bugs

Bill Haneman <Bill Haneman Sun COM> writes:

> Owen said:
> >> Major Stuff
> [...]
> >> 50966 Interface methods can't be overridden in derived classes
> I'm sorry to see this in "major stuff", since the lack of a way to do 
> this is causing some violence to our accessibility implementation 
> classes (forcing a flat topology where we would really want a hierarchy 
> in the implementation library).  I don't know, we may be the major 
> customer for this in terms of urgency at the moment.

Don't worry - this bug is considered a show-stopper - we won't
put out 2.0.0 without fixing it.

> >> 50902 GTK+ Widgets need to implement an Accessibility API
> I think the main thing still being tracked by this bug are various API 
> tweaks needed in order to implement ATK on a few widgets, perhaps this 
> bug is nearly closed since ATK is almost completely frozen now.  As most 
> of you probably know, the actual working implementation of ATK (as 
> opposed to the interfaces, their definitions, and a trivial "default 
> implementation") is being coded in GAIL, an externally loadable library.

This bug is basically a place holder for waiting for ATK to be
frozen. Since ATK is a dependency of GTK+, we can't really declare
GTK+ to be API-frozen until ATK is also frozen.

Once the ATK interface is frozen, we can move this off the API
milestone and/or close it.

I thought there were some cases - e.g. the standard dialog widgets -
where some calls to set ATK properties would be need to be added
to GTK+?

(BTW, can we create an ATK product in bugzilla? - we need issue 
tracking for ATK as well. We can give permissions to modify/close
bugs to whoever needs it.)
> In a couple of cases we have noticed bugs having to do with property 
> change notifications - are such changes to property notification 
> behavior (not involving actual method signatire changes) considered API 
> changes for the purposes of this freeze?

Additions to the set of properties would be API changes, even though
they don't involve method signature changes.

Fixes to notification (how notification behavior is supposed to
work is quite well defined) would not be considered API bugs - just


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]