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.

+8
Ülevaatamisel

Option to "Remove block diagrams" in VIPB

Steen Schmidt 11 aastat tagasi uuendaja jonlim 5 aastat tagasi 6
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
Vasta
Jim_Kring (JKI Team) 7 aastat tagasi

Hi Joerg,


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


(it's still not a native feature)


-Jim

0

Display toolkits license status

kosistivan 5 aastat tagasi 0

It would be great to see (or be able to filter out) toolkits, which are registered by Third-Party Activation Toolkit, and see its statuses. Because it happens, that some toolkits have trial period, then it is expired - and LabVIEW warns about it. When one wants to remove these toolkits, he has to open VIPM - but then he needs to search those packages by name.

But if - for example - first time user turns off notification window in LabVIEW for expired license, he does not see it in future. But, there are still toolkits with invalid (expired) license - and when he wants to uninstall them, he needs to open Activation Add-On window, check toolkits and their statuses, go to VIPM, and remove them.

If there would be statuses visible in VIPM, then one sees it directly there, and could manage - either buy/prolong license, or uninstall toolkit so he will not be bothered by it in the future.

This feature is not important, because such situation occurs quite seldom, but it could make routine a bit easier.

Thanks a lot,

Sincerely, kosist90.

+2

VIPM API for VIPC Contents

steven dusing 6 aastat tagasi 0

It would be awesome if there were a way to programmatically read the contents of a VIPC file. I don't know that there's a way to do this yet using the VIPM API

0

Font Size

Manzolli 6 aastat tagasi 0

I have a Surface Book 2 with a 3000x2000 pixels 13.5" screen. With screens like that its mandatory a way to change the font size. I suggest adding a ability to change the package list font, at least.

+1

The "show in palettes" button for xctl

zz x 6 aastat tagasi 0

The show in palettes button in the package information dialog does not support xctl? If only xctl is added to the controls palette without ctl or vi, then the button is disabled after the package is installed.

0

Fix the search text field not working with key repeat delay (key hold)

matt baker 6 aastat tagasi 0

The search text field doesn't handle key down and hold events / repeat. For example holding down the delete key should strat deleting multiple characters after a while. Same for the cursor keys moving the caret position - it doesn't work when held down.

0

Open links in the default browser instead of forcing Internet Explorer

matt baker 6 aastat tagasi 0

Use the ShellExecute WinAPI function to automatically open links in the default browser for Windows systems.

IE is horrendous.

+1

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

David Zurbriggen 8 aastat tagasi uuendaja Роман Лещишин 6 aastat tagasi 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...?

0

Prevent duplicate function palette entries in "syncronized" destination folders

Patric Jenni 7 aastat tagasi 0

Installing a package with a custom functions palette to the folders user.lib or instr.lib (eg. user.lib/My Library) results in duplicate entries in the functions palette when the package is installed.


This is due to automatic synchronisation of the functions palette within these folders. Adding an (_) underscore in front of the package installation directory (e.g. user.lib/_My Library) skips LabVIEWs automatic synchronisation of the functions palette and therefore only shows the custom functions palette like expected.


I would like VIPM to check if a package will be installed to one of these folders (without an underscore as the first letter) AND does have a custom functions palette. If so, VIPM should show a hint like "...this will result in duplicate function palettes entries..." (or something better). At least, this fact should be better documented.

+8
Ülevaatamisel

Implement "Install for previous LabVIEW version"

Steen Schmidt (GPower) 11 aastat tagasi uuendaja Christian Foisy 7 aastat tagasi 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
+1

Rebuild library after marking some VIs as Exclude from Package

Richard Thomas 7 aastat tagasi 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?

0

Bug in open Package creation

Yamaeda 7 aastat tagasi uuendatud 7 aastat tagasi 2

For some reason i get an error when opening a package in the creator from the Latest package list, this error seems to stick, as further clicks on the Build package button doesn't do anything. 

What i need to do is restart VIPM and Build Package and select Open package.

+5

Reinstall package files.

Ulrik Karlsson 11 aastat tagasi uuendaja Craig Lawton-Devine 8 aastat tagasi 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

Image 37
+4

Make It Easier To Add Real Time Palettes

James McNally 8 aastat tagasi 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.

0

Package hierarchy for a selection of packages or package configuration

ChristianL 8 aastat tagasi 0

A feature or function to display a hierarchy of packages showing the dependencies between different packages, based on a selection of packages, what is currently installed, or all packages in a package configuration. Similar to the VI or class hierarchy in LV.

0

Jual obat suplemen peninggi badan tiens murah asli

Bro Youtube 9 aastat tagasi 0

Kami menjual Jual obat suplemen peninggi badan tiens murah asli dalam bentuk paketan, kenapa begitu? maksudnya biar sesuai dengan badget (uang) dan kebutuhan konsumen, karena setiap orang budget dan kebutuhan ingin naik tingginya berbeda. Sudah jelas kan? 😉 Anda bisa memilih Harga Paket Suplemen Peninggi Badan Tiens berikut ini sesuai badget kemampuan uang dan kebutuhan ingin naik tingginya :

+2

View by date / recent additions

Greg Sands 13 aastat tagasi uuendaja Ian Nicholson 9 aastat tagasi 3
There are now an increasing number of packages using VIPM, and it can be hard to keep track of what is added.  I would like to be able to see packages that have been recently added to the VIPM repository.  One possibility would be a column which is the packages' release date, although that is not always defined.  Another would be View/Show/Recent Additions which would show all packages added locally in, say, the last month.
0

​Auto-exclude folders from VIPB source file settings by default

Pavithra 9 aastat tagasi 0

It will be nice to have a property/option to exclude newly added folders from package by default. As of now any new folder under Source directory is included in package as default, It will be nice to somehow exclude new folders by default.


I have situation where I feel this option will be very useful.


I and my team are creating lots of Instrument drivers for internal purpose and release them very frequently. We have all our code under Instrument Driver folder. Instrument Driver folder includes sub folder (category of instrument drivers like Power supply, RF etc) and menu files that needs to be deployed while installing packages. With help of menu files drivers will be shown up in LabVIEW functionally palette.Image 47

Image 48

Say to build Keithley 24xx, I need to include Instrument Driver as source directory and include Keithey 24xx folder and whole hierarchy of Instrument Driver menu files (ie the menu file directly inside Instrument Driver and the one inside Power Supply folder) and build package over it. Rest of the unnecessary folders are excluded from packages. Please see I need the whole hierarchy of menu files so that in the LabVIEW palette drivers are shown in the same level/folders as shown in window explorer (Instrument driver -> Power supply -> Keithley 24xx)


  1. Whenever a new folder or driver category is created under Instrument Driver, the next time in Keithley package, the new folder is included in the ‘Source file setting’ by default, which is NOT needed. So exclude folders by default will be helpful here.
  2. When there are multiples PC used for development purpose, there comes one more situation. VIPM removes file exclusions if source code folders aren't located on the machine where the build spec is being modified. So take the same example:
    1. A build spec is created on machine1 with this source directory: Instrument Driver
    2. Inside of that folder are several other folders: ...\Power Supply\Keithley 24xx, ...\Power Supply\Agilent E3631A, ...\RF\CMW, ...\Scope\Tektronix.
    3. In the source file settings ...\Power Supply\Agilent E3631A, ...\RF\CMW, ...\Scope\Tektronix are EXCLUDED from package
    4. The build spec is saved and closed
    5. The build spec is opened on machine2 that only has ...\Power Supply\Keithley 24xx folder
    6. VIPM will remove the folder exclusions properties of..\Power Supply\Agilent E3631A, ...\RF\CMW, ...\Scope\Tektronix (as folders are missing)
    7. The build spec is saved and closed
    8. The build spec is opened again on machine1
    9. The build will now include ..\Power Supply\Agilent E3631A, ...\RF\CMW, ...\Scope\Tektronix which were excluded first time but in the second build their properties were lost and now VIPM thinks they are newly encountered folders and include them by default.

This causes lots of issues and before each build developer has to verify the ‘Source file settings’ causing consumption of time.

0

Can VIPM sync the installed list in some host?

刘新元 9 aastat tagasi uuendaja Ashish Uttarwar 9 aastat tagasi 1
When we reinstall labview or PC crash, we can get the install all we had and install all package automatic. I think that would be cool.
+9

Better UI for Adding Dependencies

Jonathon Green 13 aastat tagasi uuendaja Tim Vargo 9 aastat tagasi 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 


Image 5
0

"Generate Preview" function for package build specs

Tim Vargo 9 aastat tagasi uuendatud 9 aastat tagasi 1
While using the VI Package Builder, once a package spec is complete or nearly complete, it would be very useful to be able to see a "Preview" of the build -- that is what the build WOULD look like if built using the current specs. This would be analogous to the existing Generate Preview function in LabVIEW projects' Build Specification properties. Such a preview would help to clarify exactly what folders the various project files will be deployed to, what their new names will be if prefix/suffix renaming has been enabled, which items will have Protection Settings, what menus will receive new entries, where any new palettes will be placed, etc., etc.

Some similar preview might be useful for VI Package Configurations as well?
+3

Search function should return results from package descriptions as well

Timothy Vargo 10 aastat tagasi uuendaja Tim Vargo 9 aastat tagasi 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!

Image 41

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

Image 40

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

Allow Palettes to be generated for class and libraries in a package

Brian Shea 10 aastat tagasi 0
Allow palettes to be generated for classes and libraries much like they are created for the overall package. Currently, only one palette can be generated and attached to one class or library. Nice feature, but when a package has multiple classes or libraries, it's a bit limiting.
+1

An API to Create a VIPC from one or more Packages

Priyadarsini 10 aastat tagasi uuendatud 10 aastat tagasi 3
Currently, the VIPM APIs support creating a VIPC given a VI or folder or LVProject. But there should also be a way to create a VIPC given a set of Packages. In this way we can create packages & a package configuration programmatically.
+5
Ülevaatamisel

Apply VIPC file on Project load

David Staab 10 aastat tagasi uuendatud 10 aastat tagasi 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!
0

Create and store "Package Configuration" files in online profile

Francois Normandin 10 aastat tagasi 0
Adding package configurations to a project is a great way to always have all my dependencies available for a quick install. However, these files can be quite large and take a lot of time synchronizing with Hg or Git repository.

It would be awesome to be able to create these packages online and store them in our user profile. Consequently, having the ability to share package configurations between users (publicly or privately) would allow to keep small vipc files in LabVIEW project without the need to "include packages" in the configuration file.

+2
Ülevaatamisel

VIPC Contain Multiple Versions Of The Same Package

Brian Hoover 10 aastat tagasi uuendaja Michael Aivaliotis (VIPM Product Manager) 10 aastat tagasi 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.
+1

Dependencies have to be uninstalled at the last

Priyadarsini 10 aastat tagasi 0
Dependencies of a package are installed first followed by the main package itself which is the correct behavior. But uninstallation should be in the reverse. Main package has to be uninstalled first followed by its dependent packages. This will be useful if the main package's custom post-uninstall action uses a VI from the dependent package. Also if there is some issue with the uninstallation process the main package will not be left alone without its dependencies.
+5

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

Christopher Relf 11 aastat tagasi 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.
+8
Ülevaatamisel

Allow libraries as build source (instead of folders)

Ton Plomp 13 aastat tagasi uuendaja Michael Aivaliotis (VIPM Product Manager) 11 aastat tagasi 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.

+3

Install VI Package Manager with admin privilege by default

Mathieu Fortin 11 aastat tagasi uuendaja Andy Soukup 11 aastat tagasi 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
+2
Ülevaatamisel

auto-exclude user-defined folders from build

Andy Soukup 12 aastat tagasi uuendatud 11 aastat tagasi 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).

+4
Ülevaatamisel

License files in RTF Format

Christopher Relf 12 aastat tagasi uuendaja Michael Aivaliotis (VIPM Product Manager) 11 aastat tagasi 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.
+15
Ülevaatamisel

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

Jonathon Green 13 aastat tagasi uuendaja Michael Aivaliotis (VIPM Product Manager) 11 aastat tagasi 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... 

Image 16
+2

Manually Set "Show In Palettes" Action

Patrick Simmons 11 aastat tagasi 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.
+3

Expose Sub-packages

Jonathon Green 13 aastat tagasi uuendaja Michael Aivaliotis (VIPM Product Manager) 11 aastat tagasi 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.

+14
Ülevaatamisel

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

Jonathan Jay 13 aastat tagasi uuendaja Michael Aivaliotis (VIPM Product Manager) 11 aastat tagasi 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.
+3

unattended deployment of VI packages

eichimat 11 aastat tagasi 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.
+5

Distribute reuse components as packed project libraries

Christopher Relf 12 aastat tagasi uuendaja Jonathan Cohn 11 aastat tagasi 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.
+1

Auto generate Pallete

Ninad Regundwar 11 aastat tagasi 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/
+2

Option to create start menu items.

K Q 13 aastat tagasi uuendaja Michael Aivaliotis (VIPM Product Manager) 11 aastat tagasi 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.
+7
Ülevaatamisel

