Re: [orca-list] Open/Libre Office: Structural Navigation added for buttons, check_box, combo_box, entry, heading, list box and table.



+1 we need that :)

El 10/06/2011 21:49, "Joanmarie Diggs" <joanied gnome org> escribió:
>
>> I wish a few users test the patch before it is discarded. It worked
>> fine when I tested.
>
> We will not manipulate the GUI (i.e. physically adjust the scrollbar) to
> work around a bug in an app or toolkit. That's not just a hack. That's a
> hack with potential side effects, including triggering new AT-SPI events
> which might cause some other AT (a magnifier, or perhaps something else)
> to do something unwanted in response to the event. The fact that you did
> not see such an issue while testing Orca without any additional AT's
> running doesn't mean the problem does not exist and/or that it will not
> exist.
>
>> It is vital that the patch must not break Orca's performance and
>> stability, but testing is the best way to check if it does.
>
> Stability can also be impacted negatively by introducing a bunch of new
> code which boils down to a hack. The more code introduced, and the
> bigger the hack, the greater the likelihood that this will occur. It is
> vital that this does not happen.
>
>> Soffice is a very popular application. Improving its accessibility
>
> Bingo, improving its accessibility does not mean hacking in Orca. It
> means fixing LibreOffice.
>
>> will benefit a large number of users.
>
> Indeed, users of Orca *and* users of other ATs. Your proposed solution
> fails to do that because it fails to really address the problem at its
> source.
>
>> This particular enhancement is also a part of the Orca roadmap.
>
> The roadmap (which I co-authored) says nothing about hacking around this
> problem. Achieving that roadmap item can -- and may have to -- include
> our fixing the LibreOffice bugs. Or finding someone who can fix them.
>
>> So I wrote some code to work round the Soffice bugs.
>
> Not some. Quite a bit. Which, again, manipulates the on-screen GUI
> objects.
>
>> I feel this is in line with Orca methodology of having one default
>> script to handle the common functions and a special script for each
>> nonconforming application.
>
> The intended purpose is not to handle non-conforming applications. It's
> to provide different task-specific functionality. What one needs in a
> chat app is different from what one needs in a spreadsheet app is
> different from what one needs in a calendaring app, and so on.
>
> Yes, we have also used the scripts to deal with non-conforming
> applications and toolkits. And we have -- and still are -- paying the
> price. Speaking of which:
>
> Last month we had a week-long "ATK/AT-SPI hackfest" at Igalia in Spain.
> Stakeholders from many different groups attended. The consensus is to do
> what it takes to bring about a much more unified, standardized
> implementation of ATK across toolkits and applications rather than
> placing this burden on ATs like Orca. It will not happen tomorrow, but I
> am confident it will happen. What you have done is a step away from that
> much-needed goal; not a step towards it.
>
> --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


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