|
Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
| Summary: | Generated Java KeyEvents don't have Location set correctly | ||
|---|---|---|---|
| Product: | ui | Reporter: | darren.p.kenny |
| Component: | AccessBridge | Assignee: | nospam4obr |
| Status: | CLOSED WONT_FIX | QA Contact: | issues@ui <issues> |
| Severity: | Trivial | ||
| Priority: | P4 | CC: | issues, patrick.wade |
| Version: | OOo 1.1 Beta2 | Keywords: | accessibility |
| Target Milestone: | OOo 3.0 | ||
| Hardware: | Other | ||
| OS: | Linux, all | ||
| Issue Type: | DEFECT | Latest Confirmation in: | --- |
| Developer Difficulty: | --- | ||
|
Description
darren.p.kenny
2003-04-30 09:22:22 UTC
Oliver: With modified bridge from dkenny you can see the UNKNOWN location information for all key events. . test - please ignore Accepted. The problem here is that the java-uno-accessbridge does not have this information either. In order to set the location of keys other than VK_NUMPAD[0-9] correctly, we need to create completly new infrastructure inside the office for this - it is quite late to make such changes. On the other hand, gnopernicus seems to use the numpad only with numlock on, so generating the location info for VK_NUMPAD[0-9] might be good enough for 1.1 ?! The features of gnopernicus, which require the location to be set correctly, will probably not work with OOo anyway because OOo key events are not consumable yet. Unfortunatly we will not be able to change this for the 1.1 release, so I am adjusting priority and target. BTW: the workaround proposed earlier doesn't really help, because also with activated num lock the AccessBridge doesn't know the location of the key corresponding to a KeyEvent. So mapping the number keys to VK_NUMPAD[0..9] was a bug that I have fixed in CWS uaa04. Seems that gnopernicus will use another mechanism for consumable key events, so that toolkit notification will only be used for key echoing. But therefor the location information is less important, so re-targeting to OOo 2.0. Since fixing this issue is not trivial and it is not clear if this information is really needed by Gnopernicus, I am re-targeting this issue back to 2.0 again until there is a clear demand for fixing it. For gnopoernicus in the following situation need the location of key. In gnopernicus the user can specify keycombanation named "user keys command", which has a set of key and modifiers. The number keys is are in this set (1-0). For layer commands the numlock is need to be active. In this case generated keys are need to be differecied by the main keyboard generated keys. e.g. numpad_1 to return a different keysyms as the 1 from main keyboard. Hi Paul, I was uncertain about if gnopernicus could achieve the same using XEvIE, but I have learned that it may take quite a while to get to work on linux. So I think we should find a solution for OOo 2.0 which can potentially be backported to the 1.1.x series. according to the announcement on releases (http://www.openoffice.org/servlets/ReadMsg?list=releases&msgNo=7503) this issue will be re-targeted to OOo Later. re-targeted to OOo 3.0 With CWS atkbridge (targeted for 2.0.3), OOo will get a "native" UNO <-> ATK bridge (see #i47890#), so there is no need to fix the UNO <-> Java bridge in this regard, especially since key events are not dispatched via this bridge on Windows. . |