Accelerator keys in dialogs not working / keyboard focus issues

Was watching Brian’s tutorials from yesterday on the earrings, and he mentions that in any command dialog (this one was for helix) you can type the underscored character to select the option (i.e. the alt underscore windows notion).

I don’t know how he’s able to get that to work, I can’t get it to work at all in any command dialog, nor have I been able to for as long as I can recall.

To illustrate I’ve attached the following video:

Rhinoceros001.mov (1.6 MB)

I initiate the helix command, and attempt typing “A”, “a”, alt-a control-a and none of them actuate the accelerator. I’ve tried this both with the UI set to have the command line options in the side bar and as a window, doesn’t work in either case for any dialog option that has a listed underscored accelerator.

Second Item (related and posted previously but shot a video of this one as well):

This illustrates the problem of focus issues with command option dialogs as floating windows. The problem is they are technically a modal dialog (or should be, as they pop up) and should retain focus. They don’t.

I first discovered this with a group name command options dialog. I have a group created, invoke a keyboard shortcut to bring up the name group dialog, and start typing but instead of naming the group, I’m renaming an object.

On close inspection in the video you can see the effects of the command dialog being cursor centric in terms of it’s focus, i.e. it ONLY works if the cursor is over the command options dialog, and even if you click and then move the cursor it loses focus and anything typed will not hit the dialog but go to any open text entry field that Rhino thinks has focus.

Rhinoceros004.mov (11.6 MB)

This occurs on both my work machine (info below) and the one at home (previously posted)

Software information

Software versions
Rhinoceros version: 5.0 (5A851)
IronPython version: 5.1.2015.131
Language: en (MacOS default)
OS X version: Version 10.10.2 (Build 14C1510)

Plug-ins
None

Third party kernel extensions
at.obdev.nke.LittleSnitch (4234)
com.nvidia.web.NVDAResmanTeslaWeb (10.0.3)
com.nvidia.web.NVDANV50HalTeslaWeb (10.0.3)
com.nvidia.web.GeForceTeslaWeb (10.0.3)
com.kensington.trackballworks.driver (1.0.0)
tc.tctechnologies.driver.PaeFireStudio (3.5.5 10988)
com.nvidia.CUDA (1.1.0)

Hardware information

Computer hardware
Hardware model: MacPro4,1
Processor: Intel Xeon CPU E5520 @ 2.27GHz
Memory: 8 GB
Architecture: Intel 64 bit

Video hardware
Graphics: NVIDIA GeForce GTX 285 1024 MB
Memory: 1024 MB
Screen size: 1920 x 1200, 1920 x 1200
Displays: DELL 2405FPW (94dpi 1x), DELL 2405FPW (94dpi 1x)

USB devices
SMSC: USB2223
Kensington: Kensington Slimblade Trackball
Apple, Inc: Apple Keyboard
Apple Inc.: Bluetooth USB Host Controller
Logitech: Logitech USB Headset

Bluetooth devices
None

OpenGL information

OpenGL software
OpenGL version: 2.1 NVIDIA-10.3.1 343.02.02f03
Render version: 2.1
Shading language: 1.20
Maximum texture size: 8192 x 8192
Z-buffer depth: 24 bits
Maximum viewport size: 8192 x 8192

Implementation settings
Use texture compression: No

Appearance settings
Antialiasing: 4x
Mip map filtering: None
Anisotropic filtering: None

Mark

type a then push the space bar (or return or rmb)

Wow.

If nothing else it illustrates the things the windows users take for granted that somebody who’s never seen it before doesn’t know exists.

2 months of daily use of Rhino later and had absolutely no clue that’s how it worked.

Ok, good to know. Still don’t understand the focus issues in the 2nd video. Tell me that’s as brain dead simple as this first one was and I’ll go crawl under a rock someplace.

=)

Thankee.

[quote=“LewnWorx, post:1, topic:20632, full:true”]On close inspection in the video you can see the effects of the command dialog being cursor centric in terms of it’s focus, i.e. it ONLY works if the cursor is over the command options dialog, and even if you click and then move the cursor it loses focus and anything typed will not hit the dialog but go to any open text entry field that Rhino thinks has focus.

[/quote]

i can’t make that happen (where the name field has focus then being able to call a command)…
what shortcut are you using to call SetGroupName?

when the command starts in your video, ‘My Curve’ has focus… why doesn’t whatever it is you’re typing as a shortcut go to that field instead?

I used command - option - g. How I’ve done all my KB shortcuts has been to go into customize, search for the command in the lower half of the customize dialog, click on the icon for the command in question, click in the Kb shortcut field and hit the key combo. It’s not an alias as you folks define them but a kb shortcut under customize.

I tend to set my Kbps commands by some combo of modifier keys and the first letter of the command. So for something like snaps I’ll have control option e for end, control option q for quadrant and so on. That way I only have to develop muscle memory for the modifiers and the rest are pneumonics.

Been doing it that way in pretty much every tool laden app that supports kb customization since oh about the time canvas and after effects 1 were in beta.

Just makes it semi consistent across apps. Less used commands I do via tool bars but things common to all apps (grouping, alignment, etc) are fairly standardized. Makes for far less to have to remember on an app by app basis.

By using modifiers I don’t have to think about stuff like if I’m I an editfield or not because the OS message pump grabs anything with modifiers and routes that to whatever object in the app handles those as opposed to the editfield unless it’s been specifically subclassed with event methods to trap for the combo in question. It’s worked in all the adobe stuff, macro media stuf, formZ, EI, infini-D, Macromodel, Swivel3d, VirtusWalkthough and every other 3d app I’ve used over the years, (dating myself horribly). In the rare cases where they didn’t natively support custom kb commands I’ve used QuikKeys to achieve the same thing.

