Re: [orca-list] Structural HTML navigation by lists

[Marcus Habermehl <bmh1980de yahoo de>]

Am 01.02.2011 08:54, schrieb Hammer Attila:
> Marcus, I see following with your send second patch:
> The vakbarat.index.hu webpage if I press Orca+menu keybinding, the menu
> I think is not displaying.

There was a bug in my changes to scripts.toolkits.Gecko.script.py. Maybe
this was the reason why the menu wasn't showing.

> When I launch Firefox, and opening for example www.oc.hu webpage, the
> webpage is downloaded fast, but after Orca begin spokening the webpage
> contents I unable to move objects with tab or shift+tab keys.
> This is happening because I think need wayting the "The Object Navigator
> is ready for use" task running. Another example is www.dumaalmas.hu
> webpage, this webpage the need wayting time is 18 second before Orca
> spokening the "the object navigator is ready for use" message.
> This task run automaticaly if the user opening a webpage? This situation
> this is not good ydea I think, because the object collecting time is
> bigger with 10 second after Firefox loading new webpage, and if an user
> not want using this feature, need waiting this task time period. This is
> true ofcourse only complex webpages.

To avoid this problem I have used glib.idle_add to execute the code into
the background. Here I can navigate while the menu is builded in background.

If this depends on the machine? What CPU do you have? If this really
depends on the machine it isn't a good solution.

I'm sure a separated thread would be better than glib.idle_add. But the
true is, I'm too stupid for threads. I've made some tests and everytime
orca was crashing.

> With form fields related:
> The ordered form fields is not good ydea my openion.
> I suggest please do a simple form fields menu item and put all form
> fields inside with this menu if this final concept is accepted with more
> users.

Okay. It was only an idea that I've seen with SUE and I was thinking
it's a good idea. :-)

> With 50 character length cutting:
> I suggest please increase this character length, because some links is
> containing more than 50 characters. I think 77 character length is
> enough, because if happening perhaps a cutting fit the three dot
> character with end of text.

To increase the labels to 77 isn't a problem for the GUI itself. But if
the search problem is fixed, this would be a problem for searching in
the treeview. The search entry of treeviews has a timeout of 4 or 5
seconds. Because of this the search entry will be closed before Orca has
spoken such long labels.

> In Thunderbird:
> When I reply or composing a new message, and I press Orca+menu
> keybinding, Presenting an empty menu.

That's possible. I haven't remember this problem on writing the new code.

> Perhaps this is only my openion, but for example I better preferring now
> you last attached patch feature working method with #620331 bugreport,
> because except headings all function working already proper right.
> With headings related the focusing issue is unable to solve before
> Mozilla developers not fix the focus tracking related bug in Firefox.

If I'm using the _headingPresentation method from the
StructuralNavigation class, there is no problem to present the heading.
So this bug can be ignored.

> I have got a suggestion with based your last attached #620331 patch if
> the purpose is commit this feature before 3.0 Orca release:
> 1. Only need binding the HTML object navigator window with a keystroke
> (now your last attached patch this keystroke is Orca+Ctrl+F8), and
> another functions need unbinding. The adwantage this this feature
> possible presenting different single lists, and the choice is the user
> think what keystrokes want binding or not binding the single lists
> (anchors, form fields, frames, headings and links single lists). If an
> user not want different single lists, only enough the treeview based
> HTML navigator feature, not need do anything. This method not reserve
> more shortcuts. Another advantage with this method we have an already
> working right code with perhaps possible committing before with 3.0
> release because the heading focuse problem is inside this feature fix,
> because the focus tracking Firefox bug is an another story with fix is
> the Mozilla developers think. Very need this feature in Orca side
> because in Firefox 4.0 series the old several years doed links list and
> headings list Firefox extensions is not compatible.
> If more users accept this working method now, we have enough time next
> developing cicle doing new design this feature if this is need.

I think it is not a good idea to implement an incomplete or not properly
prepared feature, only to have it in Orca.

> Marcus, Joanie, this suggestion is acceptable now your openion? Need a
> final choice because in this thread now not have a starting point what
> prefer more users, or only I not see the starting point because this
> thread is begin long. :-):-)
> Some users want this feature, some users not, some users prefer treeview
> desing, some users would like menu oriented design and this function is
> lost before 3.0 release.

Yes this is the problem I have. I started this thread to get answers to
some questions. But now there are more questions and I don't know what I
should do.

As I understand joanie she has planned multiple lists. But most of the
users want only one list. And both together is rejected.

Each keybinding which I suggest is either too long or too difficult.

The last idea I still have is the following:

List type: all-over list
GUI: Dialog with treeview
Keybinding: Orca+Menu
Objects: All structural navigation objects + Links
Action for Enter: All objects are focused, links are executed

About the speed I have still to worry.

The suggested keybinding seems to be easy and short enough. Here I can
do this with one hand. Would this keybinding work on a Laptop, too?

Greetings
Marcus