Brainstorming Improvements to Quick Drop Keyboard Shortcuts Framework in LabVIEW 2010

[Darren]

I shipped three Quick Drop Keyboard Shortcuts with LabVIEW 2009.  I have since posted three more shortcuts to the LabVIEW Community.  And there are more shortcuts I want to include in LabVIEW 2010.  Not to mention the shortcuts that have already been written by other members of the LabVIEW community.  All this to say that the current framework, where you add [char].vi to a certain location on disk, is starting to look like it's going to have scalability problems.  Here are the issues I've identified so far:

• When you want to use your own shortcuts in LabVIEW 2010 when it releases, you'll need to copy over your shortcuts from LabVIEW 2009.  And if you need to change a shortcut, you'll need to do it in two locations on disk.
• If I release a shortcut called a.vi, that might clobber one of your shortcuts if you've already written your own, completely different a.vi.
• It's very difficult to know what a.vi, b.vi, d.vi, etc. actually do...their filenames are not descriptive.
• You have to place your shortcuts in a rather esoteric location (resource\dialog\QuickDrop\plugins), which may not necessarily be a writeable location on all machines.

So I've got some ideas on how to re-do the framework in LabVIEW 2010, but I'd like to get some community involvement to make sure everybody agrees with my ideas.  I figured this thread would be a good place for us to discuss ideas.  Here's some initial thoughts:

