How to serialize and display Gosu buttons (ideally)

By RavensKrag Date 2010-11-03 05:12

I don't see why serialization of the button ids would be a problem. You could always just store the corresponding characters, then use char_to_button_id to get the appropriate id for the system you're on. Unless I misunderstand something about how this works.

Regardless, I'm grateful for the un-depreciation, as I don't think I'd be able to support the Dvorak keyboard layout without it. Also, thanks for fixing the #to_blob problem. ^_^

By jlnr (dev) Date 2010-11-03 16:06 Edited 2010-11-03 16:08

> You could always just store the corresponding characters, then use char_to_button_id to get the appropriate id for the system you're on.

Yes, when there are corresponding characters. :) All the more reason to have name_of_key(id) instead of button_id_to_char(id). (Which I planned to write and deprecated the existing methods a tad bit too early...)

Even given all that, I am not sure if there is a Single Right Way to serialize a keyboard config. If I change from the arrow keys to WASD, then plug in a French keyboard with the A moved around, should Gosu remember that I use 'a'…or that I want Gosu::KbA (which is always the same key)? Lots of nitpicking opportunities here! :)

By Maytsh Date 2010-11-03 17:35

Speaking of which: What does Gosu actually do when I use, say, a German keyboard layout? Will the KbZ position change relative to the English configuration? Actually, I can think of four ways games routinely refer to keys:
* By position (WASD & co)
* By character (for keyboard input)
* By name ("Press button [X] to continue!")
* By function

A proper mapping mechanic could be really useful. Hm.

By Spooner Date 2010-11-03 23:39

The Kb vars are relative to a "regular" QWERTY keyboard.

* If you want the code for the key that is Z on a QWERTY keyboard then you use Gosu::KbZ. This method is the best for keyboard controls, since the keys will _always_ have the same physical position on the keyboard.
* If you want the code for the _letter_ Z, you ask char_to_button_id("z"). This will be the same as Gosu::KbZ if QWERTY but will be the same as Gosu::KbW on an AZERTY keyboard layout.
* If you want to know which letter is currently associated with the key that is Z on a QWERTY keyboard, then use button_id_to_char(Gosu::KbZ). This will return "z" on QWERTY or "w" on AZERTY.

This is useful when developing key configuration programs, or if you want your instructions to dynamically tell peopole what actual keys they should press (rather than just writing the static text "use WASD" and hoping they use QUERTY).

Anyway, just made that explicit as much to convince myself I understood it as any other reason :P

By erisdiscord Date 2010-11-04 02:36

Sometimes explaining something to somebody else is the best way to make sure you know it yourself.

By banister Date 2010-11-04 06:19

that's what she said

;)

By jlnr (dev) Date 2010-11-04 13:22

> This is useful when developing key configuration programs, or if you want your instructions to dynamically tell peopole what actual keys they should press (rather than just writing the static text "use WASD" and hoping they use QUERTY).

Yeah, that sums it up pretty well. :)

One thing about the key name display that you and Maytsh mentioned is: should it be localized? If yes, how and by whom? Is it "Ctrl (left)" oder "Strg (links)"? One of the questions that keeps button_id_to_char from growing into name_of_button(id). :(

By Maytsh Date 2010-11-04 13:45

Easy: If QWERTY is default for key mapping, English should be the default for names. To get other localizations an extra parameter would be required.

By jlnr (dev) Date 2010-11-04 16:38 Edited 2010-11-04 16:42

Hmmm, cannot see the easy logic there? :) QWERTY is the default for constant names only (maybe I should have named it KbPhysicalA-KbPhysicalZ?). button_id_to_char may well return 'ä' on a German system, so having German display names for other keys wouldn't be too unexpected.

But yeah, arguments would probably make sense.

BTW: Just saw that your browser string is coming from X11. Gosu does not correctly handle KbZ on Linux right now, it always maps to the localized Z key I think. This is actually a bug. *cough* ;)

By Maytsh Date 2010-11-05 17:15 Edited 2010-11-05 17:18

Well, the locale here is English as well, so I wouldn't notice ;)

