I'm not really sure how much use keycodes are, in the general case. For physical location you always want scan codes, and for text you always want to let the OS do its full text interpretation (otherwise foreign languages are going to bite you, sooner or later). On Tue, Oct 11, 2016 at 4:50 AM, Rob van der Most <[email protected]> wrote:
> It would indeed be a good idea to return both. The documentation should > then include some of the rationale for using (or not using) one or the > other. At least mentioning scancodes are considered always the same > physical location, while keycodes will vary. > > Rob > > On 11 October 2016 at 10:23, Benjamin Moran <[email protected]> wrote: > > My understanding is that the scancodes -should- be in the same physical > location on every keyboard, whereas the keycodes will vary between keyboard > layouts. I think the SDL wiki sums up the situation pretty well: > https://wiki.libsdl.org/CategoryKeyboard > > I read an SDL mailing list post about this recently, and the reason for > the current implementation (if I remember correctly) was: > Sometimes you want the locations to be the same, such as WASD should be > handled the same, regardless of what the keys are called. In other > instances, such as pressing "I" to bring up "Inventory", you want the key > to represent the actual letter of the alphabet. > > > On Tuesday, October 11, 2016 at 2:25:17 PM UTC+9, swiftcoder wrote: > > I'm had thought that SDL keycodes are stable across keyboards and keyboard > layouts? > > At any rate, Apple's scan codes are definitely stable across > machines/keyboards/languages. > On Mon, Oct 10, 2016 at 6:04 PM, Benjamin Moran <[email protected]> > wrote: > > I've read about this issue a bit, and think that it would be nice to have > both available. Maybe it would be nice if the input events returned both. > > -- > You received this message because you are subscribed to the Google Groups > "pyglet-users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/pyglet-users. > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "pyglet-users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/pyglet-users. > For more options, visit https://groups.google.com/d/optout. > > > -- > You received this message because you are subscribed to the Google Groups > "pyglet-users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/pyglet-users. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "pyglet-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/pyglet-users. For more options, visit https://groups.google.com/d/optout.
