need a proper means to handle command keys for tools

[processing-bugs]

Original author: b...@processing.org (June 07, 2010 00:25:28)

This bug automatically added from:
http://dev.processing.org/bugs/show_bug.cgi?id=140

Comment from fry, 2005-09-03 08:27

obviously the best fix would be a nice gui for setting things, but that's
plenty of work to implement. some discussion about the issue here:
http://processing.org/discourse/yabb_beta/YaBB.cgi?board=Suggestions;action=display;num=1114885272

Original issue: http://code.google.com/p/processing/issues/detail?id=44

[processing-bugs]

From b...@processing.org on June 07, 2010 00:25:29
Comment from adamj, 2009-12-05 14:07

I'm working on a Processing Tool and I'd like to use shortcut keys so I'm interested in getting this
bug resolved. I'm willing to take a stab at providing a patch, but it's not clear how to proceed. Any
further thoughts on how it should work?

I expect the settings will be stored in text files. A GUI can be built on top of this later.

There's a question of how the tool author vs the end user should get control over shortcut key
assignments. As a tool author, I'd like to define it myself with a text file in my tool folder. That
way I can document my tool as having a specific shortcut, but obviously this can lead to conflicts.

I think conflict resolution will be workable if we establish clear shortcut binding assignment rules
where the end-user settings have the final say. Probably the trickiest part will be handling multiple
Tools that attempt to use the same shortcut. A naive approach like "load all tool settings in lexical
order of tool name" (so the last tool alphabetically wins) would probably be ok until a lot of tools
are available, especially if the end user can set the shortcuts however they want.

[processing-bugs]

From b...@processing.org on June 07, 2010 00:25:30
Comment from fry, 2009-12-05 17:16

To do it properly, my current thinking is that it goes like this:

1. all the current menu options -- their titles, shortcuts, and meta-key
   accelerators (alt-blah on Linux and Windows) need to be moved into a
   prefs-type file that handles the menu config. There's another bug that's
   open that handles alt/meta key accelerators, so it'd be good to take care
   of that at the same time.

2. an interface for users to override what's in that file. In fact, it
   needn't necessary be an interface, since this is a power-user thing.

3. For tools, I think the simple solution is to just let tools grab their
   own keys. If they override another tool, it'll just be replaced (the first
   time that the tool is used). If that makes the user sad, they can go mess
   with the configuration UI.

4. If you wanted to be more clever about #3, you could prompt the user and
   ask them which tool gets to have a certain command. But that's overkill.

5. Tool requests for key commands will always be overridden by keys used by
   Processing itself.

But as you can see, it quickly gets very messy and complicated, and it's a
relatively minor issue. If we allow key commands for tools, chances are,
everyone will want their tool to use one. Which is silly, because most
tools won't be that important.

All that said, a simpler implementation would be that there's a single
configuration UI for tools that allows you to assign keys to tools that you
have installed. In fact, this is probably better: The interface could in
fact be a tool itself. It would have a list of the currently installed
tools, and next to each, their key command listed if one has been assigned.
Users could assign different commands as they wish (perhaps even re-order
the menu), from a selection of keys that Processing is not currently using.
(That would have to be determined by hand, at compile time, for now.)

[benfry]

Closing; this just seems like a bad idea all around. While useful, it's way too likely to cause trouble.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.