Welcome to the VIPM Idea Exchange. Here's your chance to collaborate with JKI engineers and other users to influence the future of VI Package Manager. How can VIPM make your life easier or help you work smarter? Tell us!
To submit an idea:
- Type your idea in the box below. The Idea Exchange will show you similar ideas as you're typing.
- If someone else has already submitted a similar idea, vote that idea up and add a comment to the discussion.
- If they haven't, submit your idea as a new suggestion by clicking Next. Then provide a detailed description in the submission form. Add links, images, and video to make your suggestion clear and compelling!
To vote for an existing idea:
- Click the Vote balloon next to any idea to show your support. Better yet, also add a comment to the discussion.
- You will be prompted to create a new account if you don't have one, or login, if you do.
If you need technical support for VIPM or any of JKI's other products, click here.
I tried to create a VIP that contained the famfamfam.com Silk icon set as a glyph set for the NI Icon editor.
The Icon editor stores the PNG files in the '%Default data directory%\Glyphs' path. Unfortunately the %Default Data Directory% isn't available as a target in VIPM.
I would like the ability to categorize VI packages that are built. If my company has 3 basic categories for a toolkit (1. use at own risk 2. Semi-tested 3. Certified). Then this category can be displayed when a user installs a package.
Furthermore, once this information is gathered, you can then possibly search and install only Rock solid packages, for example
I think it would be really cool if a dynamic palettes (I will call it that after the OpenG package name, but there maybe a better descriptor for it?) were a first class feature of VIPM. There would be nothing better than being able to open up a native LabVIEW palette and being able to select from your code - all conveniently in the one place just like the OpenG ogrsc_dynamicpalette package does for OpenG etc...
It would be very useful if besides 'edit icon' and 'autogenerate icon' there would be an option to change the way the icon autogeneration happens.
For example in the LabVIEW icon editor, if you choose a template (which can be fully customised) which has a header, than the text entered in the icon editor is automatically placed under the header. Options like this, and also some other clever ways to cusomise the autogeneration of icons would make the customisation easier.
So I have a lightbulb moment today: why do I have to switch from LabVIEW to VIPM to build packages? Why can't I right click on a package build definition in my project's "Build Specifications" and either edit the configuration or build it directly from there?
My VIPM Package Table has so many entries now that I have to scroll up and down to view all the entries. I was thinking that a Tree View of the packages would make it easier to view and organise.
For instance the OpenG Package would be the root folder and clicking on this folder would show all the individual packages ie. Array Library, Boolean Library etc..
Just something little to speed things up.
Given the graphical paradigm of LabVIEW I think it would be sweet if I could click on an icon I see in the Insert >> LabVIEW Primitive... dialog to select it for the palette (rather than just text).
Just a small one... ...I think it would be sweet if the Insert >> LabVIEW Primitive... Dialog defaults to the previous search.
This may be an edge case not worth the time but I thought I'd throw it out there. It would be nice if you didn't have to wait for the Palette Dialog to refresh if you have already opened it. A refresh button could force an update or it could refresh after each install (in the background could be nice).
The idea is that Palette to Installation Location relationship would be one to many.
Have been playing with the Custom Category and I really like it.
One way could be to allow the Custom Category to be synchronised to the currently installed Category palette with the press of a button:
I am just trying to think of the best of both worlds where your Top Level mnu package is not an external dependency and its really easy to update wrt changes.
Another idea is that it could be a separate package that is included as a sub-package (ties into Expose Sub Package idea. VIPM can upgrade to the latest if not already installed, but the user is only ever distributing/installing one package.
We had some issues where it was changing from PC to PC - mine to his and vice versa (based on previous 'favourite' entries?).
But I can see other use cases where it would be handy.
Customer support service by UserEcho