Use the LabVIEW Project tree to initialise a new build definition

Thoric 12 aastat tagasi uuendaja Michael Aivaliotis (VIPM Product Manager) 11 aastat tagasi 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?


+8
Ülevaatamisel

Sort packages by license type

Jubilee 13 aastat tagasi uuendaja Michael Aivaliotis (VIPM Product Manager) 11 aastat tagasi 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.
+5
Ülevaatamisel

Compatible with LabVIEW (CwLV) Field

Jonathon Green 13 aastat tagasi uuendaja Michael Aivaliotis (VIPM Product Manager) 11 aastat tagasi 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
Ülevaatamisel

Allow Abort on Network Tasks

Jonathon Green 13 aastat tagasi uuendaja Michael Aivaliotis (VIPM Product Manager) 11 aastat tagasi 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.


Image 7
+11
Ülevaatamisel

Allow Adding Multiple Files to Palette Editor

Jonathon Green 13 aastat tagasi uuendaja Michael Aivaliotis (VIPM Product Manager) 11 aastat tagasi 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). 


Image 6

0

Disable Password Protection for Merge VIs

David Staab 11 aastat tagasi uuendaja Michael Aivaliotis (VIPM Product Manager) 11 aastat tagasi 1
Items with "Place VI Contents" enabled can't be password-protected. We currently have to find all of these VIs in the Source File Settings list and disable password protection inheritance on them manually. Why not do this automatically?
+1

Custom Package Install Location

Jed D 11 aastat tagasi 0

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

+1

Pre-check the Automated Online Activation URL

Thoric 11 aastat tagasi 0

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.

+1

Implement package star ratings

Thoric 11 aastat tagasi 0

Star Ratings

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.


Submission

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.