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:
To vote for an existing idea:
If you need technical support for VIPM or any of JKI's other products, click here.
Modify VIPB to allow the user to create a duplicate build files in a single directory of VIs. This would be equivalent to the "Save As..." functionality. In addition, VIPB must be modified to allow multiple *.vipm files in a single directory. This functionality would be useful to:
One of my projects has 18 top-level palettes (150+ VIs, 50+ Controls) and could take advantage of this functionality for both of these example reasons.
Note: Separating this package into smaller packages would not be possible or advantageous.
Please VOTE if you agree. ;o)
I would be nice to have the ability to install a package directly into a end user specified project folder instead of being forced to install to a set location. This would be similar to how NPM manages dependencies for Javacript node.js projects.
I assume this package would not be installed onto any of the pallets, but it would allow a user to work with multiple projects using different versions of the same packages. You wouldn't have dependency overlap of installing things into your labview program files or OS user file locations. I guess this would just be an extension for packed project library but with versioning built in
After starting my build process, and waiting for about 10 minutes, it bombed with an error related to validation of the Automated Online Activation URL. This check is performed by calling "_ValidateAutoActivationURL.vi" from the NI_LV2PLicAPI.lvlib, and can therefore be done at any time. Can I request that this check is performed at the very beginning please? Thanks.
Sometimes my source for folder has old (or not yet finalized) VIs that I don't want to distribute, in my project I remove these VIs from the library/class, but since VIPM picks a whole folder as the build-source these VIs show up in the package.
By selecting library or class as the build source these functions wouldn't be included.
I ventured into the wonderful world of VIPM package building recently, and am impressed. However, one thing that immediately caused me issues was the use of a Source Folder as the root of the package definition. I wanted to point VIPM at my existing LabVIEW Project. Why? Because in my harddisk folder I have VIs not included in the Project, legacy files and VIs no longer in use. When pointing VIPM to the root folder it automatically picked up all these unwanted files, and it was a nightmare of "build error" after "build error" attempting to find them all and selectively remove them from the "Source File Settings" tree.
Idea: Can VIPM analyse the LabVIEW Project tree in the first instance of creating a new package to determine which VIs (files) are wanted and which are not to initialise/populate the Source File Settings?
With most things you can download these days there's usually some form of user rating, namely in the form of a score out of 5 stars, such as
The best of the best
There are so many packages on VIPM now, and some I've never seen before and have never tried, that I wonder which ones I might be missing out on. I can't install them all, but if each were to display a star rating I could quickly pick out some candidates to try! I would know that these ratings would be coming from LabVIEW users and that I could trust them to be an honest reflection on the usefulness of the package.
NI Tools Network
The NI Tools Network already implements a ratings system, can we have something similar for the packages list view window? Clearly those that are supported on the NI Tools Network repository would need their rating to come from NI.
Of course, the ratings need to come from somewhere, and that would be us users. I think it would be great if you were able to provide your own rating for packages you have installed. If you are uninstalling a package, VIPM could ask you to provide a rating whilst it uninstalls so that you can provide feedback on why - it maybe that you hated it and this way you get to provide a low rating.
It will be cool if there is a menu option (right click, menu bar etc.) for building a package of selected VIs?
With Project Provider mechanism, this seems feasible as well.
In VI Package Builder I'd like to be able to specify a less-than-or-equal package version in the Incompatible Packages section.
The use case is this:
I update a low-level reuse VIP A, breaking compatibility with some of the VIPs that depend on A. Currently (VIPM 2013), in A, I can only select Incompatible Packages with versions "greater-than-or-equal", or "equal". What I'd like is for the VIP A installer to tell the user that they must upgrade their already installed VIP B, that depends on A, if they want to proceed with upgrading A. To do that I need to be able to specify package B from a version downwards as an Incompatible Package in package A.
it would be super nice if the user could define additional default "destinations". it is annoying that you have to manually add custom destinations to every package created.
in particular, i hate adding the quick drop plugin destination.
in my use case, i'd like to set up a list of custom default destinations that every developer on my team will be using to help standardize where things will go. it would be really nice if we could programatically configure VIPM options so that this configuration can be automated. this could be configured via text configuration file, labview API or registry edit.
When building my package under Windows, VIPM uses the environment path %TEMP%, and appends "VIPB Temp\Source Distribution\LabVIEW\vi.lib\" before then appending the package source folder structure. This resulted in a path that was in excess of 255 characters and the build process failed with a generic I/O error.
I was able to resolve this by changing my %TEMP% path from "C:\Users\UserName\AppData\Local\Temp" to "C:\Temp", which reduced subsequent file paths sufficiently to allow the builder to complete.
I ask that we are able to influence this temporary folder structure, perhaps with a setting under Options to alter the folder used for temporary files, to assist in scenarios where aggregate file paths are excessively long.
Idea: Make the temporary folder a configurable path
Under "Source File Settings", there is the option to add passwords to VIs, libraries, etc. To lock without password, I currently use a Post-Install custom action to iterate over "Files Installed" and lock them based on file suffix. (lvclass and lvlib use Library.Set Lock State. ctl and vi use VI.Lock State.Set).
When the package is being installed, VIPM shows the license agreement. However once the package is installed, if I double click on the package, I don't have access to the license again, I have to uninstall the package and install it again if I want to see the license. (there might be other ways, but it is not obvious). I know I can add a product page link, but the license is part of the package, the user should be able to access it.
It would be nice if there was another buttion in the package info page (besides Uninstall, Show in Palettes and Show Examples) that would have the "show license" option.
When using OGPB this is doable because of two reasons:
This would allow me to make these changes (in a well known folder hierarchy - another plus) without having to unpackage the package and go in with a post-build hook.
I have setup a post-build VI that checks all the changing files into our SCC.
However when I hit the 'Show package in VIPM' VIPM will resave the VIPB file with the new (for next build) version information, leaving me with a dirty project.
It would be nice if there were no alterations after the post-build VI.
What is it?
currently you have the ability to add a file name prefix/postfix to all package files. I am proposing that we have the ability to add a file name prefix/postfix to ONLY the dependencies. This would be identical to the way that NI allows you to rename the dependencies in packed libraries.
Why is this needed?
When migrating your code into packages, you're presented with this series of events:
With this change implemented, the series of events changes to:
for a full discussion of this issue, see this thread http://forums.jki.net/topic/2103-rename-vi-dependencies/page__gopid__5165
VIPM provides quite a bit of information to the pre and post action VIs. Not enough information was provided in this feature request for us to make improvements. Please open new request with more details.
VIPM 2013 implements menu refresh automatically starting with LabVIEW 2013.
It would be really cool if Product Description has its own page.
Given that the Get Info page is really sweet in VIPM 2010, its a great way to present a lot of info about the product, but it would be easier to edit in a larger string control on its own page.
Is a built in spell check and HTML-like support (for e.g. links) out of the question too?
When i started using VIPM before few months i supposed to make some of my packages "public"(using "Window>>Show VI Package Repository Manager" but it won't appears to be "public" status in VIPM untill i press this button.(Am i correct?).
For the first time users this button should look like OR (just a suggestion)
I thought a cool new feature would be to allow adding multiple files on Insert... >> VI... to the Palette Editor instead of one at a time (and opposed to the entire folder).
Instrument drivers continue to be a headache to manage with LabVIEW. This refers to both "VISA" and "3rd party DLL based" instrument drivers. There are many issues encountered when dealing with instrument drivers:
I could see great value if VIPM could streamline the conversion of an instrument driver. An instrument driver "wizard" would seem to be the most logical way at handling the package building process with the following features:
(The installer/uninstaller could be accomplished through the Custom Actions, but requires additional work that could be automated with a command line switch.)
This would allow a VI Package Configuration to also include 3rd party instruments and would greatly improve the value of VIPM.
This feature is available from the tools menu of the VI Package builder in VIPM 2012 SP1. We've improved the process in VIPM 2013.
when creating a new VIP, automatically "exclude from build" folders that match user-defined strings (preferably compatible with labview regular expressions or PCRE). I suggest this because we have a well-defined file structure in our source code repository. all files in certain folders are never included in the build because they are only used during development. It would be nice if this could be auto-configured but only when creating new packages (so there are no surprises when opening an existing package).
This has been implemented in VIPM 2012.0.1
Problem Description: When I use the VI Package Builder, I can make a list of package dependencies, which becomes a .VIPC file in the root folder of VI Package.
There is even a button in the
"Package Dependencies" section to "Open VI Package Configuration". This
opens up VIPC editor, where I can explicitly select for each entry if I want include only the link to the VIP or the whole VIP.
After closing the VIPC editor I am still in the VI Package Builder. I makes me very confident that the settings I have made in the VIPC editor are valid for the VI package I am editing right now.
But apparently it not this way. It brings up some other problems, which are real problems (not just theoretical) to me:
If a VIP (call it a.vip) has a dependency(call it a_dep.vip) that is used in the Pre or Post-Install steps, than I start to have a dependency hierarchy. If a.vip is a dependency to a new new.vip than it's not enough anymore to just include the the a.vip and the a_dep.vip in a VIPC file with the new.vip. From this point on nothing guarantees that a_dep.vip will be installed before a.vip.
I'm building a project provider*, and I'd like to build a package of VIs that are installed into the <LabVIEW>\resource\Framework\Providers folder (no problem there), but I don't want VIPM to check/recompile my VIs - I just want it to copy them into that location. I know that the provider's dependancies will be there, and I don't want to bring across my own copy when I can reference the ones that are already there.
* This really is related to how you can only create project providers inplace on disk, and I'm getting around that limitation. That said, there may be other use cases where someone doesn't want VIPM to check for broken VIs. Maybe VIPM should warn me that I've got broken VIs, but I don't think it shouldn't let me build the package.
This could be for several reasons:
- I have done some custom building/obfuscation of code and want to distribute it using VIPM.
- I have developed code under a <LabVIEW> non-symbolic path and want to copy to source tree to include in a package build but do not want VIPM to compile these.
...and maybe tell me about updates to packages I don't have installed?
When I scan my repo, it tells me that there are no new verisons of packages that I have installed. I think it should also tell me if there are any new packages avialable since the last scan.
An initial iteration of this feature has been implemented in VIPM 2012.0.1.
Thought it would be cool if the subVIs in the palette used their Display Name (VI Properties>>Window Appearance>>Window Title) in VIPM rather than their actual name (unless it is undefined).
The reason being it just a final check I can do whilst building, and I would pick up any errors (names I missed).
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 not sure if this got bought up before (in the beta?) but I would like a better UI for interacting with dependencies then there currently is. I just find it hard to find what I want unless I know the exact spelling of the package name (VIPM 3.0) or display name (VIPM 2010) and scrolling through everything is not that fun
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
One of my use case is to create a package to "install" QuickDrop shortcut in LabVIEW.ini file. Source code could be too large for manage user interface dedicated. Workaround I've used is not satisfying.
I should understand that my use case is perhaps a wrong usage of VIPM.
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 really cool if you could edit icons in the Enhanced Icon Editor and have their layering preserved, so that next time when opened the image isn't merged. This may be currently impractical due to the state of the API currently available to handle this (which is why I have this idea here). Just thought I'd put it out there...
The VIPM Idea Exchange is a direct line of communication between you (the users) and the VIPM development team.
Your job is to submit your own suggestions, and vote for and discuss other users' suggestions.
JKI's job is to review suggestions, engage the community in the discussion, and keep you informed about what we're working on.
When you submit an idea, it will pass through several stages: