11-11-2013 09:21 AM
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.
11-11-2013 10:33 AM
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.
11-11-2013 10:58 AM
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.
11-13-2013 02:44 AM
I posted the idea here - http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Supercharge-Quick-Drop-Turn-QD-keyboard-shortcuts-into...
11-13-2013 10:38 AM
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.
11-13-2013 10:47 AM
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...
11-13-2013 11:00 AM
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:
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.
11-13-2013 11:12 AM
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
11-18-2013 03:56 PM
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.
11-19-2013 09:53 AM
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.