• Create a shared location in [LabVIEW Data] as a secondary place to hold Quick Drop Keyboard Shortcut VIs (I'll continue to ship the core, "supported" shortcuts in the 'resource' location).  This will solve the writeable location issue, and will also allow the use of the same shortcut VI in multiple LabVIEW versions (kinda like how custom probes work).
• Have the shortcuts be named descriptive things, like "Remove and Rewire.vi" instead of "r.vi".
• Store mappings between shortcut VIs and keyboard characters in the LabVIEW.ini file, which will facilitate easy migration of mappings between LabVIEW versions (we already copy over our INI files anyway).
• Provide a simple UI in the Quick Drop "Shortcuts" configuration dialog that allows the mapping of keys to shortcut VIs.

I'd like some feedback as to whether or not these sound like good ideas.  Also, some help in figuring out these open issues will be nice:

• Is it that big a deal if I break backwards compatibility with existing LabVIEW 2009 QD keyboard shortcuts?  If breakage does occur, it should be pretty easy to fix.
• We need a way for a shortcut author to configure a "default" key for his shortcut.  Should it be part of the VI name?  Stored as a tag in the VI?  Stored as a value in a control on the shortcut VI's front panel?
• I think I should provide the facility for the 'Shift' modifier to launch a different VI, i.e. the user could potentially launch completely different shortcut VIs with Ctrl-G and Ctrl-Shift-G.  The current LV 2009 framework always launches the same VI in this case, just with a boolean passed in that indicates whether Shift was pressed.

Ok, this is probably a good start.  Please post any feedback you have on these bullet points (or any other issues you have with Quick Drop Keyboard Shortcuts in LabVIEW 2009 that you'd like to see addressed in LabVIEW 2010).

-D

P.S. - DISCLAIMER:  My LabVIEW plate is very full at the moment, so I make no promises as to what, if anything, I'll actually have time to implement in LabVIEW 2010.  But getting feedback on these ideas and having a concrete plan on what to do should increase our chances. 

[jgcode]

Thanks for getting this group started - this is great, I can't wait to read all the feedback.

Here is some of mine -

• Create a shared location in [LabVIEW Data] as a secondary place to hold Quick Drop Keyboard Shortcut VIs (I'll continue to ship the core, "supported" shortcuts in the 'resource' location).  This will solve the writeable location issue, and will also allow the use of the same shortcut VI in multiple LabVIEW versions (kinda like how custom probes work).

Please don't place them in [LabVIEW Data]!

It is very hard to manage when trying to create modular installs e.g. using OGPB or VIPM as OS Data Directory is not supported as a relative path.

And there is no LabVIEW version management!!

I made this request to the Idea Exchange along with this post with respect to the Icon Editor.

Is it possible from them to sit under [LabVIEW] somewhere?

• Have the shortcuts be named descriptive things, like "Remove and Rewire.vi" instead of "r.vi".

As previously discussed this would be preferred - less chance of a name clash, and much more readable

• Store mappings between shortcut VIs and keyboard characters in the LabVIEW.ini file, which will facilitate easy migration of mappings between LabVIEW versions (we already copy over our INI files anyway).

This sounds really nice.

• Provide a simple UI in the Quick Drop "Shortcuts" configuration dialog that allows the mapping of keys to shortcut VIs.

As does this.

• Is it that big a deal if I break backwards compatibility with existing LabVIEW 2009 QD keyboard shortcuts?  If breakage does occur, it should be pretty easy to fix.

If I can manage Versions using OGPB/VIPM packages then this should not be a problem.

• We need a way for a shortcut author to configure a "default" key for his shortcut.  Should it be part of the VI name?  Stored as a tag in the VI?  Stored as a value in a control on the shortcut VI's front panel?

I like what you have done so far with the QD template, a default on the BD set by the author should be ok, given that it can be changed if you go with a configurable UI - what happens if it already exists?

Would it make sense to be able have QDS's installed but not activate (like you do for RCF)

• I think I should provide the facility for the 'Shift' modifier to launch a different VI, i.e. the user could potentially launch completely different shortcut VIs with Ctrl-G and Ctrl-Shift-G.  The current LV 2009 framework always launches the same VI in this case, just with a boolean passed in that indicates whether Shift was pressed.

I do like the Shift option for the same VI in case there is a logical choice for deciding something between choice A and choice B and it should all sit in the same VI for easy maintenance.

But on the other hand it would increase the number of shortcuts available - but I am unsure whether I can remember then all

Maybe an option to reserve the Shift (I have written some QDPs that use this already as others may have)

Or be able to assign Ctrl + X and Ctrl + Shift + X to the same VI - that would be cool.

Just my 2c

[Darren]

Thanks for the feedback.  Regarding the [LabVIEW Data] location, I planning on that being a secondary location *in addition to* the currently plugins location (resource\dialog\QuickDrop\plugins).  So if you prefer to have your plugins stored in the resource location (so they're in an easy location relative to the base LabVIEW directory), you can still do that.  I'm just thinking we need a LabVIEW version-independent, and universally writeable location, to possibly store shortcuts as well.  That's why I was thinking [LabVIEW Data] would be a good secondary location.

I'm thinking a good solution for the default key combo would be to store a tag in the VI Description of the plugin VI.  Here are my reasons:

• Don't have to uglify the plugin VI name (like Remove and Rewire_r.vi would require if we stored the default shortcut in the filename)
• Can programmatically retrieve the VI Description without having to load the plugin VI into memory
• Easy to edit by the plugin developer (as opposed to something more obscure like storing a VI Tag)

The more I think about it, the more I'm thinking support for separate plugin VIs for the -Shift- modifier would be a hassle, for a use case that probably wouldn't be that common.  So unless anybody has very strong feelings on the matter, I think I'll keep the current framework, where the same plugin VI will run for both char and shift-char.

-D

[Daklu]

Yeah, what he said.  (I mostly agree with jgcode, so I'll just highlight the points I don't completely agree with.)

Please don't place them in [LabVIEW Data]!  It is very hard to manage when trying to create modular installs e.g. using OGPB or VIPM as OS Data Directory is not supported as a relative path.

I would rather have them in Labview Data than in the Program Files folder.  Disk backups get very complex when user data is spread all over the place.  The issue with the lack of OS Data Directory support in OGPB or VIPM needs to be addressed in those applications.

I do like the Shift option for the same VI in case there is a logical choice for deciding something between choice A and choice B and it should all sit in the same VI for easy maintenance.

As a user I want to configure the quick drop hotkeys in a way that makes sense to me.  I'll grant that containing shift and non-shift functionality in a single VI makes it easier for plug-in developers to create code, but I think it creates an inferior user experience.  Suppose you create a plug-in that does two related functions, A & B, so you make one of them (B) shift-enabled.  Now suppose I really like function B, but have no use for function A.  Not only do I have to remember to use the shift key to access that functionality but I can't use the non-shift hotkey for any other quick drop shortcut I like to use.  Furthermore, if the Alt key ever gets added as a modifier (please?) each plug-in would have to be rewritten again to take advantage of the added functionality.  IMO the user needs to be able to assign each QD shortcut function to a key combination of their choosing.

That does present a bit of difficulty in packaging a set of QD shortcuts that use common sub VIs.  Might be a prime spot for classes and the command design pattern.  Have the framework define an abstract plug-in class with two public methods:

1. GetNames returns a string array of the names of all the functions the plug-in supports.
2. Execute takes a string input and executes the specific function with that name.

(This is just off the top of my head so there are probably many reasons it won't work... but I believe the general idea is valid.)

------------------------

And a suggestion I strongly support...

Would it make sense to be able have QDS's installed but not activate (like you do for RCF)

I prefer this implementation over "always-on" shortcuts.  There are some functions I use only periodically, but when I use them I use them heavily.  For these kinds of functions I like to be able to temporarily set up a convenient hotkey and then remove the key combination when I've finished the task to 'disable' the functionality.

[Darren]

I can see valid use cases for both implementations of the Shift support.  If you've got a plugin that performs similar actions with the shift key (like the Ctrl-D/Ctrl-Shift-D plugin that ships with LabVIEW 2009), it makes sense to have them in the same VI.  But I could see wanting to configure, for example, Ctrl-W and Ctrl-Shift-W to be two completely different things, since they're both easily typable with the left hand.  How about this:

• Allow the user to, via the configuration UI, configure multiple shortcuts (Ctrl-W and Ctrl-Shift-W) to point to the same VI or to different VIs if he so chooses
  
• Still pass in the "Shift Pressed?" boolean into all plugins, so that even if the user only has Ctrl-W configured in the config UI, that same plugin will run when Ctrl-Shift-W is pressed, and it will know whether or not Shift was pressed
• Assume that if a plugin is not configured in the config UI (but has a default key assigned, as all plugins should), it will run for both Ctrl-W and Ctrl-Shift-W

Will the above design solve all the use cases?

As for Ctrl-Alt-[char] or Ctrl-Shift-Alt-[char], I don't see any reason why that couldn't be supported, other than simply not having time to implement it.

Finally, in regards to disabling plugins, I would think that the config UI would list all available plugins on disk.  You could then assign shortcuts to each one, or choose not to assign one at all.  If a plugin doesn't have a shortcut assigned in the config UI, it may still have a default shortcut, which I don't think we'd want to disable.  But if you're using plugin A's default shortcut for plugin B that is configured in the UI, though, you would effectively be disabling plugin A, since we would prioritize configured shortcuts over default shortcuts.  Would that solution be sufficient?

-D

[jgcode]

As you know, I have asked about OSDATADIR support in VIPM or OGPB

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 (I currently have 4 LabVIEW Versions installed on work PC). 

This is fine for me, but if others use the package it cpuld be a problem.

But if there is support for both folder locations, it is win-win for us Daklu!

Maybe a workaround.compromise to one of your issues is to still have char and shift-char assigned to a single VI but the user can swap what does what so if you favour shift-char you can swap it to char.

Quick drop would just update the VI description (from Darren's post) or something.

All in all I am very happy with the way this is shaping up.

[asbo]

The approach you've outlined here sounds like it really covers all the bases. For some reason, there's still a little bit of appeal to turning off a plugin entirely, but I can't give you a good reason for it.

With regard to developers defining default shortcuts, it would be nice to have something stand-offish to make it clear in context help or whatever. Maybe <b>Shortcut:</b> would suffice, and just have more than one <b>Shortcut:</b> line for plugins with more than one hotkey. It might be nice to be able to throw a description after each hotkey, though, so perhaps a standard delimiter ... Can you put tabs in VI descriptions?

The geek in me would like to see shortcut descriptions implemented as ^w and ^W for Ctrl+W and Ctrl+Shift+W, respectively, but something tells me that would be received as a little unreadable. 🙂

[jgcode]

Darren beat me to the post there, so I agree with that his design sounds good for char-shift

I love Asbo idea of seeing a description for each plugin and action(s) in the UI as well.

Enabling plugins is a good idea

I am thinking a default shortcut should become the prioritized shortcut automatically on install ONLY IF that shortcut (including the shift shortcut if it is included) is not already taken.

Otherwise it would have to be activated manually.

This would speed up an install and avoid any issues.

This is off the top of my head - when I say on install I guess I mean when LabVIEW starts up - could this process be dynamic like when the palettes get loaded?

It may be cool not to worry about configuration e.g. for newbies, but advance users could configure to their hearts content?

[Darin.K]

First, let me say that I love Quick Drop shortcuts.  Now let me blastpheme for a moment, I wish I could use them without, well, Quick Drop.  On one of my machines, the startup time is intolerable.  Once it is going, it rocks.  My first suggestion is certainly not new, if you have time to spend on QD, please work on speeding the startup process, or giving us an option to only use shortcuts.  My other thought is that it would be nice if us (the users) could have our own hotkey which we could link to our own VI.  If they are all booked, I suggest taking a hard look at Ctrl-t, who uses that?  The default VI (IMO) could be a simple key catcher that passes control to the given shortcut, just like QD without the startup.  We could even have our own folder, so our shortcuts don't have to intermingle with the growing number that will ship with LV.  For the adventurous types, the VI could be changed by the user (like the icon editor), so we can have at least one tool that feels tightly integrated into the IDE.

I really like the other ideas being mentioned, but not more than I'd like to put the Quick in Quick Drop.

[NJKirchner]

Darin,

   I'm going to play the role of the infiltrator at the moment by offering up exactly what you want... in a slightly different way.

At the heart of the QD shortcuts is the ever present problem that you highlighted....how can you execute these scripting VIs that make your life so easy.

Currently there are 3 major answers to this question

The Quick Drop Shortcuts

the JKI Right Click Framework

and the one that I have the most interest in

LabVIEW Speak - Programming LV through voice commands

The basic idea is the same, execute helper code when you need it.

It just happens to be that LVSpeak invokes those by voice, so you can get all that functionality that you're looking for w/ out requiring the long startup time.

Now that that's out of the way, let me assure you that I have stood upon a desk at NI and demanded that they find a smarter way to cache these palette items so that it doesn't take so long to load them.

The response that I've gotten is this.

In order to do anything with this, it is so deep down in the C code that it vastly outweighs the cries of those who would like this to be faster.

Now I did this before I set the 'load at startup' option

So I bit the bullet, I set the load at startup option and it's just become one of those things I don't even pay attention to because I have forgotten that's why LV is taking so long to load.

...I suggest you do the same.... the emotional callous just takes about 4 days to grow.