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:

  1. Type your idea in the box below. The Idea Exchange will show you similar ideas as you're typing.
  2. If someone else has already submitted a similar idea, vote that idea up and add a comment to the discussion.
  3. 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:

  1. Click the Vote balloon next to any idea to show your support. Better yet, also add a comment to the discussion.
  2. 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.

+20

Replace Table View with Tree View in Main GUI

chrisreed 7 years ago • updated 7 years ago 5

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

+15
Under review

Support Layers for Non-VI icons (Sub-Palettes, category, etc)

Jonathon Green 7 years ago • updated by Michael Aivaliotis (VIPM Product Manager) 5 years ago 4
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... 

+14
Under review

Better indication for types of packages: Free, Trial, "For Money"

Jonathan Jay 7 years ago • updated by Michael Aivaliotis (VIPM Product Manager) 5 years ago 2
There are a few packages currently in the list that seem like they'd be quite useful but until I look at the package's info I don't know if its a free package, a trial for a paid package, or a "buy before use" package. If there was another column added to the list that would very obviously indicate this it would be helpful in both sorting and deciding on what to download and use.
+13

Native Support for Dynamic Palettes

Jonathon Green 7 years ago • updated by Michael Aivaliotis (VIPM Product Manager) 6 years ago 3

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


+10
Under review

Allow Adding Multiple Files to Palette Editor

Jonathon Green 7 years ago • updated by Michael Aivaliotis (VIPM Product Manager) 5 years ago 0

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



+10

Build vip packages from the project explorer "Build Specifications"

Christopher Relf 7 years ago • updated 7 years ago 0

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?


+9

Install package for all supported LV version

olivier-jourdan 7 years ago • updated by Michael Aivaliotis (VIPM Product Manager) 6 years ago 3
It would be great to be able to install a package for each compatible version installed on a computer.
+9

Better UI for Adding Dependencies

Jonathon Green 7 years ago • updated by Tim Vargo 3 years ago 4

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 :)


+8

Support for Multiple Installation Locations for a Palette

Jonathon Green 7 years ago • updated 7 years ago 2
This one came up - installing the same palette in multiple locations. E.g. maintain forwards and backwards compatibility with a Top Level mnu, if that location changed. Also would benefit idea of Dynamic Palettes.  

The idea is that Palette to Installation Location relationship would be one to many.

+8
Under review

Implement "Install for previous LabVIEW version"

Steen Schmidt (GPower) 5 years ago • updated by Christian Foisy 12 months ago 5
We often have enquiries from our customers to make available a version of our toolsets for an earlier version of LabVIEW than the VIP was developed for. We don't want to develop all our toolsets with LV 7.1 for instance, just to make certain all our users are covered, and it's a huge task to down-save all our toolsets and make new VIPs for those versions. The user also has a hard time doing this, as a simple "Save for Previous Version" doesn't cut it, as the user has to manually recreate the palette in the process (which many users don't know how to do).

VIPM currently allows the user to install for the LV version that the package was developed for, and for later versions as well if we have configured the package to allow this. VIPM uses Mass Compile for this (unless the user has disabled Mass Compile in VIPM of course). I suggest one of two changes:

1) Either allow the end-user to install a package for an earlier version of LabVIEW than the package was built for. This requires the user to have installed the lowest LV version that the downloaded package demands, as well as having installed the target LV version as well. Then VIPM could use the "Save for Previous..." method and re-create the palette for the user.

2) Or, allow the VIP-developer to build packages for earlier versions of LV than the VIs are developed for. This poses the same requirements on the developer, having both the source and target LV versions installed, and would enable VIPB to use "Save for Previous..." when building the packages.

I prefer 2), as that basically automates the process I'd otherwise go through to make our VIPs available for earlier versions of LV, but without me having to handle duplicate build scripts for VIPB. And it puts fewer requirements on our end users.

Best regards,
Steen, GPower
+8
Under review

Allow libraries as build source (instead of folders)

Ton Plomp 7 years ago • updated by Michael Aivaliotis (VIPM Product Manager) 5 years ago 7

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.

+7
Under review

