Description

processing-bugs

opened on Feb 10, 2013

Issue body actions

Original author: [email protected] (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

Activity

1. processing-bugs commented on Feb 10, 2013

   

   processing-bugs

   on Feb 10, 2013

   Author

   More actions

   From [email protected] 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.
2. processing-bugs commented on Feb 10, 2013

   

   processing-bugs

   on Feb 10, 2013

   Author

   More actions

   From [email protected] 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.)
3. benfry commented on Nov 19, 2014

   

   benfry

   on Nov 19, 2014

   Contributor

   More actions

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

   closed this as completedon Nov 19, 2014
5. benfry

   added

   wontfix

   on Nov 19, 2014
6. github-actions commented on Jun 16, 2021

   

   github-actionsBot

   on Jun 16, 2021

   More 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.
7. github-actions

   locked as resolved and limited conversation to collaborators on Jun 16, 2021

Issue actions