My point is: For better or worse, English is pretty much the default for everything, so until you want to implement localization in honest it is best to stick with it. I mean, let's face it, most Gosu games will probably never get to that stage. And when they do, passing some parameters to Gosu is probably the least of the programmer's worries.

By jlnr (dev) Date 2010-11-05 18:15

I think Windows has a method to get a key's name, and that always returns the localized name AFAIK. So the question is not whether to implement localization or not, but whether to *avoid* it or not. And I think we should, by using an English-only custom implementation. But we all seem to agree on that part anyway. Yay!

By Maytsh Date 2010-11-06 14:02

Hm, it would be kind of strange, on the other hand, if it only was a slight reformatting of the key's in-program name (KbA & co). With Haskell, you already have that essentially for free, so it would feel kind of redundant.

By jlnr (dev) Date 2010-11-06 15:02

Well no, because KbA would not always be 'A'. For KbShiftLeft it would probably always return "shift (left)" though. And as mentioned below, it could already respect OS conventions.

By Spooner Date 2010-11-04 14:11

I'd say the localisation is up to the developer, as long as the names returned are in English, consistent and documented. If Gosu localizes it automatically and doesn't localize to every language in the world, then it is impossible for us to fill in the blanks. That said, I think all "standard" buttons are going to be the same over every keyboard, so I would base my i18n from the numeric constant rather than from the name unless the name was also a constant.

# Assuming the Gosu::Kb* codes are not consistent for "named" keys on different layouts,
# we need constants to recognise those names so we can internationalise them.
name = button_id_to_char(id)
name = case name
when Gosu::KbEnterName then t("key.enter") end
etc
else
name
end
end

# Assuming the Gosu::Kb* codes are consistent for "named" eys on different layouts, we can
# use the existing key codes.
name = button_id_to_char(id)
if name.size > 1
name = case id
when Gosu::KbEnter then t("key.enter") end
etc
end
end

I am personally using i18n (the one from Rails) for my internationalization efforts.

Sorry if I'm over-thinking this.

By jlnr (dev) Date 2010-11-04 16:40 Edited 2010-11-04 16:49

> That said, I think all "standard" buttons are going to be the same over every keyboard

The Ctrl keys are labeled Strg in all German speaking countries, and the space bar is usually called 空格 in Chinese. And then there are per-OS names like "Start key" (Windows) vs "cmd" (Mac, can also use vendor-specific Unicode entity) vs "Meta" (X11/Linux).

I think the latter distinction could/should? be handled by Gosu. Games can then add localization tables for the languages they are actually localized into. In the actual game, I am thinking along the lines of:


display_name = Gosu::name_of_button(id)
return my_localization_replacements[display_name] || display_name

Man, what a mess. :D But it seems we all agree on English, easy-to-localize return values.

Edit: Oh, you meant the scancodes. They are the same across keyboards and languages, but not across operating systems. They can change between everything that needs a new compile, i.e. even 32-/64-bit versions of the same OS.

By Spooner Date 2010-11-04 20:15

No, I meant that although letters and symbols "move around" based on keyboard layout (with respect to the QWERTY-based Gosu::Kb* constants), the named keys do not (return is always where return is and does what return does and is always represented by Gosu::KbReturn).

By jlnr (dev) Date 2010-11-04 21:46

Consider my posting a response/addition to your code then :)

By Maytsh Date 2010-11-04 13:46

Interesting to know. I better put a note on that in my documentation...

By RavensKrag Date 2010-11-04 19:27

> since the keys will _always_ have the same physical position on the keyboard.

I understand this is the way that the constant is supposed to be implemented, but this is not the case, at least for me. I'm using Ubuntu linux, with the ruby version of Gosu if it makes any difference.

I use the Dvorak keyboard (as mentioned previously) so this is rather important to me.

This implementation would work fine imo, if it were actually the real implementation ^_^;

By jlnr (dev) Date 2010-11-04 21:51 Edited 2010-11-04 22:25

See my response to Maytsh, this is a bug in the current implementation of Gosu on Linux. Not really sure which API gives me the scancodes. Contributions welcome, this is pretty far from all my open loops in Gosu right now :)