KeyButton overlapping key binding label

[GSculerlor]

[bdach]

Could apply truncation (as in #6023 and similar), but honestly those binding names seem a little long - maybe some FontAwesome usage could be in order here? (i.e. replace joystick with 🕹 / 🎮 , directions with arrows ⬇️⬅️)

[peppy]

joystick can be shortened to joy as a first step.

[smoogipoo]

Pretty sure this is all framework-side, and I highly disagree with changing framework-side components for a failing in osu!. In this case I'd like to see osu! provide the naming, rather than using framework strings.

[peppy]

osu! side is fine, yes.

[eclipsek20]

joystick can be shortened to joy as a first step.

I know this is an old thread, but just incase uses this idea, I think it would cause confusion, a better way to shorten it would be padbtn or joybtn indicating that this is a button, or perhaps using the the above implementation but with a help section or a help icon explaining this.

[Susko3]

In this case I'd like to see osu! provide the naming, rather than using framework strings.

Hmm, what if the framework exposed a localisation namespace, eg. osu.Framework.Resources.Localisation.InputKey, and returned LocalisableStrings instead of raw strings for key names. This could allow the game to customise the framework strings to its liking, and also has the added bonus of being able to translate the key names. Eg. on a German keyboard, Ctrl is usually printed as Strg.

Of course, not every input key would get its own translation string, some would use formatting:

public static LocalisableString Control => new TranslatableString(getKey("control"), "Ctrl");

public static LocalisableString JoystickButton(int button)
    => new TranslatableString(getKey("joystick_button"), "Joystick {0}", button);

I think the hardest part would be integrating framework localisation to existing tooling. The shape of the *Strings.cs files could be made as similar as possible to existing osu! localisations to make it easier.

The same framework-provided localisation namespace idea could be used for localising other framework strings (https://github.com/ppy/osu/discussions/22226).

[smoogipoo]

Conceptually that sounds like a fine idea to me.

[frenzibyte]

I don't understand this direction? Using LocalisableString/TranslatableStrings infers that these strings should be sent to crowdin and be localisable by the community, but that doesn't make any sense.

For the original issue at hand, it's one of two options, depending on what the intent of KeyCombination.GetReadableString is:

1. If the intention is for the method to return short readable strings for the user, then I see no reason not to replace Joystick with the joystick icon in there and call it a day.
2. Otherwise, change the key binding settings overlay to display joystick keys with the joystick icon, since the issue is with the display of the settings overlay overall, and we don't want to change the method to be more human readable.

[smoogipoo]

(1):

• Why should keyboard keys not be ⌨️ A and mouse keys be 🖱️Left to match?
  • The point I want to make here is that those emojis suck, at least on the GitHub font. Games are opinionated in the way they display things, see this example from Apex Legends: https://github.com/ppy/osu/assets/1329837/7b886624-5356-476d-88cc-ba922b09fcb3
• What do you do when the user's font (if they have something like an OsuSpriteText defining its own font) doesn't have those particular code points?

Imo, the framework should provide sane values and not sane displays of values.

(2) Would be fine.

[frenzibyte]

• Why should keyboard keys not be ⌨️ A and mouse keys be 🖱️Left to match?

In my own opinion, keyboard keys should usually appear without a preceding emoji, since they're the default input device for any key binding configuration section. Mouse buttons...maybe, maybe not. Joystick input feel like a special case especially since the name of some of their buttons conflict with the keyboard (e.g. A, B, X, Y), so having an emoji preceding that looks like a nice way of differentiating it from keyboard keys while not being too long for each use case to handle locally.

• What do you do when the user's font (if they have something like an OsuSpriteText defining its own font) doesn't have those particular code points?

I tend to think that icons would always be supported using FontAwesome, but I suppose some fonts cannot mash well with FontAwesome. This is a fair point.

[smoogipoo]

Sure, if they're using FontAwesome. But, FA only shows icons, and we don't support multi-font SpriteText, and the same is true in reverse.

feel like a special case especially since the name of some of their buttons conflict with the keyboard

Aside from them not being named by their platform's label, that's why they're Joystick 1, Joystick 2, etc, no?

And that's another point - what if the user does want to show the platform label? Whatever is changed here immediately becomes nothing more than a half-solution for osu!'s sake...

[frenzibyte]

Sure, if they're using FontAwesome. But, FA only shows icons, and we don't support multi-font SpriteText, and the same is true in reverse.

I believe we do? SpriteText looks up glyphs using the FontStore, which searches on every font added to the game (icon needs to be passed by character from FontAwesome class). That being said, baseline alignment looks to be incorrect for some particular reason:

Either way, with the points given above (and the baseline alignment issue here), I would stick to just locally handling this in osu! (SettingsOverlay implementation) and call it a day.

[Susko3]

Here's how it looks like in osu!