Re: [orca-list] Structural HTML navigation by lists
- From: Marcus Habermehl <bmh1980de yahoo de>
- To: orca-list gnome org
- Subject: Re: [orca-list] Structural HTML navigation by lists
- Date: Tue, 01 Feb 2011 21:19:19 +0100
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
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.
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
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
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?
] [Thread Prev