Quick Drop Enthusiasts

cancel
Showing results for 
Search instead for 
Did you mean: 

Running out of keyboard shortcuts

First, you're right - I don't use QD, but my own version, which doesn't have the keyboard shortcuts.

Second, the fact that you can create a shortcut which will show another UI doesn't really solve the problem, which is how to manage all the different shortcuts. Showing the plugins as part of the list does not preclude having the keyboard shortcuts for some or all of them - you go and configure somewhere shortcuts to invoke specific plugins, but the list will be the main access point - if there are plugins which you use often, then you would want to set up a shortcut for them.

And if you want not to have to repeatedly open QD, but have a hidden window instead, you can add an idea for that in the IE (although I think there already is one).


___________________
Try to take over the world!
0 Kudos
Message 11 of 34
(1,959 Views)

tst wrote:

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:

  1. 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.
  2. It doesn't give you a filtered list of options like the RCF does.
  3. It doesn't give you a list of options at all.
  4. 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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.

Sorry for the late response, I've been away.

I think your points have merit. I like the side-bar - it makes Quick Drop accessible to those picking it up for the first time (and unaware of their keyboard shortcuts).

I think we need to keep in mind that Quick Drop is meant to be "Quick". My favourite aspect of QD is that I can cause a plugin to fire without even looking at what I'm doing by pressing a pair of keyboard shortcuts quickly. If we make shortcuts the 'secondary' access mechanism, and introduce a new primary access point, then it needs to be at least as quick as a keyboard shortcut. Although through the sidebar we can peruse all available plugins to learn about them, once we know of them we only need a way to quickly launch them.

Having 'selection criteria' VIs that each plugin must provide to allow QD to determine the suitablility of a plugin is neat, but I can't see that working well without long lag. has anyone considered implementing a set of predefined criteria to which the plugins register themselves? But what criteria I wonder would provide flexibility and also sufficient specificity?

Thoric (CLA, CLED, CTD and LabVIEW Champion)


0 Kudos
Message 12 of 34
(1,959 Views)

Thoric wrote:

If we make shortcuts the 'secondary' access mechanism, and introduce a new primary access point, then it needs to be at least as quick as a keyboard shortcut.

No, it doesn't - you have the shortcuts for speed and the list for ease of use. The reason I referred to the shortcuts as a secondary mechanism is that I see them as optional - you define shortcuts only for those plugins which you access often enough to warrant the shortcut, just like you define text shortcuts only for some of the items in QD. Remember the title of this thread.

Thoric wrote:

Having 'selection criteria' VIs that each plugin must provide to allow QD to determine the suitablility of a plugin is neat, but I can't see that working well without long lag.

Like I said, there's no reason in principle why these VIs couldn't run asynchronously in the BG and simply add items to the list as each one completes. It would take time until you get all the options, but the UI would be responsive. Of course, like I said, the way QD works makes this less needed than it was with the RCF and if you want it to react quickly, then this feature would be bad.


___________________
Try to take over the world!
0 Kudos
Message 13 of 34
(1,959 Views)

tst wrote:

Thoric wrote:

If we make shortcuts the 'secondary' access mechanism, and introduce a new primary access point, then it needs to be at least as quick as a keyboard shortcut.

No, it doesn't - you have the shortcuts for speed and the list for ease of use. The reason I referred to the shortcuts as a secondary mechanism is that I see them as optional - you define shortcuts only for those plugins which you access often enough to warrant the shortcut, just like you define text shortcuts only for some of the items in QD. Remember the title of this thread.

If a user is to define a shortcut for the plugins they wish to access regularly, then what do they do when they run out of shortcuts? It is feasible that a developer will still regularly use more plugins than there are shortcuts, and we're then back to the same issue I raised in this thread - Running out of keyboard shortcuts. If you are suggesting a developer doesn't need that many shortcuts, then this whole argument is null.

tst wrote:

Thoric wrote:

Having 'selection criteria' VIs that each plugin must provide to allow QD to determine the suitablility of a plugin is neat, but I can't see that working well without long lag.

Like I said, there's no reason in principle why these VIs couldn't run asynchronously in the BG and simply add items to the list as each one completes. It would take time until you get all the options, but the UI would be responsive. Of course, like I said, the way QD works makes this less needed than it was with the RCF and if you want it to react quickly, then this feature would be bad.

Yes, I understand that, and clearly that's one possible method to launch dozens of criteria-checking VIs, but what is important is speed. The UI can remain responsive, but if a plugin hasn't reported back that it's valid/invalid (and the developer themself knows that it will be), they could be required to wait for the VI to finish before they can launch the plugin. I can envisage such VIs taking more than a few 100ms to complete, in which case a developer will have already pressed their preferred shortcut combination and be left waiting. Currently QD doesn't cause such delays, and making the process slower isn't favourable. In the end, though, we'll never know until a framework is designed and tested. I'll remain reserved but quietly optimistic that such an approach can be adequately implemented.

Thoric (CLA, CLED, CTD and LabVIEW Champion)


0 Kudos
Message 14 of 34
(1,959 Views)

Atleast for your own shortcuts it's possible to cluster them to a single key combination to reduce the total count of primary key combinations.

You open your shortcut by a single key combination. When your shortcut code is running, then you can use another key to trigger the actual implementation you want to execute.

