Hi Colin,
On Thu, Jun 4, 2009 at 4:25 PM, Colin Steinberg
wrote:
> Have you considered some kind of layered approach? Maybe an immediate
> interface to the physical keycodes, sending events for every _key_ press
> and release. Another layer could then use the windowing-system mappings
> to conv
Hi Folks,
Have you considered some kind of layered approach? Maybe an immediate
interface to the physical keycodes, sending events for every _key_ press
and release. Another layer could then use the windowing-system mappings
to convert these events to _character_ press/release events.
If this s
Hi Ralf,
Thanks for the links and explanation, this makes is clearer.
So what I can read from this is they the virtual key codes mapped to
physical events, and the printable characters are akin to state.
Robert.
On Thu, Jun 4, 2009 at 3:33 PM, Ralph Kern wrote:
> Hi Robert,
>
> here are the po
Hi Robert,
here are the pointers to the MS docu:
virtual key codes:
http://msdn.microsoft.com/en-us/library/ms927178.aspx
MS explanation for their term "virtual key code":
http://msdn.microsoft.com/en-us/library/ms927175.aspx
Reference for WM_KEYDOWN (has also links to WM_KEYUP and WM_CHAR in
HI Ralf,
Thanks for the info. Just to be clear on language and actions could
you clarify the following.
By virtual key codes do you mean the raw keycodes? I.e. whether you
press 'a' or have shift pressed to get 'A' you still get 'a'?Or
are the WM_CHAR the raw keycodes?
W.r.t key presses/ke
Hey,
* Mathias Fröhlich -- Thursday 04 June 2009:
> May be we need to track these up/down event pairs in *flightgear*.
We can't ATM, because we don't have the keycodes! That's why I started the
thread in the first place! And my assumption was that it's better fixed
once in OSG, than in every sing
HI Mathias,
2009/6/4 Mathias Fröhlich :
>
> Hi Melchior,
>
> On Thursday 04 June 2009, Melchior FRANZ wrote:
> [...]
>
> May be we need to track these up/down event pairs in *flightgear*.
> ... if an application needs these synthetic events, exactly this application
> should synthesize these event
hi,
perhaps some input from the MS Windows event API: They differentiate
between key press and release events (WM_KEYDOWN/WM_KEYUP) using
"virtual key codes" and "typed character" events (WM_CHAR) which is the
UTF-16 code of a typo generated because of some key press.
The virtual key codes includ
Hi Melchior,
On Thursday 04 June 2009, Melchior FRANZ wrote:
[...]
May be we need to track these up/down event pairs in *flightgear*.
... if an application needs these synthetic events, exactly this application
should synthesize these events?
You cannot expect that this special usage pattern of
From my perspective, if I were writing a game control scheme, I'd want
all downs and all ups with raw key codes. 'a' down, left-shift down, 'a'
up, left-shift up.
Just because application X is using the keys to type human words doesn't
mean that application Y has any relationship between shift
Hi,
* Robert Osfield -- Thursday 04 June 2009:
> I don't think calling it bug clarifies anything, [...]
I didn't call it a "bug" to clarify anything, but because the current
behaviour is without any doubt broken. Maybe I should have used the
MS euphemism "issue" instead. :-)
Your examples use t
Hi Melchior,
On Thu, Jun 4, 2009 at 10:43 AM, Melchior FRANZ
wrote:
> Making the physcial key number available in the event structure would
> allow us to fix our problem in FlightGear, though I think the bug
> is in OSG and should be fixed there.
I don't think calling it bug clarifies anything,
* Robert Osfield -- Thursday 04 June 2009:
> I'm in two minds if I'd would classify this issue as a bug, and I'm in
> two minds about your suggested remedy. The code is it stands right
> now doesn't enforce a matching of presses and releases, it just the
> way it works. It's a bug if your assume
Hi Melchoir,
Thanks for the extra explanations, this is really useful.
I'm in two minds if I'd would classify this issue as a bug, and I'm in
two minds about your suggested remedy. The code is it stands right
now doesn't enforce a matching of presses and releases, it just the
way it works. It's
Here's another illustration of what the patch does. The first part
is what the added code in KeyPress does, the second part is what
the code in KeyRelease does.
press '3' (with autorepetition), press shift, release '3', release 'shift':
key: 51, shift: 0, pressed: 1
key: 51, shift: 0, pres
Hi,
> Added the unmapped/modified key to the GUIEventAdapter is something
> we've discussed in the past.
That would allow applications to work around that OSG *bug*. But IMHO
that's clearly a bug.
> The unmodifed would have to be assigned in addition to the existing
> modified key, as just dro
Maybe I should have described the patch a little more, even though it's
rather short.
Initialization
--
Define an array _lastKey[] in which every physical key is mapped to a
keySym. All entries are initialized to -1, which means that the key
is not pressed. Array size is 256 on X11 (o
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
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 report
19 matches
Mail list logo
