Assigning a keyboard shortcut to a button

[FourthWorld]

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.

If 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.

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.

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.

[bogs]

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.

I found, from my submission, it is actually considered a 'bug', and apparently it was spotted all the way back in Version: 8.0 A 1. I'm surprised (but probably shouldn't be) that this wasn't fixed somewhere along all the DPs since that point.

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.

The first letter thing is new(ish), way back when I started using VS ('98 or so), doing gui design in VB you'd just put an ampersand wherever you wanted the shortcut to be, for example in an [Exit] button, you'd put the label as E&xit, denoting 'x' as the shortcut/accelerator key. Pretty sure it was the same in Delphi 5 to 2k (but would have to whip Delphi out to find out). Interesting that the accelerator keys aren't underlined in Lc/Mc, as I mentioned the whole point is to indicate which letter is the key, just as you see in a menu. In fact, in the menu builder there is a perfect example of it.

Selection_003.png (15.71 KiB) Viewed 6539 times

While I can't speak for the majority of dev's today, I do know that again, up to Win8 they were very much in use, and depending on the person writing the application in Linux, I see them in constant use there as well. The screen shot above was simply the first one I came across in a general search, there were plenty of others

As for the Gnome screen shot, is the Cancel button triggered by the "X" key? Icons are different from accelerator keys.

Gnome? I thought I mentioned that was XFCE In that dialog, there are actually 2 buttons with 2 accelKeys, the 'S' in all settings, and the 'C' in close. The icon on the button is another thing I like to see, but it isn't an accelerator key, it is just an icon on a button. AccelKeys, as I may have said somewhere before, *should* be underlined, other wise whats the point?

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.

I agree with this to a point, I agree that as an experienced dev, you should be able to figure out and easily access any property you want. I further think that certain properties shouldn't require research to reach. I'm not of the mind that Lc should become 'every other IDE', certainly, but I don't see the need to remove something that is common to it's own history and as I may have mentioned, probably looked for by anyone that dev's for people who are keyboard dominant, never mind that a beginner isn't going to know how to access every property on their own when they start and shouldn't have to code in what has been and should be there by default.

You and I are roughly on the same page for the rest

[FourthWorld]

The first letter thing is new(ish), way back when I started using VS ('98 or so), doing gui design in VB you'd just put an ampersand wherever you wanted the shortcut to be, for example in an [Exit] button, you'd put the label as E&xit, denoting 'x' as the shortcut/accelerator key. Pretty sure it was the same in Delphi 5 to 2k (but would have to whip Delphi out to find out). Interesting that the accelerator keys aren't underlined in Lc/Mc, as I mentioned the whole point is to indicate which letter is the key, just as you see in a menu. In fact, in the menu builder there is a perfect example of it.

I don't believe the first letter things is a technical requirement, just that the Win Guidelines suggest following it for controls. For menus of course Alt-key shortcuts can be any character in the menu item label (though even those seem slowly fading in favor of Ctrl-key shortcuts, and once again aren't completed in LC: current specs require apps to hide the underline until the Alt key is down, but LC currently shows the underline persistently).

[bogs]

...current specs require apps to hide the underline until the Alt key is down, but LC currently shows the underline persistently...

Lc's doing it right in that case, and the HIG guidelines team for each OS saying it should be hidden need to go to re-education camp

[richmond62]

saying it should be hidden

That's daft:

1. Probably not all Windows users are aware of the need to press the Alt key . . .

Supposedly Windows is "so simple" that "anyone" can get up-and-running with it in
next to no time, and while we are all aware what advertising hype is, and that
Microsoft have such traction they virtually don't need to advertise at all, hiding
things away only to let them be revealed when one presses the Alt key is doing
their users a disservice.

2. Macintosh does NOT have that requirement.

3. Xubuntu does NOT have that requirement.

Personally I hate those apps that promise the user to access "hidden features"
of their OS: the features shouldn't be hidden in the first place: and when,
eventually, after wrestling with one's system for 20 years you find that you could
have saved 20% of your life just by accessing some "hidden features" . . .

[richmond62]

HIG guidelines

They are ONLY guidelines, and while the OS-pedlars want to bully us into conforming to their
vision of the bright new future (and when push comes to shove that is what HIGs are), or,
as they coyly say "play nicely", we are under no contract (either moral or otherwise) to
do that.

It is probably nothing more than bloody-minded to use shortcuts that conflict with an OS's
own ones, or make one's own idiosyncratic conventions

[OK; from now on, in my app Alt-W will 'copy', Ctrl-F will paste,
Cmd-Alt-Ctrl-U will make the computer sing the Horst Wessel song.]

However, if one wants to have an app-specific keyboard shortcut that does not
conflect there should be no besetting reason why one shouldn't use it.

[bogs]

You know, I was poking around in Mc again today to see how it got along with 9.x (um...not real terrible actually).

Anyhoo, I came across the other part of the mystery with this property (figures huh?) with the keyword not being underlined. The reason is (drum roll) because that is set by the mnemonic (another property that has disappeared from you know where).

However, unless you are running on winders, or deving for iOs or android, you'll never see the underline for some reason

Comments:
The mnemonic is any number between 1 and the number of characters in the button's name. The character at that position is underlined, and pressing the Alt key with that character sends a mouseUp message to the button. If the number is zero, the button does not have an Alt key equivalent.

This property has no effect on Mac OS or Unix systems.

Go figure, works on Winders, iOs, and android though, apparently

[jacque]

Mac, iOS, and Android don't use underlining in menus or buttons, it's just a Windows thing. I'm not sure about Linux.

[richmond62]

Well . . .

. . . Firefox in an XFCE desktop uses underlined letters . . .

as does LibreOffice 6.

BUT, Linux being "the Wild West", your mileage may vary.

[FourthWorld]

The Alt key shortcuts are indeed mostly a Windows thing. Win 3.1 IIRC, before MS licensed UI elements from Apple. Motif supported then back in the day, but I don't know of any systems that ship with Motif anymore. Now all three desktop platforms favor Ctrl key shortcuts instead, with useful consistency within and between the platforms.

Given Windows' market size Microsoft is obliged to maintain legacy conventions far longer than their more marginal competitors, so the Alt key shortcuts do indeed remain supported in the OS even as much of the rest of the system has moved on to favor the more universal Ctrl key shortcuts wherever practical.

As a side note, it may be helpful to keep in mind that we're discussing menus now, not push buttons. That both forms of command-invoking controls happen to belong to the "button" class in MC/LC is an architectural choice made by the original engine author, unrelated to user expectations or HIG guidelines for menus and push buttons, which of course are functionally and conceptually very different types of objects.

[bogs]

[1.]The Alt key shortcuts are indeed mostly a Windows thing. Win 3.1 IIRC, before MS licensed UI elements from Apple. Motif supported then back in the day, but I don't know of any systems that ship with Motif anymore. Now all three desktop platforms favor Ctrl key shortcuts instead, with useful consistency within and between the platforms.

[1a.] See, this is what makes me think we are not always talking about the same thing. I only ever remember seeing Alt key combos in relation to menus, not to buttons. Button key combos as far as I can remember have always been Ctrl key combo driven, they have always had the shortcut key underlined, and if you felt generous, you might include a tool tip giving a more indepth explanation. There are exceptions to this, such as Ctrl + c or x or v (copy, cut, paste in order), but I believe that is the way it is because you would not find those commands on a button usually, although I have seen "Copy" buttons obviously.

In each *Os I ever worked in, this was consistent and expected as far back as I can remember.
*Os - OSX and Windows 10 being the two exceptions for me, I have never spent a lot of time working in either.

As a side note, it may be helpful to keep in mind that we're discussing menus now, not push buttons.

I am discussing only buttons, as this is what the Op was asking about. The menu system Lc/Mc had works as expected, pretty much as every other development environment always has that I have played in.

Given Windows' market size Microsoft is obliged to maintain legacy conventions far longer than their more marginal competitors, so the Alt key shortcuts do indeed remain supported in the OS even as much of the rest of the system has moved on to favor the more universal Ctrl key shortcuts wherever practical.

Again, I've never seen an Alt key combo in any other event as anything other than driving a menu selection. If I hit [Alt + f] for instance, no matter the Os or the application, I'd expect to see a file menu open. That is pretty much universal, and Lc/Mc covers that correctly as far as I can tell.

An example of a programming environment that I was talking about earlier would be Fpc/Lazarus (Pascal based, like Delphi). Here is their property sheet that you were mentioning earlier, and the exact steps to produce an underlined Ctrl key combo on a regular button.

Selection_003.png (23.39 KiB) Viewed 6338 times

The underlined 'x' is just an example, today considering ctrl + x is expected to cut something to memory, I would probably use the more universal ctrl + q and label the button Quit (if my program had any kind of copying or pasting allowed / expected).

If we go back to Mc, this behavior is well demonstrated again by the selections available (this is on a Linux system which is not Motif, btw).

This was also available in all of the Lc's from 1.1 up. If we now move on to lets say, 7.1.4, what do we find? Why, that it *still* applies, of course! (This also on a linux system that is not Motif).

The available accelKeys are ctrl/cmd, alt, and shift, btw.

Not only does it still apply, but they made it even easier to reach! Before, in Mc, you had to count the letters of your button's name, then type in the integer that you wanted underlined, 0 = no underline. In Lc, you hit that mnemonic dropdown, and it has all the letters of the button name that you can choose from in the dropdown? MARVELOUS!!

Well, marvelous except for whatever reason, bug, by design, misguided forethought, whatever, it was removed going upwards from there.

Again, we are not talking about menus or just alt keys, and in this case I'm not going to sweat whether it is mentioned in the guidelines or not, as Richmond pointed out, they are after all only guidelines, and there are plenty of examples of long LONG running well used applications that include them because I would have thought anyone that used em would expect them to be there.

Obviously if you design interfaces without taking advantage of them, then you would have little use for them, but the keyboard predominant users I would think immediately look for those hints and expect them to work, I know I do.

[FourthWorld]

[1.]The Alt key shortcuts are indeed mostly a Windows thing.

[1a.] See, this is what makes me think we are not always talking about the same thing. I only ever remember seeing Alt key combos in relation to menus, not to buttons.

I have to admit as this thread's grown I'm not sure I can follow it myself. The screen shot of the menu in a recent post threw me off. The OP has the answer anyway, so I probably won't further confuse this long thread.

If I hit [Alt + f] for instance, no matter the Os or the application, I'd expect to see a file menu open. That is pretty much universal, and Lc/Mc covers that correctly as far as I can tell.

Are we talking about buttons or menus?

FWIW I see that same behavior in Gnome, but not on MacOS. In Gnome the trigger key isn't rendered with any underline or other signifier, so this feature is completely invisible to those who don't already know it's there. And even on Win the underline is rendered only while the modifier (Alt) is down (except in LC, where the underline remains present regardless of the state of the modifier key).

If we go back to Mc, this behavior is well demonstrated again by the selections available (this is on a Linux system which is not Motif, btw).
Selection_004.png

Yep, that was put in when MC was born in '92 and anyone still using that old IDE will see it. I hear it was in earlier version of LC IDE as well. And IIRC the LC team has suggested they'd consider putting GUI support for that back in for those who enjoy the convenience if someone will file a request so they can put it in queue.

The property has remained in the engine the whole time, fully functional and always available.

Apparently all that happened is that the GUI for that property, as with other less-commonly-used props, fell out during the redesign.

So if someone will just file the request they'll probably get the GUI for it. And anyone who needs it can still use it as it's always been supported and no one plans on removing it.

This thread has been surprisingly long.

[bogs]

If I hit [Alt + f] for instance, no matter the Os or the application, I'd expect to see a file menu open. That is pretty much universal, and Lc/Mc covers that correctly as far as I can tell.

Are we talking about buttons or menus?

Huh, Either you are pulling on my leg, or I didn't make it clear enough the first time

So if someone will just file the request they'll probably get the GUI for it. And anyone who needs it can still use it as it's always been supported and no one plans on removing it.

Yes I did, and it was done before I did it, which I posted a link to wayyyyyyy back here

[FourthWorld]

If I hit [Alt + f] for instance, no matter the Os or the application, I'd expect to see a file menu open. That is pretty much universal, and Lc/Mc covers that correctly as far as I can tell.

Are we talking about buttons or menus?

Huh, Either you are pulling on my leg, or I didn't make it clear enough the first time

See also, from the post I was replying to:

I am discussing only buttons, as this is what the Op was asking about.

Both were clear enough in their respective contexts, but we did rather stray from the OP's topic. My earlier indulgence in this history of the feature was only to suggest reasons why it fell out of the GUI; as usual, Jacque's post in that regard was more concise, and apparently less distracting.

So if someone will just file the request they'll probably get the GUI for it. And anyone who needs it can still use it as it's always been supported and no one plans on removing it.

Yes I did, and it was done before I did it, which I posted a link to wayyyyyyy back here

Excellent. Thanks. Looks like that was a duplicate, which is useful here because it means others were asking about it as well.

For those following along the current bug DB report is here:
https://quality.livecode.com/show_bug.cgi?id=14824

[bogs]

Heh, as I read your last reply, all I could think of were two (different) conversations, one from "Cool hand Luke" with the warden where he said

What we have here is a failure to communicate!

and the other was the (in)famous Abbot and Costello "Who's on first" skit