I don't disagree. While this is the first time I've read a discussion of the accelKey in all my years with LC, if folks are using it they should consider a pull request putting it back.bogs wrote: ↑Sat Mar 31, 2018 5:20 pmIf it was "common" enough to include in every version of Lc in a much smaller property palette up till NOW, I'd expect it to be there if I were using a newer IDE. We're not talking about adding some new kind of thing here, or "every property ever made", we're talking about something that has been there since the start and, pertinent to this topic, was being requested when it shouldn't be a mystery on how to reach it.Remember that an Inspector is a specific design choice to provide quick access to the most commonly-used properties. As such, the LC Inspector does not attempt to provide GUI controls for every property the engine supports for every object type.
But considering how many properties, and even property options, aren't represented in the Inspector ("menu" is omitted from the button styles, for example), I can't speak to their process for prioritizing what gets included and what gets left out.
On the utility of the property itself, I don't mind being corrected: the Windows HIG does indeed explicitly mention using accelKeys for buttons - see "Access Keys" about a third of the way down here:
https://msdn.microsoft.com/en-us/librar ... 42465.aspx
Windows' "access keys" are more limited than MC/LC's "accelerator keys" in that the Win HIG suggests only the Alt key or no modifier key as the trigger. They also require developers to use only the first letter of a label for the trigger key, which may not be practical in some cases where they key is also the first letter of a menu or has some other common use.
It's also worth nothing that despite their mention in the HIG, they aren't commonly used. In the screenshot above, there are many interactive controls but only one with an access key (and a button which is continually debated in UX circles as to whether it makes sense to use at all - conceptually, when is "Apply" not okay?).
As for the Gnome screen shot, is the Cancel button triggered by the "X" key? Icons are different from accelerator keys.
Both examples remind us of other areas useful for both us as UI designers and for the LC team as engine implementers: aside from Mac, modern UIs do provide good support for keyboard navigation in layouts. But they tend to favor a small number of keystrokes applied commonly across controls more often than control-specific key combos. We move from control to control with tab, activate option controls with Space, navigate them with Up and Down arrows, etc.
The challenge for the LC team is that option controls do not respond to keyboard navigation as well as their OS-native counterparts. And the Ask and Answer dialogs and other layouts in the IDE do not respond to the Tab key to navigate among buttons.
And with accelKeys, the LC engine doesn't render them with the underlined character.
So adding that prop back to the Inspector is only the first step for the engine team.
For us devs, I believe it's more useful to have all props available than a selected subset. Property Sheets are the common solution IDEs use for this purpose. They can be dynamically populated at least as efficiently as any other, but provide access to more elements given the same space.
This design decision has sailed, though; the LC team has made their preference for the more consumer-app-oriented Inspector clear.
So if we want a Prop Sheet we'll have to make one. And a few of us have.
That's one of the things I like about LC: since the IDE is just a collection of stack files, any stack files can be used to augment or replace things however we like. Like the flexibility of Linux but so much eaiser, everyone gets exactly the UI they most prefer.