Brainstorming Improvements to Quick Drop Keyboard Shortcuts Framework in LabVIEW 2010

[Darin.K]

Norm!   I am still a little queasy talking on the phone to a machine, so I am not sure I am quite ready to start talking to my computer.  That is pretty darn cool though.  And since two of my favorite things to play with in LV are 2D Pictures and Scripting, I take your suggestions seriously.

You did leave out my most-used solution, adding VIs to the Tools menu.  No assigning shortcuts though. 

Someday I will be running the latest version of LV on all brand-new machines so I can start QD once and run for days.  Until then, I find myself launching LV a few times per day, and the wait adds up.  I can choose one option and be mad at LV in general, or another and just be mad at QD.  Either way I am mad.  And yes, I will get over it eventually.  I complain because I care, thanks for trying (maybe just stand up one last time).

[Daklu]

"Will the above design solve all the use cases?"

Technically, it may allow the user to do things needed.  From a user perspective I don't think it will allow me to do it easily.  Assuming you're visualizing the typical hot key configuration dialog box with the function listed on the left and the key combination on the right, I can see various issues.

1. If a single VI contains multiple functions, there's no good way for the configuration VI to discover what those alternate functions are.  In other words, each plugin, which can support multiple functions, is only listed once.
2. Due to #1, the functions supported by a plugin are not easily discoverable.  It's up to the user to find documentation (assuming the author has provided some) or dig into the source code to find those functions.
3. Due to #1, the user interface for assigning a key combo to a plugin's shift function is going to be clunky at best.  Since the actual shift key is used to define the hotkey, setting the config vi to use the plugin's shift function will require some sort of "Send Modifier Key" enum.  (Starting off with "No Modifiers" and "Shift" followed (hopefully) by "Alt" and "Shift+Alt" in the future.)
4. Due to #1, setting custom key combinations to a plugin's Ctrl function and Ctrl-Shft function is going to be worse than #3.  You'll either need to list the plugin multiple times (with the same name) or add additional columns to the config table for the alternate functions, neither of which follows the norm for hotkey configuration dialogs.
5. Due to #1, there's an upper limit (currently 2, increasable to 4 max) to the number of related functions that can be packaged in a single plugin.

I think you did an awesome job providing us with this functionality in 2009.  I love it and use it all the time.  However, I believe the single vi/multiple function architecture is too limiting and needs to be changed before it is too late.  Personally I would rather wait an extra year for configurable hotkeys than see it head down a path that leads to a deadend.

(Any chance of giving us a callback for either the VI that returns the plugin name or the VI that returns the plugin reference?  It would be interesting to play around with it.)

[Daklu]

"But I am thinking even if I did have it I would still not have LabVIEW version control and I would still have an issue with packages.

This means that if I create a package that installs here I am going to run into issues if I accidentally install it or uninstall it over two or more versions."

This is always a bit of a problem.  You could have <osdatadir>\National Instruments\QD Plugins\<Labview Version>, but then if you want the plugin available across multiple versions you have to install it in multiple places.

Q: Is your concern when you create a plugin with a version that is newer than the one you may be working in, or is it because you have different functionality depending on the Labview version?

I can think of relatively easy solutions if the plugins were classes.  Add a "Valid Versions" or "Min Version" method to the plugin class and have the config dialog box only show those plugins applicable to the Labview version currently running.  With the current setup... I dunno.

[Darren]

Thanks for the feedback, everybody.  Here is what I'm *planning* on doing in the 2010 timeframe.  It's a subset of what we've discussed here (along with a new idea or two), and it is what I think I can get done in 2010, although there's still no guarantee I'll actually have time to get it all in:

• Add a location to [LabVIEW Data] that Quick Drop will check for plugins.  This will be in addition to the current resource\dialog\quickdrop\plugins location.
• Allow plugin VIs to have descriptive names, and have the default keyboard shortcut for them specified in the VI Description.
• Allow keyboard shortcuts for plugins to be configured in the "Shortcuts..." dialog in Quick Drop.  Also have a text field in that dialog that describes each shortcut in the list.
• Only allow one keyboard shortcut to be assigned per plugin.
• Ctrl-[char] and Ctrl-Shift-[char] will run the same plugin VI.  -Alt- will not be supported (looks like the Key Down event will not fire for the ASCII [char] if you press Ctrl-Alt-[char]...not sure why).
  
• Store shortcut mappings in the LabVIEW INI file.
• Add a new folder in vi.lib\VIServer that contains "shared" plugin components.  My thinking here is that, if we have a subVI that wraps functionality for a plugin, and we place it in there, then other editor-enhancing frameworks (like LVSpeak or JKI RCF) could use those shared components in their own plugins without having to rewrite the same exact scripting code.

A lot of the more advanced framework ideas in this thread are great, but realistically, there's no way I'd have time to implement them without getting actual project time approved, which isn't going to happen in the 2010 timeframe.  Also, there are other enhancements to Quick Drop, not related to QDKS, that I'm trying to get in as well. 

-D