Hi Melchior, Added the unmapped/modified key to the GUIEventAdapter is something we've discussed in the past. The unmodifed would have to be assigned in addition to the existing modified key, as just dropping the mapping would break exisiting applications, not doing the mapping would also require 3rd party apps to add the mapping which in turn would require knowledge of the windowing system that their apps would required.
Reading your email I could pick out exactly what you were doing, but it sounded like you were duplicated events which doesn't does appropriate as again this would break applications. Robert. On Wed, Jun 3, 2009 at 8:25 PM, Melchior FRANZ <melchior.fr...@gmail.com> wrote: > At the moment there's no guarantee that for a key that triggered a key-press > event before there will ever be the matching key-release event later. This > is a problem for applications like FlightGear: here pressing the b-key, for > example, applies the brakes on the landing gear until the key is reported > released. If there's never a release, then the brakes remain stuck, until > one pressed/released b again. But how could the release event possibly get > lost? Consider this: > > 1. b down -> 'b' press event > 2. Shift down -> shift modifier set > 3. b up -> 'B' release event (but 'B' was never reported pressed!) > 4. Shift up -> shift modifier unset > > > Well, letters aren't really a *big* problem. We hack around that by checking > for an a-release if maybe 'A' or Ctrl-a was reported pressed before, or for > an A-release if maybe 'a' or Ctrl-a ... etc. > > > But what about this case: > > 1. \ down -> '\' press event > 2. Shift down > 3. \ up -> '|' release event -- '\' remains stuck!! > 4. Shift up > > We can't hack around that, because it depends on the keyboard layout whether > \ and | are on the same key. This information is lost for the OSG client and > can't be retrieved in a cross-platform way. That's OSG's job. > > > One way to fix that would be to store all reported symbols for press events > per > physical key, and to make sure that the same symbol will be reported for the > release, even if that means to inject an artificial release. This works here > in my local build. (The attached patch is not meant to be applied -- I'd make > some more cleanup before. All usage of _keyMap could then be removed, too.) > > Any comments on that? Windows and Mac maintainers would have to implement the > same solution, which is the main reason for the RFC. Otherwise I would just > have submitted the patch. And I can only remove the hack in FlightGear, once > all platforms work correctly. > > (Should EventTime for the generated release event differ from the press event, > e.g. by subtracting a very small time?) > > m. > > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org