Today I realised I now have two plugins that use the same shortcut, forcing me to change one to a less than obvious letter, which raises a question regarding future expansion: how do we support more plugins than shortcut combinations?
We're quickly approaching a scenario of having more QD plugins than there are sensible keyboard shortcuts, and assuming the Shifted combinations are reserved for the same plugins to achieve alternative behaviour then we have about 36 shortcuts. If you include the punctuation keys then you get maybe half a dozen more, but you can argue that these are not so intuitive to remember.
So, given I've already had to change one of my plugin shortcuts to accommodate Darren's default (autoWire CTRL+W), what's on the drawing board to allow us to host the plethora of plugins we will no doubt have in just a couple of years time?
...what's on the drawing board to allow us to host the plethora of plugins we will no doubt have in just a couple of years time?
To be honest, I have not given this topic much thought. Probably because I currently only use about 10 total shortcuts in my daily work, so I'm not even half-way run out yet. But I think this thread is a good place for us to brainstorm ideas on how to proceed with the possibility of running out of keys. One thing I've thought of before is to create a meta-shortcut (Ctrl-M?) that takes what was typed in the Quick Drop text box and uses it to execute one of an arbitrary number of commands. More keystrokes, but no limitation on the number of commands.
I don't use QDKS and one reason is that I never liked their lack of intuitiveness and discoverability. That's the same problem I had with LV Speak when it first came out and Norm's decision to show a list of possible commands in later versions certainly seems to help, so I would suggest doing something similar - add the actions to the list and give them full names (and maybe a glyph).
One mechanism would be to simply give them preference in the sort. Another would be to only display them when a hot key is pressed (so if you press Shift+"re" you will see the remove and rewire action and you probably won't see the normal results). That would hurt some of their accessibility, but you could probably still keep the current mechanism as an additional access point, so that people who want to access certain actions a lot would configure shortcuts for them.
Darren: I can foresee that we might need a revised interface to present the features of QD. Currently we have a search field and a results listbox. If we are to envisage a large selection of plugins (actions that can be performed as opposed to functions that can be dropped), then perhaps these ought to be given similar treatment to the functions results when searching. The search box would therefore also search avialable plugins/actions, perhaps based on embedded keywords and tags, and include them in the results listbox. How you would arrange these in the results listbox can be debated, but I see value in the ability to search for the plugins just as much as functions/VIs in the way that it currently does.
For example, I know there's a useful plugin for creating controls and indicators for all terminals of a selected subVI. If I can't remember the non-intuitive shortcut I'd like to be able to type something akin to the action in the search field and see the plugin appear in the results listbox.
This approach will cope with any number of plugins/actions that people may create, without the need for unique keyboard shortcuts for them all. Of course, you would still be able to assign shortcuts to your favourites.
tst: Showing a list of possible commands certainly would help, much like my suggestion above. I wrote the above before reading your reply, and see now that you've suggested pretty much the same thing!
By the way, what might be even nicer is if plugins had an optional popup panel which would let the user configure the needed parts of the plugin (maybe if you press Shift+Enter to open the panel or something similar). I'm actually assuming that this is already possible today, since the plugins are simply VIs and writing a popup should therefore be simple enough, but it would be nice if this was standardized (for instance, if plugins with popups had a different glyph in the list or if selecting a plugin a list would display a short help feature in a side panel* or if there was a standard way to save control values for each plugin so that it would remember its settings, maybe by using something like this. Maybe some of those settings should even be displayed in the list?).
* Actually, that might not be a bad idea in general - you add a side panel to QD which would display the description text of the currently chosen VI (and maybe the context help image?) or some help text with the current settings for a plugin. I think the implementation could be fairly straightforward if you use a class structure (i.e. each plugin is a class which has an override method or sets a property on the parent to provide the relevant text and regular results are treated as a separate class). It would probably require a tool which converts existing plugins to the class structure, but that should be easy enough. Maybe for 2014? Should I add it as a proper idea in the idea exchange? I'm not sure how many votes it would actually get.
Or that panel could actually be a subpanel which will hold the config and thus not require the popup VI, but I assume that might be more complicated because it would require users to properly handle the exit command that QD will send to the VI.
And what might be even cooler was if QD plugins worked similarly to how the JKI RCF behaves - there, each plugin actually had two separate steps. It first checked the selection list to decide if it's even applicable and only if it decided it was it would add itself to the list. That meant that when you right clicked a selection, the menu only displayed plugins which would actually do something. That made the selection really simple. Maybe something similar could be done with QD, where if you hold a hotkey after opening QD (Ctrl?) then QD automatically only shows applicable plugins in the list.
The main problem I see with this is performance. This scheme requires each plugin to run its testing VI when the hotkey is pressed. The more plugins you have, the longer this step will take and the longer it would take before you can see the results in the list. It also complicates plugin creation because it requires you to add extra code for the command building step. The main advantage is that it increases ease of use of the plugins considerably, because you only see relevant plugins. Maybe this is something won't be as critical in QD because in QD you can type to filter the list, whereas in the RCF you couldn't, but it's still something worth considering. It might be deemed to be too much of a headache both in ease of implementation and ease of creation for plugin developers.
QuickDrop is fast becoming an absolute must use tool for anyone serious about improving their block diagram creation efficacy. I can't live without it, so I would strongly agree that efforts to improve it's useability be favoured over any increase in upfront effort required to make it more feature-rich. If it requires plugins to follow a strict API with pre-call functionality then yes that makes for more work, but we're all proficient developers and can appreciate the reasons why. Quick Drop is great, but it could be awesome. Expanding it's abilities and taking it further is inevitable, if that requires a redesign of the framework then so be it.
There are still many developers unaware of QuickDrop and when I show it off at our User Group to new attendees they're amazed. Then when they learn they can create plugins they're astounded. Perhaps creating an enahnced API for custom plugin developments ought to be considered asap before the current QuickDrop becomes too "set in its ways"? I don't mean that to sound fractious, I just think Quick Drop can be so much more and I don't want Darren to miss the boat.
A thought I just had was to keep Ctrl+Space as the shortcut for the functions and controls, but then maybe use Ctrl+Shift+Space for the list of plugins. Then you could redesign the plugin stuff without having to worry about how it ties in with the quick-dropping of functions and controls. Then, if you set it up similar to the way the main quick-drop screen currently is, we could assign whatever keystrokes we want for a given plugin. Of course, for the plugins that use the input text you would have to have some way of handling that, like use everything after some delimiter as the "data" for the plugin, or tab to another "data" control.
I like the idea of showing the glyph of the main VI of the plugin as well.
As for the determination of which plugins to show, in order to keep the development of plugins simple, I wonder if it would be plausible to have the plugin template include a simplified list, maybe in the documentation of "when this plugin should be included in the list." Simplified as in: "When nothing is selected", "When wires are selected", "When controls are selected", "When indicators are selected", "When hovering over an input terminal", "When hovering over an output terminal" etc. By default, there could be the full list of all of them and then if the plugin shouldn't show up in that list they can just delete the appropriate ones. Ok, so that may not be the best way, just brainstorming (:
I also think it would be nice to have "QuickDrop (Ctrl+Space)" as the top menu item in the Functions and Controls menus. It looks like it is in the "View" menu, which I hadn't noticed before, but if it is somewhere where everyone sees it all of the time, I imagine it would be picked up faster. I finally had to deselect everything in the "Change Visible Palettes" to remind/force myself to use quick drop several months ago when I was first starting to use it. This would help even the newly initiated to LabVIEW users to start using it right away.
Following this discussion, I quickly typed up the following for the idea exchange, but since I don't have any real experience with QDKS, I would appreciate it if people went over it and added their comments before I post it. Note that this is the first draft and I haven't polished it at all yet, so you're also welcome to suggest structural changes if you like. Also, it's possible that suggestion #2 should actually be a separate IE entry:
Supercharge Quick Drop
OK, so Quick Drop is pretty useful when it comes to dropping things and the fact that it also gets items from the project is great.
What I don't like about QD, however, is the keyboard shortcuts. The concept itself is great, but the implementation QD uses lacks some important features which other similar tools like the right-click framework and LabVIEW Speak have, such as:
- It requires you to remember keyboard combos to call the plugins. That's great as a secondary access mechanism, but is terrible as a main one.
- It doesn't give you a filtered list of options like the RCF does.
- It doesn't give you a list of options at all.
- Setting options on the plugins is done by pressing the Shift key or other similar magic combos instead of having clear UI representation.
I think that this situation can be considerably improved by implementing some or all of the following options:
- Show the plugins in the list, just like the items to drop. They could either be part of the list and be marked with a bullet or they could be displayed when you hold the Ctrl button down.
- Add a side panel to QD which will show configuration options for the currently selected plugin. This panel could also be used to show the icon and context help/description for non-plugins.
- Filter the list of plugins based on the selection. This would require each plugin to have another VI which will be called initially and analyze the selection to decide if it should be displayed. This is what the RCF does, but I'm actually not so happy about this one for two reasons:
- In the RCF this causes a lag in displaying the menu because it has to run the VI from every single plugin. The more plugins you have the worse it gets. This could probably be handled in QD by running these VIs asynchronously and updating the list as the results come in, but I don't think it's actually needed because:
- Unlike the RCF, QD has another filtering mechanism – the search. Even if the initial list of options is long, it's very easy to make it short, unlike the RCF where the menu displays everything that you put into it.
- An alternative to 2 would be for each plugin to display a popup if it wants additional configuration, but I think it would be nice if this was part of a standard framework.
Here's a short video showing what options 1 and 2 could look like. You'll note that the plugins have a bullet - http://www.screencast.com/t/ar3BYvkV . Of course, in this video I don't actually show the help or the settings for the plugins, but it's just supposed to be a rough mockup.
I like my QD window small and fast. I'm only looking at it when searching project VIs or other not frequently used items.
I'd even prefer it, if i'd not have to open QD to fire QD-Ctrl-Key-Shortcuts.
If you want a single UI for QD Shortcut access you could write a single Shortcut opening a UI serving as function filter and selector.
In general it seems to me that you are more thinking about the QD than actually using it in the current form.
It is pretty adaptable to your personal needs.
To advertise the Quickdrop feature i'd recommend to create and publish some QD programming footage.
(With overlay of used shortcuts and slow motion parts where needed)
Showing some badass programming skillz of World's Fastest LabVIEW Programmer!
That's viral marketing. People like viral marketing these days.