Re: Enable accessibility by default in development releases?
- From: David Malcolm <dmalcolm redhat com>
- To: Federico Mena Quintero <federico ximian com>
- Cc: desktop-devel-list gnome org
- Subject: Re: Enable accessibility by default in development releases?
- Date: Fri, 11 Nov 2005 14:16:36 -0500
On Fri, 2005-11-11 at 12:18 -0600, Federico Mena Quintero wrote:
> On Fri, 2005-11-11 at 12:20 -0500, David Malcolm wrote:
>
> > So here's a (possibly crazy) suggestion: during development releases,
> > enable a11y by default, and during stable releases, disable it by
> > default. That way people running jhbuild, GARNOME etc would be running
> > all of the a11y code, and any bugs in that layer would be discovered
> > more quickly.
>
> Let's do it.
>
> On a few conditions:
>
> - You will write a short tutorial of how to write profiling scripts with
> Dogtail.
>
> - You will write a little bunch of Dogtail scripts that will help us
> profile particularly slow operations (opening the panel menu, doing
> stuff in Evolution)
Here's a start:
http://cvs.gnome.org/viewcvs/dogtail/examples/filechooser-stress-test.py?view=markup
http://cvs.gnome.org/viewcvs/dogtail/examples/evolution-test-switching-components.py?view=markup
(though I think that one's currently broken in CVS)
I've been mainly using Dogtail for testing functionality, rather than
performance testing. Dogtail automatically inserts delays, so if you're
doing timings you'd want to do something like:
import dogtail.config
dogtail.config.config.defaultDelay = 0.01
to avoid this skewing the results.
I suspect that there are some memory leaks in Dogtail at the moment as
well.
>
> - Sun will write the dtrace scripts to figure out why/how enabling a11y
> is a performance problem for the desktop: a11y does a lot of IPC, and
> profiling that is hard unless you have something like dtrace.
>
> All agreed? :)
>
> Federico
>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]