Quick Drop Enthusiasts

cancel
Showing results for 
Search instead for 
Did you mean: 

Running out of keyboard shortcuts

tst wrote:


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 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.

I would use QDA (Action) if this were implemented.  Well, I do use QDKS for scalar-to-array / array-to-scalar and remove-and-rewire.  When I read the 2 bullets above, I didn't follow you at first (in part because I was reading on my iPhone and couldn't see the images).  Maybe something like this instead:

-The actions appear in the list using their full names and have a glyph to differentiate an action from a node.

-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).  Providing primary access to actions apart from keyboard shortcuts not only relieves the developer from memorizing nebulous keystrokes but removes the burden of continuously ranking new actions and assigning them to a limited number of shortcuts.


Certified LabVIEW Architect
TestScript: Free Python/LabVIEW Connector

One global to rule them all,
One double-click to find them,
One interface to bring them all
and in the panel bind them.
0 Kudos
Message 21 of 34
(2,730 Views)

Differentiate > Visible, although I'll probably try to think of a better way of saying it (maybe "a glyph to set them apart from the items").

I thought the second part was too long when I wrote it and it's even longer after your suggestion. It's actully redundant because at some point I added the problem description at an earlier point in the text, so I should probably just point to that and edit the section describing the problems with QD so that it explains this better.


___________________
Try to take over the world!
0 Kudos
Message 22 of 34
(2,730 Views)

I agree.  The sentence that I added to the second bullet summarizes why your idea takes QD to the next (RCF) level.  Ironically, in the IE just naming this "Add Context Help to Quick Drop Window" might garner more immediate community support than something about QDA.


Certified LabVIEW Architect
TestScript: Free Python/LabVIEW Connector

One global to rule them all,
One double-click to find them,
One interface to bring them all
and in the panel bind them.
0 Kudos
Message 23 of 34
(2,730 Views)

I posted the idea here - http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Supercharge-Quick-Drop-Turn-QD-keyboard-shortcuts-into...


___________________
Try to take over the world!
0 Kudos
Message 24 of 34
(2,730 Views)

What about something like this?

http://screencast.com/t/ICFiWKuZHp3

Ctl+M is because we are executing the idea of 'Macros'

Also, because the engine can be called from anything, you can create your own tool to invoke such commands, and not have it specifically linked to the QuickDrop interface.

0 Kudos
Message 25 of 34
(2,730 Views)

NJKirchner wrote:

What about something like this?

http://screencast.com/t/ICFiWKuZHp3

Ctl+M is because we are executing the idea of 'Macros'

Also, because the engine can be called from anything, you can create your own tool to invoke such commands, and not have it specifically linked to the QuickDrop interface.

Why should we even use quick drop when we should just yell at LabVIEW.  Right, Norm?  That interface looked very suspiciously like your LabVIEW Speak.  I need to play with that again...


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 26 of 34
(2,730 Views)

What I was looking for with this idea is to try to finally promote one of these plugin-executing frameworks to a more mainstream position. I think that the concept of custom actions is as good today as it was when the RCF came out a few years back and I really want to see it gain more widespread adoption.

For that it absolutely needs two things:

  1. To ship with LV.
  2. To be easy to access and use.

The first part is accomplished by having NI roll it up into QD and the second by having the actions in the QD list and having the panel.

I absolutely agree that it would be great if there were additional mechanisms for accessing this. We talked about merging the RCF, QDKS and LV speak into a common API years ago and I think now it's more realistic as the RCF is effectively dead and can be ignored and this new mechanism can be compatible with LVS/QE as you just demonstrated.

I agree that that it would be great if the floating panel of actions would ship with LV.

I agree that it would be great if someone would install LVS (or it would ship with LV) and it would automatically share the same list of actions.

But, I think those should come as additions or alternatives to what's suggested in the idea, not instead of it.


___________________
Try to take over the world!
0 Kudos
Message 27 of 34
(2,730 Views)

I have actually fully decoupled QuickEdit from LVS which allows you to use the full suite of commands from any interface you like, including from a QDKS.

Ping me directly if you'd like it.

It's pretty much ready to post online, but I need to get some beta users first.

~N

0 Kudos
Message 28 of 34
(2,730 Views)

tst,

I think this is an excellent idea and not dissimilar to the concept used in emacs where M-x (alt-x) initiates an "execute-extended-command". I would suggest a slight modification to your idea:

Rather than the commands (or macros as you describe them) being in the same list as all the VIs they should be in a separate list which is activated (like emacs) with a key combination e.g., ctrl-space-c (c for commands for example, but should be user configurable) -- that is press control and space, then "c", without releasing ctrl. The reason for having the commands (macros) in a separate list is so that the auto-complete/matching is faster. It also allows for shortcuts which may overlap with those for the functions list (normal quickdrop).

I like the expandable help/config panel (maybe it should be toggled with the tab key) but I think that only defaults should be set here, all options should be available via keyboard shortcuts -- keep the mouse out of my quick drop 🙂 !

I would suggest a workflow as follows:

1. ctrl-space-c (activates command selection which populates from the plugins folder),

2. bash the keyboard untill I can see the command I want,

3. press tab (as I've forgotten the options and exactly what the command does) to expand the help/configuration panel for the command,

4. press enter to begin the command,

If the command has no options it will now complete, if not the quickdrop list will now populate with the command options:

5. bash the keyboard some more untill the particular option I want is selected,

6. press enter to complete the command with the options I selected.

This is similar to the emacs workflow which is a very well tried and tested editing environment.

Regards,

Steve.

0 Kudos
Message 29 of 34
(2,730 Views)

Like I said below, my main goal with the idea has been not only to make the actions more usable (e.g. you don't have to remember the shortcuts), but also to get them to become more mainstream. While your suggestion (which can be done today and which Norm demo'ed below) covers the first part, it doesn't cover the second.

The same applies to keyboard access for setting the options - while it would be nice, I think it should be secondary. I expect that most actions either won't have options at all or would work with the same settings that the user previously used, so for most of them you would just invoke the plugin (using the full name, the shortcut or the keyboard shortcut).

If the plugin you want does have options which you want to change from the previous/default value or it's a plugin that you don't know as well, then I think it's all right if you stop for a few seconds and read or use the mouse to configure the options. Remember that the plugin is supposed to automate some action and save you some time, but this is a plugin that you don't use often enough to assign a keyboard shortcut to - nothing terrible will happen if you have to use the mouse.

I can give you anectodal evidence from my own experience with the code capture tool for how this is relevant - about eight years ago someone posted a useful utility to the forums, which would allow you to drag a VI into it and run it and it would create an image from the BD of the VI, which was useful for sharing the code online. This may not sound like much today, but back then scripting was a lot less well known, so it was more impressive. It became even more impressive when it was modified so you could simply launch it from the tools menu and it would work on the VI it was called from. Then, people started adding all kinds of magic buttons. If you pressed shift, it would grab the FP. If you pressed control, it would grab both. If you closed one eye and cocked your head to the left, it would do something else. Eventually, I had enough and created a GUI for it with proper options, but I added keyboard shortcuts for controlling those options. What I found was that nobody actually cared when I removed those shortcuts later, because you didn't need to change those options often enough. When you did, using the mouse was just fine.


___________________
Try to take over the world!
0 Kudos
Message 30 of 34
(2,730 Views)