You can help to choose the implementation by showing a little GUI. (like here: https://decibel.ni.com/content/docs/DOC-14469)

0 Kudos
Message 15 of 34
(1,959 Views)

Thoric wrote:

If a user is to define a shortcut for the plugins they wish to access regularly, then what do they do when they run out of shortcuts?

Get another keyboard. Duh.

Seriously, though, what do you do if you want LV to to use Ctrl+N to nuke the current VI? You go to the LV options dialog and you configure Ctrl+N to call the nuke menu item instead of the new VI menu item. Then, if you want to open a new VI, you go through the menu.

This idea solves the issue of running out of shortcuts by saying "OK, we'll use a list instead of the shortcuts. Oh, you like the quick access? OK, I'll let you configure shortcuts for whichever plugins you want".

Thoric wrote:

I can envisage such VIs taking more than a few 100ms to complete...

You don't have to. I can tell you from experience with the RCF that with a couple of dozen plugins installed, opening the menu (which meant running the analysis VIs for all the plugins) would take around 1-3 seconds. It's possible that the QD version would be more efficient (especially if the VIs can run in parallel), but I don't think this feature is critical, so I'm thinking of leaving it out of the idea.


___________________
Try to take over the world!
0 Kudos
Message 16 of 34
(1,959 Views)

Perhaps this is a silly Friday afternoon question, but I use keyboard shortcuts for the custom plugins, and I use contracted string shortcuts for the built in functions. Such as CTRL+W for my Symbols Wizard plugin and "cs" for "case structure".

As we're running out of keyboard shortcuts, why don't we make configurable contracted string shortcuts associate with plugins?

I can type "wiz" just as fast as I can press CTRL+W, or at least quick enough to make the difference irrelevant to me. I would welcome this as an addition to Quick Drop as I'm more likely to be able to support multiple plugins that might intuitively use the same keyboard mapping shortcut.

Thoric (CLA, CLED, CTD and LabVIEW Champion)


0 Kudos
Message 17 of 34
(1,959 Views)

OK, so it did take six months, but I finally got the inspiration today to clean this up properly and I'm planning on posting it on the IE in a couple of days. If anyone has comments on what I should add/change/remove, now would be the time:

tl;dr  There's a summary at the bottom if this is too long for you.

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. These allow you to perform custom actions in LV and 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 is not discoverable, it requires you to remember key combos and it doesn't work if you want a longer list of macros which perform all kinds of useful operations, because you run out of available shortcuts.
  • Setting options on the plugins is done by pressing the Shift key or other similar magic combos instead of having a clear representation in the user interface.


So, what can we do about it?

I think a good first step would be to stop thinking of these as "keyboard shortcuts". They should be thought of as custom actions or macros and they should simply appear in the list
along with the regular items, like so:

http://forums.ni.com/t5/image/serverpage/image-id/125199i05F2BCEED6741EE1/image-size/original?v=mpbl-1&px=-1


There are a few things to point out in this image:

  • The actions appear in the list using their full names and they have a glyph to make them visible.
  • The actions may (or may not) have a shortcut.
  • The actions may (or may not) have a keyboard shortcut (and there's no reason in principle why regular items can't have them too). This solves a problem we currently have where there's a limited amount of shortcuts available.
  • There's a ring on the bottom which shows just the items, just the actions, or both. Ideally, the value of this ring would also be settable by other means (e.g. open QD using Ctrl+Shift+Space and the list only shows the actions or open QD when you have a selection and the list only shows the actions).

OK, so that's step one. Now step two - some of you may have noticed that the image has another new thing - there's an expand button on the right side.
Clicking that button will open this panel:

http://forums.ni.com/t5/image/serverpage/image-id/125201i18FA8083D67AE4CB/image-size/original?v=mpbl-1&px=-1


This shows the details of the currently selected action and allows selecting options for it.

Of course, once we have this panel, the next logical step is to also have it show the help for standard items:

http://forums.ni.com/t5/image/serverpage/image-id/125203iDFC4CF29B68E2AC7/image-size/original?v=mpbl-1&px=-1


The panel should remember its last open setting between calls and when it's open, it should work asynchronously, so that it doesn't delay the operation of QD.
For the VIs which appear in the panel, there should be a standard template for loading and saving values, for showing titles and help data and for shutting down. If the VI fails to respond to the shutdown command within N ms, Quick Drop should proceed and not wait for it.


So, to sum up:

  1. Custom actions should be in the list of Quick Drop items.
  2. Shortcuts for actions and items should be fully customizable.
  3. There should be a panel which allows customizing options for actions and show the help for regular items.

Again, any comments are welcome.


___________________
Try to take over the world!
Message 18 of 34
(1,959 Views)

I didn't see an Idea Exchange link have you made one yet or just looking for feedback?

I never really thought about it but I think needing a shortcut for an action can be quite limiting, and your solution would remove the need for binding a key combo to an action (like Restart LabVIEW).  Of course we can still have key combos if we need.

I think a good comparison is what if each item in the menu bar needed a key combo?  There are somethings that are obvious like Open (CTRL+O), Save (CTRL+S), Copy Paste Cut (CTRL+C,V,X), but what if each item under File, Edit, View, Project, Operate, Tools, Window, and Help all needed keyboard shortcuts?  We would quickly run out, and no one would be able to keep track of what does what, especially when new items are added.  This kinda feels like the issue we are having with quick drop.  In LabVIEW 1.0 each menu item probably could have had a shortcut but now that method of calling a function isn't feasible.

0 Kudos
Message 19 of 34
(1,959 Views)

Hooovahh wrote:

I didn't see an Idea Exchange link have you made one yet or just looking for feedback?

Not yet. I plan on posting that text (with some edits if I feel inspired) and want feedback before I do, because it's relatively long and complicated. Any kind of feedback is good (such as additional points), but feedback which has to do with the actual language is ideal (particularly if it makes it easier to read).

I think a good comparison is what if each item in the menu bar needed a key combo?

Exactly. I also made the same comparison earlier in the thread - the menu item is the primary access mechanism and you configure shortcuts as a secondary access mechanism for some of the menu items.


___________________
Try to take over the world!
0 Kudos
Message 20 of 34
(1,959 Views)