Re: AT-SPI hard code freeze break request
- From: Willie Walker <William Walker Sun COM>
- To: Vincent Untz <vuntz gnome org>
- Cc: release-team gnome org, Eitan Isaacson <eitan ascender com>, desktop-devel-list gnome org
- Subject: Re: AT-SPI hard code freeze break request
- Date: Sat, 15 Sep 2007 11:22:00 -0400
Hi All:
GNOME 2.20.0 is pyatspi's first official release to the world, so we
want to get the API as close to AT-SPI as possible. In addition, we
want it to support the impending FF3 event type annotation feature. The
patches in question accomplish these goals and have been tested by
various members of the AT-SPI, Accerciser, and Orca teams.
http://bugzilla.gnome.org/show_bug.cgi?id=467366 is most important
because it will allow the new Firefox 3 annotated event types to come
through to users of pyatspi (e.g., Dogtail, LDTP, Accerciser, and soon
Orca). Without this patch, the annotated Firefox 3 event types do not
make it through, breaking any pyatspi client that happens to be
listening for the events, whether they are annotated or not.
http://bugzilla.gnome.org/show_bug.cgi?id=472301 is important as well
because it will allow users of pyatspi to get the expected experience of
AT-SPI where the return value of the event handler specifies whether or
not to consume a device event. Without this patch, the return value is
ignored, breaking with the expected experience of AT-SPI.
Hope this helps, and thank you for your consideration,
Will
On Sat, 2007-09-15 at 10:40 +0200, Vincent Untz wrote:
> Le vendredi 14 septembre 2007, �9:42 -0700, Eitan Isaacson a �it :
> > Hi.
> >
> > This is to request a freeze break on two outstanding patches:
> > http://bugzilla.gnome.org/show_bug.cgi?id=467366
> > http://bugzilla.gnome.org/show_bug.cgi?id=472301
> >
> > The first one is a fix to allow new Firefox 3 event types to be caught.
> > As you know, Firefox has it's own schedule, and they could afford major
> > changes now. I think it would be worth putting in that fix so we could
> > interop with FF3 in this next release.
> >
> > The second one is an API conformance bug. We would like to have this in
> > the earliest version possible since it is a small but fairly significant
> > fix.
> >
> > The above is the opinion of Willie Walker and I with Li Yuan's consent.
>
> Those two are not easy to me: the code changes seem okay, but I know
> nothing about this code base so I can't know if it can have any negative
> impact.
>
> Has this been well-tested?
>
> Vincent
>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]