Re: [orca-list] FLAG WEEKEND (aka refactor part 2)

[Derek Roberts <bigd vi guy gmail com>]

Hi,

As far as the slow flat review bug, I can reproduce this in other
programs too. For instance, if you open iceweasel and try entering
flat review, it can take anywhere from 1 to 10 seconds depending on
the page. It also works for me in lists, like as you said the message
list in thunderbird, or a list of files in transmission. This is with
the latest orca from debian unstable (2.30.1), but I also was able to
reproduce it back when I used debian stable (orca version 2.22 or
something).

Is their anything I can do to help with this? I'm still learning
python. I could try the debug.out thing but it didn't seem to be that
helpful when you tried it. Is their something else I can do?

Thanks.

On 5/9/10, Joanmarie Diggs <joanmarie diggs gmail com> wrote:
> Hi again, Steve.
>
> I've got some good news and some bad news. Here's what I'm seeing using
> Thunderbird 3.2a1pre from a few months ago:
>
> * Flat review is working the same way for both the stable gnome-2-30
> branch of Orca and for master. "Same" is less than ideal, namely:
>
> * In a short list of messages, it seems we can't figure out what's
> focused and what's not, so flat review is starting at the top of the
> window. But flat review is otherwise working as I'd expect.
>
> * In a huge list of messages (My 'All Mail' folder claims 27,273
> messages, flat review takes forever to come up).
>
> * The only tracebacks I'm seeing are intentional stacktraces we include
> in debug.out to tell us that a node which should be alive has since
> died/gone STATE_DEFUNCT. Gecko likes to kill it's accessibles for sport
> and replace them with new versions. Kinda like Invasion of the Body
> Snatchers, but with AtkObjects. But I digress... There are no tracebacks
> suggestive of a refactor-related error. (Whereas when Jacob reported his
> problem, there was indeed such a traceback indicating where I'd
> forgotten to make a change.)
>
> So I agree that in a really large list of messages, building the flat
> review context is insanely slow for Thunderbird. And that's no good and
> we should figure out where things are failing. But I'm not so sure it's
> a refactor issue. Having said that, if you have a traceback for an Orca
> error (not a dead-node stacktrace), see if it says that a given method
> could not be found. If you find that, I blew it. And as soon as I know
> where, I'll commit a fix.
>
> Thanks for the testing and feedback!
> --joanie
>
>
> _______________________________________________
> orca-list mailing list
> orca-list gnome org
> http://mail.gnome.org/mailman/listinfo/orca-list
> Visit http://live.gnome.org/Orca for more information on Orca.
> The manual is at
> http://library.gnome.org/users/gnome-access-guide/nightly/ats-2.html
> The FAQ is at http://live.gnome.org/Orca/FrequentlyAskedQuestions
> Netiquette Guidelines are at
> http://live.gnome.org/Orca/FrequentlyAskedQuestions/NetiquetteGuidelines
> Log bugs and feature requests at http://bugzilla.gnome.org
> Find out how to help at http://live.gnome.org/Orca/HowCanIHelp