cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Properly cascading keyboard shortcuts

Properly cascading keyboard shortcuts

Hello,

TL;DR

Shortcuts and all_filer_project_dir files (perhaps others) should cascade properly through different customization levels rather than squashing lower-precedence customizations.

I've just been customizing v19 Creo Elements/Direct at the site and user levels, and I noticed that most of the customizations cascade in a well-ordered way, with a precedence of factory/corp/site/user, which works great. But the shortcuts (e.g. sd_shortcuts.acc) and the all_project_filer_dir files do not seem to cascade this way. They are in the category of “first file found in…” rather than “all files found in,” as described in the startup order documentation. This is problematic because a user that adds a SINGLE keyboard shortcut to their user level (say through the Customize menu) has blocked themselves from seeing ANY changes to keyboard shortcuts at the site level.


The idea is that keyboard and project directories should cascade in a similar fashion to all the other features. Keyboard shortcut additions (and removals!) should be recorded at the user-level, without stomping lower precedence keyboard shortcuts.


Here is an example.


Existing functionality:

Suppose the user has not modified any shortcuts so there is no user_customize/sd_shortcuts.acc, and Site/sd_shortcuts.acc has these shortcuts:

("CTRL E" :command "Extrude")

("CTRL M" :command "Mill")

("CTRL P" :command "Punch")


If a user changes the keyboard shortcut for "Punch", user_customize/sd_shortcuts.acc is created with the following shortcuts:

("CTRL E" :command "Extrude")

("CTRL M" :command "Mill")

("ALT P" :command "Punch")


Despite the fact that the user only intended to define the Punch shortcut, he just captured ALL of them. Now suppose a shortcut is added at the site level:

("CTRL E" :command "Extrude")

("CTRL M" :command "Mill")

("CTRL P" :command "Punch")

("CTRL S" :command "Stamp")

The user will not see the effects of this, because user_customize/sd_shortcuts.acc, rather than complementing and (where collisions occur) overriding shortcuts in Site/sd_shortcuts.acc, squashes all of them.


Proposed functionality:

When the user changes the keyboard shortcut for "Punch", user_customize/sd_shortcuts.acc should instead be created with only the following:

("ALT P" :command "Punch")

The only problem now is "How do you know if a user wants to remove a keyboard binding?" Instead of checking for its absence in user_customize/sd_shortcuts.acc, just record removals in that file:

("CTRL P" :command "Punch" :removal t)

Obviously for this to work the loading mechanism can no longer simply take the highest-priority shortcuts file and use that. It has to integrate the shortcut files at various customization levels (as it does with other things IIUC) but that doesn't seem too difficult.

Regards,

Rich Kinder

Keysight Technologies