What your not seeing I the video is that in the latter part I’m not even typing anything, just moving the cursor, and even though I’ve clicked in the command option dialog’s edit field, the second the cursor leaves the bounding rect of the window the focus reverts to the field in the object properties dialog which tells me the kb focus is being lost. Not sure if the command option window has been set up to be modal or not in terms of holding focus.

In all my code work for OSX (and granted I’m not doing anything in the graphics arena at all) I’ve typically set that type of window to be modal across the board, so anything that’s straight chars (sans modifier combination keys) will funnel into whatever editfield that last had focus in the dialog. Once in a blue moon I may have ran into an occasion where I’ve subclassed an instance of an editifield on a form and adding traps for modifiers but that’s really rare.

However, in thinking about it, this issue may be due to exactly that, a subclassed editfield. I’ve noticed the dialog vanishes anything I’m trying to set a group name and hit space (which is annoying as hell since I’m not used to naming things one way in one part of an app and a different way elsewhere), but I’m guessing the no spaces allowed in group names is an architectural internal file format restriction or something along those lines, so as a result you are probably trapping for the space to exit the dialog, or that’s an across the board thing with the command line?

If the former, could you not allow the spaces and strip them post return or enter or ok click? It’d make it a lot less frustrating to think you’ve named a group one thing and inadvertently hitting a space and not realizing or even seeing the dialog vanish, thinking the group name you’d set was “solids pre bevel” and the finding out later it was actually just “solids” because the dialog used the space as a “done” trigger? I can get that you may have a many versions old architectural restriction to having spaces in group names and I don’t think anybody would have an issue with the spaces being stripped from the group name, but it would reduce the potential for inadvertent user error a great deal.

I’ve named groups this way more than once and not realized it didn’t take anything after the space only to be burned by that later when selecting by another, similar name and not having them visible at the moment leading to deletion and other bad things simply because I didn’t notice the stuff after the space never got in to the group name.

yeah, i see it now too.

i think any keystroke that uses command or option without the shift key will allow this to happen… (command-G will do the same thing for example… except i use cmmd-G for _Group , cmmd-J for Join… cmmd-T for Trim… they don’t require any additional keys so i guess the way i’m set up avoids the behavior.)

if you tried setting it to cmmd-shift-G, then you wouldn’t be able to do what you did in your video.

not really sure if this is a problem with the modal dialogs so much as it is with clashing keystrokes… or something along those lines.


[EDIT]
i said – “if you tried setting it to cmmd-shift-G, then you wouldn’t be able to do what you did in your video.”

…scratch that… cmmd-shift-G will do it… shift-option-G wont…
if you type shift-option-G in a text editor(or this reply field), it will display a character… cmmd-shift-G won’t…
so any keystroke you assign that doesn’t have some sort of character binded to it, will exhibit the behavior.

There’s still something odd about the modality or lack thereof, in that once the dialog is invoked by any means, when the mouse leaves the bounding box the kb focus goes to the last text edit field that had it (i.e. the object name field on the main window if present). if you move the cursor back to within the group rename dialog, the focus hi light goes back to the group name field and again reverts when the mouse leave msg fires. It should be holding focus until a tab/return/mouseclick event.

Bear in mind I haven’t set foot in windows land in the better part of 20 years outside of our own IDE for our code stuff, so I have no clue how much of this comes from that arena. I’m about as much of a mac only guy as you’ll probably encounter.

i don’t disagree that it’s odd behavior… it is.
but it’s not the modal dialogs that are the problem… they work perfectly fine in most scenarios…

instead, you’ve sniffed out a problem which will occur in a rare number of circumstances…
that being-- calling a command while a text field has focus using a keystroke which doesn’t have a character tied to it and the command dialog needing further text input.

One thing i’ve noticed is that if your last click was, for example, in the Layers palette (where i am a lot), you have to actually click back in the modelling space in order for commands to run properly. This is one of the drawbacks of an “all in one window” application… there often isn’t visual feedback as to where your cursor/input is currently focused.

i remember there being a problem with that in the past but it’s been fixed for a while now… or, for me, i can work in the layers inspector and go right into commands without issue.

what are you doing, exactly, when you see the problem?

Tried some other variants. Noticed that if a key combo is already in use it doesn’t flag you to let you know it is. For example tried command control G (which apparently is the stock shortcut for “ghosted”. UI doesn’t let you know that, but probably should at least let you know it’s in use when you go to assign it. Granted there’s areas where it makes sense to overlap the usage of an assign, but it should be a conscious choice to do so, in order to ensure that the user understands and is specifically choosing to reuse in use combinations (hopefully in areas where the overlap won’t clash).

Will have to return to this later… Fiance’ is arriving and tomorrow we’re doing the knot tie thing. Cheers…

yep… been like that since shortcuts were first added.

http://wiki.mcneel.com/rhino/mac/keyboardshortcuts

[quote]Notes about your keyboard shortcuts

There is no error checking in the keyboard shortcuts you assign. Rhino will let you assign the same shortcut to more than one command and the resulting behavior is undefined. You can also assign shortcuts that are reserved by OS X, and these shortcuts won’t work in Rhino. The operating system will perform the shortcut first.[/quote]

The command option dialogs are not modal, but are modeless dialogs. They have to be, or you wouldn’t be able to do anything in the model like select objects, draw lines, or rotate the view.

This is a bit of an edge case. It will be fixed in the 5.1 release.

Perhaps I should note that you you can type commands and type command options and their values without ever moving the cursor to the command options dialog. Keyboard input while a command is active is sent to the command options dialog for handling.

Well that was the point of the bug report. Even when I clicked into the group rename text field, when the cursor leave the command windows text text goes into the last text field that had focus on the document window, this (in this case) renaming a previously selected object.