Option to "Remove block diagrams" in VIPB

Steen Schmidt 5 years ago • updated by Jim_Kring (JKI Team) 1 year ago 5
Since password protecting VIs is really not that great a protection, we opt to remove block diagrams from our paid software. When building paid toolsets with VIPB it would be great to have an option to remove block diagrams during the package build, instead of us having to do it beforehand (with the risks that involves of losing the source code completely, although we use SCC and can thus step back if necessary).

When removing the block diagram from reuse VIs destined for the LV Dev environment, we limit that toolset for a single LV version obviously. Thus it would be nice to have the ability to build more than one package with a single build specification; one for each of a number of specified LV versions. Instead of specifying "LabVIEW 2012" vs. "LabVIEW 2012 or later", then maybe an optional selection list where you could tick of which LV versions to build for (resulting in N vip-files).

Or maybe I should just automate our dev process some more to do the above myself? Maybe I can use the VIPB API to do that...

Best regards,
Steen
Answer

Hi Joerg,


This should be possible with a post-build custom action VI.


(it's still not a native feature)


-Jim

+7
Under review

Use the LabVIEW Project tree to initialise a new build definition

Thoric 6 years ago • updated by Michael Aivaliotis (VIPM Product Manager) 5 years ago 2

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?


+7

Preview pane for packages

Greg Sands 7 years ago • updated by Jonathon Green 7 years ago 3
Currently, to see information on a package, it is necessary to double-click, which opens a modal window.  This makes it difficult to browse through a number of descriptions.  I suggest a preview pane (like in Windows Explorer) which either just shows the package description, or which shows all the contents of the package information window (including Install button etc).  Something like this hacked screen shot:
+6
Under review

Sort packages by license type

Jubilee 7 years ago • updated by Michael Aivaliotis (VIPM Product Manager) 5 years ago 1
I would like to install all the BSD licensed packages and all the packages with private type of license which is as free as BSD with no binding limitation in the small letters.
At the moment I need to go over each license and find afterwards that I actually installed a trial version or some other tool that I won't be able to use.
If VIPM could organize the packages not only by the name of the license type but also by a deeper understanding of it (there aren't that many license types in VIPM after all) then I'll feel much safer while installing packages from VIPM.
+6

user ranking of packages

Jubilee 7 years ago 0
Add 0-5 stars field to packages so users could rank the packages and even add comments, like in amazon, letting the community know how they use the package and how it helped them.
+5

Allow duplicate vi name in the same package

olivier-jourdan 7 years ago • updated by Michael Aivaliotis (VIPM Product Manager) 7 years ago 1
[Related to this thread on JKI forum]

My use case is to create a package which install templates. These templates could have some identical VI in different directory.
VIPM, currently doesn't allow to build this type of package.  
+5
Under review

Apply VIPC file on Project load

David Staab 4 years ago • updated 4 years ago 2
When a .lvproj file that has package dependencies is opened, those packages need to be applied (installed, upgraded, or downgraded...and conflicts with dependencies uninstalled) before the project loads. I want LV/VIPM to catch a "project.open" operation and first apply dependencies.

This will probably require a new tag in the project file to specify where the dependencies package is on disk. It'll probably also require access to a new Filter event from LV that notifies some process/tool of an impending File Open operation. So I don't expect much out of this request, but I'd sure like to see it!
+5
Under review

Allow Abort on Network Tasks

Jonathon Green 7 years ago • updated by Michael Aivaliotis (VIPM Product Manager) 5 years ago 0

I ran into the situation a few times when I wanted to abort what I was doing but couldn't. This seemed to be for network tasks. I thought it would be cool if I could abort these in the future.


+5
Under review

Compatible with LabVIEW (CwLV) Field

Jonathon Green 7 years ago • updated by Michael Aivaliotis (VIPM Product Manager) 5 years ago 0
I would be beneficial IMO if you could see the Compatible with LabVIEW level (standard, silver or gold) of a package in the main screen. 

Of course this would only apply to the LabVIEW Tools Network repo but would be good to know whilst perusing new downloads in VIPM. I expect this would become more important as the LVTN repo grows
+5

Distribute reuse components as packed project libraries

Christopher Relf 6 years ago • updated by Jonathan Cohn 5 years ago 2
The current options are folder, folder (preserve heirachy) and llb - I'd like to be able to build as a packed project library to further protect library subcomponents.
+4

LabVIEW Version Specific Deprecated Packages

Jonathon Green 7 years ago 0
This feature relates to VIPM Enterprise, but affects VIPM end users.

It would be handy if Deprecation was LabVIEW Version Specific, instead of global. 

This way a package would be shown in VIPM only for compatible versions of LabVIEW and hidden for non compatible versions.  
+4

Easy Synch to upgrade Custom Category

Jonathon Green 7 years ago 0

Have been playing with the Custom Category and I really like it. 

One issue I foresee is the difficulty in updating all packages when there is a change of the Custom Category.

One way could be to allow the Custom Category to be synchronised to the currently installed Category palette with the press of a button:

Another way, possible better, would be to link to an external file. This way, you update the external file and the next time you load the VIPB it will update:

This file could be as simple as a 32x32.png file or maybe there could be an a GUI option that allows a new VIPM file type to be created.

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.
+4
Under review

License files in RTF Format

Christopher Relf 6 years ago • updated by Michael Aivaliotis (VIPM Product Manager) 5 years ago 5
I like that I can add a license to my distributed packages, but I'd love if VIPM supported the Rich Text File format - the quasi-standard for license files.
+4

Reinstall package files.

Ulrik Karlsson 5 years ago • updated by Craig Lawton-Devine 2 years ago 4
When I am debugging my code, I often need to make some temporary changes to the installed packages. When the debugging is done, it would be nice to be able to reinstall the package instead of uninstall and then install again.

Ulrik, GPower

+4

Incompatible packages - more comparison selections

Steen Schmidt 5 years ago 0

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.


Makes sense?


Cheers,

Steen

+3

Make It Easier To Add Real Time Palettes

James McNally 2 years ago 0

I have built a number of internal libraries where I want the same support on desktop and RT palettes. This involves recreating the palettes from scratch currently.


There should be an easy way to have the same palette on both.

+3

Install VI Package Manager with admin privilege by default

Mathieu Fortin 5 years ago • updated by Andy Soukup 5 years ago 4
While trying to install a package.  I had Error 8 (something related to Read/Write file).  I spent some time trying or figure what was the problem.  I finaly tried run as admin and it worked.

Nitrof
+3

Search function should return results from package descriptions as well

Timothy Vargo 4 years ago • updated by Tim Vargo 3 years ago 3
When I use the "Search" function to filter the displayed packages for certain words, any result must contain my search words in one of the columns Name, Version, Repository, or Company to be listed.  This is insufficient -- I need results returned from package descriptions as well.  For example, type the word "icon" into the search field, and you currently get two results ("IconExpress" and "NI Icon Library Update Tool"); but I want the results to also list "UI Tools" since the word "icon" exists in that package's description text.

I recently gave a presentation on VIPM Professional to a room full of colleagues, trying to convince them that we should all own a copy.  The question was asked "Would this tool provide me with a flexible way to search our reuse libraries for some functionality that I am looking for"?  Alas, I had to answer "No".  This would be IMMENSELY helpful!



The package name "UI Tools" is not in the list above ...



... but it should be because the word "icon" exists in this package's description text.
+3

Expose Sub-packages

Jonathon Green 7 years ago • updated by Michael Aivaliotis (VIPM Product Manager) 5 years ago 1

It would be really cool if I could add multiple dependency packages to a package as sub-packages so I could ship one package that contained all required packages. 

I can currently do this with a .vipc file, but love the idea that a package could do it.
Another good reason for sub-packages over .vipc files that I forgot to mention: .vipc files currently have to be installed in the same version they were created. For example, this means that to support multiple versions of LabVIEW for a package release, I have to add multiple .vipc files if I want to include dependencies + package in a .zip release. 

To start with I don't mind if its not exposed through the UI - as I would more than happy to do it myself with hooks. 
Backwards support for OGPB would be nice too.

+3

The name of the vip file shouldn't be an identifier that VIPM uses.

Christopher Relf 5 years ago 0
Use some kind of GUID in the package that is the unique identifier between packages, and not the filename. I've had to change the filename of some packages a few times over the last few years (eg: changed product name due to a customer clarification), and it's a pain - now I have two (or more) parallel products that have schismed from the original, all because the filename changed.
+3

unattended deployment of VI packages

eichimat 5 years ago 0
I would suggest to implement a possibility to install packages unattended.
This could be useful if you have to setup lots of computers with the same libraries. If a unattended way was provided, this could be put in scrips etc.
Especially in our case this could be a reason why we cannot use VIPM. I created a *.vipc file and imported them manually. This worked very nice and easy but I am not willed to do this on all of our computers. A in my opinion easy and usual approach could be to put the functionality in a command line argument. I.e.:
VI Package Manager.exe /addLibrary "C:\library.vipc"

I know that there is the VIPM API. The problem is, that this is usable with the pro version only. To install the pro version on all of our computer would be too expensive and never needed any more after this step.
+3

Be able to have "custom action" VI with sub VI

olivier-jourdan 7 years ago • updated by Michael Aivaliotis (VIPM Product Manager) 6 years ago 2
As far as I've seen "custom action" VI cannot have SubVIs. It might be useful to allow that.
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. 

+3

Create Package from Windows Explorer Right Click Menu

David_L 7 years ago • updated by Christopher Relf 7 years ago 3
To zip something up in a Zip file and send it to someone, it's as easy as going to the directory, right clicking files and choosing "Add to zip" or "Compress" depending on your software.  VIPM should add this option to the context menu so you can easily create a new build specification at this location.  
+3

Ability to snapshot palettes (.png) to disk

Jonathon Green 7 years ago 0
I would like the ability for VIPM to save a .png to disk of the palette. 
Of course I can do this with external utilities but, it would be quicker if it was native.
This will be used for documentation etc...

The VIPM palette is very similar to the LabVIEW one:

I don't mind any of the differences (VIPM logo etc...) being there.

Additionally, an option to select all (atomic action) subpalettes would be great, then just dump them everything to a folder.
+2

Need a way to open VIP URLs from VIPM for Mac/Linux users

Aristos Queue 6 years ago 0
VIPM 2012 can create links that when users click on them in the browser will open VIPM and install the file... but only on Windows. For Mac and Linux users, there is no way to use a link, since there's no way to download the file and then open the package. The main VIPM menus need an equivalent to File >> Open File but for opening URLs. (Or fix the system so that links will open VIPM on these other platforms, but I get the impression that's hard to fix.)
+2

Cache Palette Search

Jonathon Green 7 years ago 0

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


+2

Insert LabVIEW SubVI...

Jonathon Green 7 years ago • updated 7 years ago 2
It would be really cool if there was another option on the Insert pop-up for LabVIEW SubVI....  
I envision this would navigate directly to the <LabVIEW> or (maybe even better) the <vi.lib> symbolic directory.
Just something little to speed things up.


+2

LabVIEW Tools Network should show what packages are already installed

John Lokanis 7 years ago 0
When I am browsing the LabVIEW Tools Network, packages that I have already installed are not marked as INSTALLED.  So, I cannot be sure if I already downloaded something.  I would like to see thiswork like the Apple App Store, where it shows me what is installed and alsolets me know what is new and what is updated.
+2

Option to create start menu items.

K Q 7 years ago • updated by Michael Aivaliotis (VIPM Product Manager) 5 years ago 1
This feature would allow easy creation of start menu items so that users can access build applications, examples, user manuals, etc. in the same way they do for many other applications.
+2
Under review

VIPC Contain Multiple Versions Of The Same Package

Brian Hoover 4 years ago • updated by Michael Aivaliotis (VIPM Product Manager) 4 years ago 1
Lets say I have a set of packages that I want to make into a single VIPC file.  I can then copy this file to another machine and install the packages offline if they are included in the VIPC which they are by default.  But lets say I have version 1.0 of an array package that supports 2011 and newer, but version 2.0 only supports 2012 and newer.  At the moment my VIPC would contain only one version.  So I have to either support 2011 and newer with the older package, or use the newer package, but abandon support for 2011 in my VIPC.  

My suggestion is to have the ability to put multiple versions of the same package into a VIPC.  This way when I am installing it offline and not connected to a repository, where all package versions could be available.  I could then use the same VIPC for 2012, or 2011, and in both cases I could have the latest version that is supported.
+2

Add a better interface to set up a repository

Christopher Relf 6 years ago • updated by Michael Aivaliotis (VIPM Product Manager) 6 years ago 3
i'd like to see a wizard added to the repo interface - i figure most people need help when they're setting up their first repository.  or, better yet, make the repo interface more like the package builder interface.
+2

Manually Set "Show In Palettes" Action

Patrick Simmons 5 years ago 0
When creating a package, placing a *.mnu file manually from source files does not allow you to set "Show in Palettes" action.  When a user selects "Show in Palettes" from VIPM, a random subpalette is brought up instead of the top-level palette.  

In this case, the "Palettes" tab in VI Package Builder is not used at all.
+2
Under review

auto-exclude user-defined folders from build

Andy Soukup 5 years ago • updated 5 years ago 5

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

+2

Allow Defined Destination of Included Dependent Code

Jonathon Green 7 years ago • updated 7 years ago 0
I would like control over specifying the name and location of internal dependencies. 

I envisage another entry in Destination (where if not configured, VIPM would just do what its doing at the moment).


This topic relates to this thread here.
+1

Rebuild library after marking some VIs as Exclude from Package

Richard Thomas 1 year ago 0

I built a hardware driver, all VIs are part of a library. The library contains some unit testing VIs which I don't need as a part of the VIP distribution, so they are marked as "Exclude from Package" on the Source File Settings section of VIPB.


However, as these VIs are a part of the library, when excluded from the build they cause the library to list them as missing dependencies when the VIP is installed on a development machine (the little yellow exclamation marks in the Project View).


If I move the VIs to outside the library this creates scoping issues with certain private dependencies only accessible from within the library, so they must remain within the library.


Ideally, VIPBuilder would repair the library by removing these dependencies safely within LabVIEW (not just excluding the files from the package) and thus maintaining library integrity. Maybe his can't be done.


But can I ask, what's the proper way to exclude VIs from the package that are listed as belonging to a library without the library becoming bad?

+1

Auto-populate VIPM packages from disk for faster LabView installations on multiple Computers

David Zurbriggen 2 years ago • updated by Роман Лещишин 2 months ago 3

When i quickly want to have a new LabVIEW installation on another PC or VM, I can let run the LabVIEW installation unattended, but then it takes quite some presence-time to re-install all the VI packages with VIPM. So I usually just copy the whole LabVIEW user.lib folder over to the new VM. While LabVIEW gathers/auto-populates the user libraries automatically and the packages vi folders show up as palettes, VIPM doesn't do this, what in my eyes would be expected behavior. The whole VIPM packages list stays empty even though all the packages are there on disk. But maybe I oversee something, and there is already a way to make this auto-population happen...?

+1

Auto generate Pallete

Ninad Regundwar 5 years ago 0
In VI Package Builder when a new VI is added to the existing vipb the VI should be auto generated in the functions pallet without clicking the 'Auto generate Pallet'

Refer to post:http://forums.jki.net/topic/2227-add-new-vi-to-the-pallet/
+1

Insert LabVIEW Primitive Defaults to Previous Search

Jonathon Green 7 years ago 0

Just a small one... ...I think it would be sweet if the Insert >> LabVIEW Primitive... Dialog defaults to the previous search. 

It should have the text highlighted in focus so I can just type over it if I am doing a completely different search, but if I am in the middle of putting a bunch of like-primitives in the palette then there may already be there from the last keyword search.

+1

Visual Indication of Auto-populating Field

Jonathon Green 7 years ago 0
I thought it would be cool to know what fields are autopopulated but some small visual indicator. 
The only way we had to check was in the VIPB file. 
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.