> I see an interesting problem with my development Lucid system.
> I using Orca development version with my Jaunty and my Lucid development
> system. My keyboard layout is general 105 key pc with both systems, and I using
> hungarian keyboard layout with both two systems, so, this is equals.

To help us verify the keymaps are indeed identical, please run the following commands:

1) On Jaunty:

   xmodmap -pke > jaunty.out

2) On Lucid:

   xmodmap -pke > lucid.out

Then attach jaunty.out and lucid.out to this bug.

Thanks!

Created attachment 152081 [details]
This is my jaunty output from xmodmap -pke command.

Created attachment 152082 [details]
This is my output from xmodmap -pke command with my Lucid system.

Will, if need, I possible do this test with my wife Karmic system.
I tested she machine with Orca laptop keybinding commands, and don't see problems, the laptop keybinding commands equals works correct with my Jaunty and my wife Karmic system.

For example, if I go to learning mode and press Capslock+f key command, I hear following message:
"Opens the Orca Find dialog."

Another interesting think, I don't no why happen always my Lucid system:
When I do any Orca laptop keybinding command, my Capslock key is toggled on or off. For example if my capslock key state is off, and I disabled the speech with Capslock+s keybinding command, my capslock key is turned on.
If I remember right, this problem is oldest time publicated with Orca mailing list, but I don't no the letter subject.

Attila

Hi Attila:

The keyboard layouts are completely different.  The jaunty layout looks like a QWERTY layout and the lucid layout looks like a QWERTZ layout.  If you put Orca into help mode and press individual keys, Orca will speak the key names for you and you should be able to tell the difference.

If you want to try the jaunty layout on your lucid system, I think you can type this command on your system, assuming jaunty.out is the file containing the results you've attached from your jaunty machine:

xmodmap jaunty.out

Will

This is very interesting, because the quertz laiout is the right. Possible my Jaunty keyboard laiout configuration is destroied.
But when I do you suggested command, not fixed the Orca keybinding problem.
Just a moment, I save Karmic keybinding layout, and try apply.

Attila

I don't understand this problem.
When I run xmodmap karmic.out command, the keyboard layout is absolute changed. My wife machine is a correct hungarian keyboard layout (quertz). When I apply this layout with xmodmap karmic.out command, the z and y letter place is replaced, and for example the é character is changed with ;, , the ő character changed with [, etc.
After this, when I run orca --replace command, Orca running correctly, and learn mode spokening right Capslock+f key text my Lucid system.
But, when I apply this modification, impossible to using hungarian characters.

I look my Jaunty configuration, absolute work right, the keyboard layout is not destroyed, correct hungarian keyboard layout setted up.

Attila

Created attachment 152095 [details]
This is the saved karmic.out file.

I ask Gabor Kelemen he known happen or not xkeymap modifications with related this problem.

I wayt he answer.

Attila

Created attachment 152097 [details]
I sending again the xmodmap -pkey Jaunty output result, see my comment why.

Will, please compare now Lucid output result and this Jaunty output result.
I forgot one think with my Jaunty and Karmic system:
Ubuntu installer installs possible automaticaly the US English keyboart layout, but the hungarian keyboard layout used by default, because the language is hungarian my system.
When I remove the Us English keyboard layout my Jaunty system, I reproduced this problem, Capslock+f keyboard command not do character attribute spokening, executing Orca find dialog.
The bigger problem is following:
Character attribute spokening is defined with Capslock+f keybinding command, but missing.
Not possible Capslock+f looks [ character (Altgr+f key combination)? For example, Orca find dialog keybinding is Capslock+[ in english I think.

For example, Altgr+, is ; character with hungarian keyboard layout, and sayall command is Capslock+; command in english.

Another problem: When I try redefine sayall command with Capslock+é keybinding, not working this operation.

Attila

Hi Attila:

Try running Orca with whatever keyboard layout you have and enable debug mode:

orca --debug-file=debug.out

Then, just try one thing: press what you believe to be the CapsLock+f keys.  Then quit and save the debug.out file and attach it to this report.

I dug a little deeper.  When I look at all the keymaps, I see this:

keycode  41 = f F f F bracketleft ordfeminine

This means the f key and the [ key are bound to the same physical key and there's a conflict.  Not quite sure what we can do to fix this properly, so you will probably need to redefine your key bindings to work with your keyboard for now. :-(

Created attachment 152128 [details]
This is your requested debug.out file.

Hy Will,

This is your requested debug.out file.
I do following commands.
I go to learn mode with Capslock+h command, and pressing Capslock+f keybinding command, Capslock+6 keybinding command (say title command), Capslock+, keybinding command (say all entire document).

Your suggestion is little difficult, because I don't no why need define with 41 key code for example with following entry with hungarian keyboard layout:
keycode  41 = f F f F bracketleft ordfeminine
I don't no not possible missing another user with bracketleft ordfeminine definition.

Not possible handle this problem with general language independent fix with Orca? I ask this, because another non english language users need redefine with own xmap keybindings?
For example, what happen if have a spanish language user, installing only spanish language and spanish keyboard layout, what Orca keybindings is not working this user?
For example, if the Orca keybindings is different with language by language, need I retranslating Accessibility Guide hungarian translation file with laptop keybinding command document part. :-):-)
But, this is the smallest work.

Attila
Attila

Will, I redefine the following conflicting key with Orca keybinding page:
Open Orca Find dialog: I redefined with Orca+ő keybinding code (phisical place with [ key with english keyboard layout).
In hungarian keyboard layout, the [ character phisical place is replaced with ő character (after p letter).
Not optimal way, but working, and don't need search the hungarian users with another keystrokes (why not working the attribute spokening for example).
Don't possible to do automatic fix this problem if I add a list with need automatical replacing keys if Orca using with hungarian language, and don't need all user manual do this task, because learn oldest keybinding methods (sayall document Capslock+é keybinding command, Orca find dialog: Capslock+ő command)?

Attila

My ydea not working full right. I tryed redefine prewious wroted commands with my wife desktop computer with laptop keybinding only. The definitions is working correct when I using laptop key binding. But, when I switch desktop keyboard layout with Orca preferences, the redefined commands is not changed (for example say entire document command is not changed with numpad+ key).

I have no more ydea.

Attila

Very interesting, when I using original laptop key bindings, flat review commands is working right for example, and equals with english keyboard layout commands.
The miss working functions is:
say entire document key,
Orca find dialog keys (find dialog keybinding command Capslock+[, and find next entry command Capslock+] command), say title command (Capslock+slash), say status line command (Capslock+slash press two quickly).
For example, see my sent lucid.out following entryes:
keycode  44 = j J j J iacute Iacute
keycode  45 = k K k K lstroke ampersand

Attila

Created attachment 152131 [details]
This is show my keyboard preferences window.

Will, I found a temporary workaround, with keeps back old worked Orca laptop key bindings my prewious used systems.
I do following steps, and working:
1. I go to the system/preferences submenu, and choosed keyboard preference tool.
2. I go to the billentyűkiosztás page (keyboard layout with english location.
3. Because Us keyboard layout is not installed by default my system, I add this keyboard layout, and move to top of the list with clicking the move button.
Now, first keyboard layout is USA, the second keyboard layout is Hungary. But this change not disturb me with hungarian keyboard usability, because the keyboard layout switch automaticaly my system if I using hungarian locale.

Now, Capslock+f spokening attributes, Capslock+é do sayall entire document, Capslock+- do say title command if I using hungarian keyboard layout.

But why need install US keyboard layout when I would like using old seed Orca laptop key bindings? :-):-)
I don't understand but this workaround is working. :-):-)
Oldest systems not need do this workaround steps, because the USA keyboard layout installed automaticaly, and putted top of with keyboard layout list by default.

Attila

I believe what we're running into here is that two or more keysyms that we expect to be on different keys are ending up on the same key for the Hungarian keyboard layout.  In addition, there might be keysyms we expect to be defined somewhere on the keyboard layout that are not in the keyboard layout at all.  This is indeed problematic.

With the exception of attempting to provide translatable keyboard mappings (something we won't be able to do for 2.30), I'm not sure of a graceful way to solve the problem.  For now, we will need to mark this as a known limitation and provide users with examples for how to redefine their Orca keybindings or their X11 keymaps.

Another thing we might do is instrument the code to output informational messages about potential breakages in the keybindings (e.g., multiple keysyms on one key and missing keysyms altogether).  This would at least give users an idea of what keys are causing problems and which pieces of functionality might be broken.

I talk Gabor kelemen (hungarian GNOME translation coordinator).
He sayd me not need do anythink with hungarian keyboard layout, because the keyboard layout map is good, standard.

I don't no how can handle with Orca code with this some exception keybindings (don't need handle all key bindings, because more keybindings is equals with english and hungarian keyboard layout).

This is not easy, and I absolute agree if impossible do fix this problem with GNOME-2.30 release.

Attila

Created attachment 152172 [details] [review]
Code (turned off by default) to try to detect error conditions in keybindings

This patch attempts to detect missing keysyms as well as keybindings that map to the same physical key.  It is disabled by default.  To enable it, set settings.validateKeyBindings=True then rerun Orca.  This is disabled by default because it can be a relatively expensive operation and is run each time a new script is create.

The output goes to the debug log at LEVEL_SEVERE.

Hy Will,

I look your patch with tomorrow, because I am not home with this day.
If I understand right, I installing your patch tomorrow, this is clean. After I setting settings.validateKeyBindings=True with user-settings.py file and rerun Orca.
When I turn debug mode with severe with user-settings.py file after I remove again the US keyboard layout, what can I need do? Go to learn mode, and pressing for example with Capslock+f keybinding command? Or enough to do debugging with orca --replace --debug-file=debug.out command, and do this prewious wroted steps with learn mode?

Attila

The patch has  already been committed, so you can get it by just pulling from git master.

If you then set settings.validateKeyBindings=True and rerun Orca, it will output problems it finds with the keybindings and the X server keymap.  So, running "orca --replace --debug-file=debug.out" after setting the new setting to True should do it.

Will

Created attachment 152293 [details]
This debug.out shows the problematic laptop keybindings with hungarian keyboard layout

Will, I sending you the requested debug.out file.

Your detection patch is fantastic. If you don't want search the required informations with debug.out file, I copyed this informations with this comments, possible this is easyest your work:
No physical key defines SunF36
needed for Toggles whether to read just the current table cell or the whole row.
semicolon maps to the same key as comma
used by Speaks entire document.
used by Speaks the current flat review character.
slash maps to the same key as 6
used by Speaks the title bar.
used by Go to bookmark.
bracketleft maps to the same key as f
used by Opens the Orca Find dialog.
used by Reads the attributes associated with the current text character.

Unfortunately, impossible change this key maps with hungarian keyboard layout, because this is standard with all operating systems with using hungarian keyboard layout.
For example, when the user using an english keyboard layout, sayall entire document command is Capslock+; keybinding. Not possible to do replace automatical this keybinding if the user using for example with hungarian keyboard layout with Capslock+é keybinding?

Not possible request the default keybinding and the actual needed key code map?
For example, compare the englis keyboard map and hungarian keyboard map with 47 key code:
keycode  47 = semicolon colon eacute Eacute dollar cent
keycode  47 = eacute Eacute eacute Eacute dollar cent
Not possible replace semicolon with é?

Not help mark translation with builtin Orca laptop keybindings? Not need mark all x keymap with translation, enough to mark with builtin 51 Orca laptop key bindings, or detected problematic key bindings.

If my ydeas impossible to do and resulting lot of extra work, have any ydea how can solving this problem? I am interesting only: What result showing for example with another keyboard layouts (germany, francais, spanish etc)?

Attila

(In reply to comment #23)
> No physical key defines SunF36
> needed for Toggles whether to read just the current table cell or the whole
> row.

This is OK -- it's mostly there to support a layout where F11 is sometimes defined as the SunF36 key.

The rest of these are bad, though:
> semicolon maps to the same key as comma
> used by Speaks entire document.
> used by Speaks the current flat review character.
> slash maps to the same key as 6
> used by Speaks the title bar.
> used by Go to bookmark.
> bracketleft maps to the same key as f
> used by Opens the Orca Find dialog.
> used by Reads the attributes associated with the current text character.

> Not possible request the default keybinding and the actual needed key code map?
> For example, compare the englis keyboard map and hungarian keyboard map with 47
> key code:
> keycode  47 = semicolon colon eacute Eacute dollar cent
> keycode  47 = eacute Eacute eacute Eacute dollar cent
> Not possible replace semicolon with é?

This would not be trivial to do, and I believe it would also require the US English keymap to be loaded on the machine.  Using the keycodes themselves would also be a bad idea because keycodes are not guaranteed to be the same from distribution to distribution (Sun keycodes differ from Linux keycodes, for example).

But, maybe some sort of exhaustive study of all possible default language keymaps could be done to try to map the physical layout to the keysyms.  We could then potentially try to store/use this map in Orca.

> Not help mark translation with builtin Orca laptop keybindings? Not need mark
> all x keymap with translation, enough to mark with builtin 51 Orca laptop key
> bindings, or detected problematic key bindings.

This is potentially a solution, but then it requires the keyboard layout to match the locale in use.  I'm not sure this is done everywhere.  I'm not sure if Orca can make the XKB calls necessary to detect which keyboard mapping is in use, or if this would even work because the user can also freely modify their keymap to be anything they want.

Bulk reassigning Will's bugs to the default assignee. (Sorry for the spam!)

(3.0 Planning Spam-o-rama. Sorry!)

Joanie, unfortunately the used workaround is not useful with Maverick and possible next versions.
When my system only installed hungarian keyboard layout, for example the sayall document command keystroke (Capslock+semicolon) conflicted with spokening actual character in flat review (CapsLock+, keystroke), because , and ; characters are the hungarian standard keyboard layout map are equals phisical place.
If I installed the US keyboard layout and put top of the list with this keyboard layout under the system>preferences>keyboard preference tool, after all login operations the keyboard layout is setted up default with english keyboard layout. This configuration workaround is working Lucid, but not working with Maverick.
The result this bugy working workaround under Maverick:
I possible use sayall document command, but unable to look the current character with flat review, this is a critical bug.
Perhaps have a very simple fix to fix this laptop keybindings conflicts general independent with used keyboard layout, I not like JAWS key bindings, but I not have got another keystroke ydea:
Need redefine sayall document command with Capslock+Down arrow key combination, this is fixing conflicts with Capslock+, and Capslock+Semicolon keystroke with non english keyboard layout with have the , and ; characters are equals phisical places. This new keystroke is not reserwed any function.
This is the critical important fix.

Unfortunately, we unable to redefine the say title and say status bar keystrokes, because Capslock+t key combination is reserwed with saytime and saydate functions. Impossible to define saytime and saydate function with Capslock+F12 key combination and defining say application title command with Capslock+t keystroke, because Capslock+F12 is reserwed with switch Orca gecko/caret navigation.
Say statusbar key combination optional possible define the Capslock+Pagedown key combination, but the original Capslock+/ keystroke not producing any conflicts, only problem have another phisical place the keystroke with english and another language depending keyboard layout. Perhaps this is an optional fix, not need very.

If you tell me what keystroke suggestion you accept, I welcome doing the patch and possible close this bugreport. The purpose have minimal number laptop keystrokes have phisical place difference with keyboard layout to another keyboard layout, and keystrokes not producing conflicts depending a non english language keyboard layout.
The only sayall document command keystroke redefining is fix the critical issue, but not resolving another issue (for example the title and status bar keystrokes phisical place difference with english and hungarian keyboard layout.
Unfortunately central hungarian keyboard layout change is not a good way, because this hungarian keyboard layout is a standard keyboard layout. :-):-)

Attila

Created attachment 172186 [details] [review]
This patch fix only the critical keybinding conflict with sayall document command and current character spokening command in flat review

Joanie, this is the minimal need fix.
I only doed sayall document command redefining, but not change another keystrokes before your suggestion.

Attila

Review of attachment 172186 [details] [review]:

While this seems harmless enough, it might introduce key conflicts for other users. 

Ale and I will be looking at all sorts of architectural issues soon. I will add this issue to the list. Perhaps we need an "alternative layout" feature.

Joanie, another critical issue if the US keyboard layout have not top of the keyboard layout list, now tested:
I unable to use say actual character information Orca command (Orca+f), because conflicting with opening Orca search dialog command (Orca+leftbracket) if the US keyboard layout list is not have top of the keyboard layout list in system/preferences/keyboard preference tool. This is happening because f and left bracket have equals phisical place with hungarian keyboard layout map, if I press ALTGR+f key I get a left bracket character.
This is unfortunately impossible to change, because this is a keyboard layout standard with hungarian keyboard layout.
I haven't got an absolute sure working ydea now how can possible fix this issue, but the say actual character attribute information command is very important with default work.
Perhaps redefine the opening Orca search dialog keybinding command from Orca+leftbracket to Orca+Ctrl+f keystroke and Orca+rightbracket with Orca+Ctrl+g keybinding command solves this issue, but not extra difficult this keystrokes with another users?
I very frayd the some keybinding conflicts are possible reproducable not only laptop layout, for example the now described issue is not only laptop keyboard layout specific.

Attila

Joanie, perhaps Orca+Shift+f key combination is better with opening Orca find dialog, and Orca+Shift+g better with search next entry command (Orca+rightbracket defined now)?
This keybindings change resolving the Orca+f keybinding conflict for example with hungarian language keyboard layout.
Monday I doing a joined patch with containing this changes, if not have another ydeas or conflicted keystrokes, and testing desktop keybinding layout the conflicting keybinding issues is possible reproducable or not.
I yesterday looked Ubuntu Natty alpha1 release, my general Orca laptop keybinding issues is reproducable too unfortunately.

Attila

Created attachment 176040 [details] [review]
Fixed my all wrote conflicting laptop key bindings

Joanie, please look this patch. I not found another conflicted laptop keybindings.
I doed following modifications, tested, working right all keystrokes if not installed the english keyboard layout map, not have any keybinding conflicts:
I redefined the sayall document command with CapsLock+Down arrow keystroke, because if Ubuntu Maverick installed only hungarian keyboard layout, the original Capslock+semicolon keystroke is conflicted with read current character with flat review command (Capslock+, keystroke). Possible use the sayall document command, but unable to use with read current character with flat review command.
I changed the Opening Orca find dialog from Orca+Bracketleft to Orca+Ctrl+F keybinding command, because this old keystroke is blocked with present actual character attribute keybinding command (Orca+f) for example with hungarian keyboard layout. This is happened because the f and bracketleft key is have equals phisical place with hungarian keyboard map and this is not changeable.
I changed the Find next string entri (Orca+bracketright) with Orca+Ctrl+g keystroke, and changed the find prewious entry command (Orca+Shift+bracketright) with Orca+Shift+g keystroke.

You accept this modifications, or you have got better suggestion?
Possible fix this problem before next stable version?

Attila

Hy Joanie,

This issue is reproducable with final Ubuntu Oneiric stable version.
If only hungarian keyboard layout are installed, the prewious described original keystrokes are conflicting with other important Orca laptop binding commands.
If installed english US keyboard layout and this keyboard layout are in top of the keyboard layouts list, unfortunately after login the US keyboard layout the default layout with hungarian language, so this workaround are unusable.
Please commit my patch for master version if this is possible, or suggest a better solution to fix this bug with I18N dependent.
All hungarian Orca users manual redefining this conflicting keybindings is not a good alternative my openion.
What your openion if we marking this conflicting keybindings for translation?
What simplest your openion: simple changing this keystrokes general for example my patch doing keystrokes, or marking this keystrokes for translation and prowide possibility with I18N teams to defining own keystrokes this conflicting commands?
The first method are better with documentation related works, because all Orca docs translators need using equals keystrokes when doing the documentation translation.
Second method are good, if an I18N team would like different phisical keystroke without need redefining original english laptop bindings.
Other non english language teams need replacing for example with sayall command binding with he's own keyboard layout phisical combination, for example in hungarian language the right command binding is Orca modifier+é keystroke if hungarian keyboard layout is using, this keystroke phisical place are equals with Orca modifier+Semicolon binding if the english keyboard layout are using.
I think I trying this way fix to I see the result.

Attila

Ok, my marking translation ydea doesn't working full right.
The key names is possible translatable, but not I would like form.
For example, if I replacing semicolon word with eacute word in hungarian translation the patched version, the keybinding conflict is not happening with flatreview sayall character  command and say entire document command.
If this keynames are translated, visual presenting for example with eacute word with Orca keybindings list in Orca preferences dialog. Happening similar problem for example with original key bindings, for example I see hungarian with the Orca keybinding command name, but with keybinding I see visual with Orka módosító+semicolon keystroke.
This tested marking translation method are not good, because if I switch for example english keyboard layout, sayall command will be unusable with english keyboard layout if I using hungarian language with Orca.

Attila

Prewious I setted hungarian keyboard layout with use system wide possibility in gnome-keyboard-properties preference tool, this possibility are doing the change without changing the keyboard layouts list order. English layout have top of the list, so Orca laptop bindings commands have equals phisical place with english keyboard layout, but the hungarian layout the default my system.
Look following bug:
https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/779573
If I see right, GNOME3 dropped this possibility, so need fixing this bug anyway with next development cicle.
If only hungarian keyboard layout are installed, described Orca bindings are unusable, because conflicting the bindings with other important keybinding commands.

Attila

Review of attachment 176040 [details] [review]:

Thanks for your patch. I would rather get to the bottom of the problem and fix it properly rather than hack around it by redefining keybindings. After all, even if we redefine these particular keybindings, we are in danger of running up against this problem with future commands.

Hy Joanie,

I absolute agree your comment. Have you ydea how can possible fixing this problem independent the used keyboard layout?

Attila

Joanie, possible fixing this bug before 3.4 stable release?
I have got an ydea, but I don't no how can possible implementing this with Orca:
Well, we known what characters (key names) producing keybinding conflicts, hungarian keyboard layout absolute sure.
Sayall operation associated with semicolon keyname, but in hungarian keyboard layout the phisical english semicolon character place have é letter (eacute keyname).
We possible write the semicolon character with ALTGR+comma combination, so the comma and semicolon characters are have equals phisical place.
When if I using only hungarian keyboard layout under GNOME3, and press Orca modifier+comma keystroke, Orca detect this command with sayall operation I think.
Look the Orca find keybinding:
Orca find are associated with Orca Modifier+leftbracket binding, but in english phisical left bracket character in hungarian keyboard layout have ő character (oacute keyname I think). We possible write left bracket with ALTGR+f keystroke.
If possible querying the actual used keyboard layout, possible doing a dinamic replacement the conflicting keybindings?
An example dictionary:
hu_conflicting_keynames={}
hu_conflicting_keynames['semicolon']='eacute'
hu_conflicting_keynames['bracketleft']='oacute'
hu_conflicting_keynames['bracketright']='uacute'

Attila

Could this be a duplicate of https://bugzilla.gnome.org/show_bug.cgi?id=436926?

Hy Marcus,

I think correct you linked bugreport, equals the issue.
I think better to append future comments with your linked report.

Attila