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.

0

Build Package option in Project (using Project Provider)

It will be cool if there is a menu option (right click, menu bar etc.) for building a package of selected VIs?


http://screencast.com/t/bZbEaDixH


With Project Provider mechanism, this seems feasible as well.

+4

Incompatible packages - more comparison selections

Steen Schmidt 11 lat temu 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

0

Save the VIPB file before the 'Post Build Action' is run

Ton Plomp 11 lat temu Ostatnio zmodyfikowane przez Michael Aivaliotis (VIPM Product Manager) 11 lat temu 1

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.


Ton

Odpowiedź

Is this basically a request for NOT autosaving? Just want to clarify.

+1

rename dependencies (without renaming package files)

Andy Soukup 11 lat temu zaktualizowano 11 lat temu 2

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:

  1. I have X.vi. It is some piece of re-usable code that hasn't yet made it into a VIP.
  2. I build package A.vip and it has dependency X.vi included in the package
  3. I have application Application.vi that has dependencies A.vip and X.vi 
  4. Now, when i open Application.vi, I am unsure which X.vi will be used?!
Now, as a consequence of me applying configuration management, I have now completely lost configuration management if X.vi! (darn!). Usually, you are able to migrate X.vi into a package fairly quickly, but if you're working with a large library of reusable code (mine is 2300 VIs), this becomes an issue. 


With this change implemented, the series of events changes to:

  1. I build package A.vip and it has dependency X.vi included in the package as A_X.vi (assuming you add "A_" prefix to dependencies)
  2. I have application Application.vi that has dependencies A.vip and X.vi 
  3. Now, when i open Application.vi, the application uses X.vi and A.vip used A_X.vi

for a full discussion of this issue, see this thread http://forums.jki.net/topic/2103-rename-vi-dependencies/page__gopid__5165

0

store dependency in VIP file (as in VIPC)

Bela Komoroczy 11 lat temu Ostatnio zmodyfikowane przez Michael Aivaliotis (VIPM Product Manager) 11 lat temu 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.

Image 36

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.

Image 35

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.


Idea:

The option to have VIP file dependencies copied into the VIP file should be possible in the future. I find it the easiest to just simply reflect the status of the packages in the .VIPC file. There could be a switch like "Import Stored packages from VIPC file?" to keep compatibility with previous versions of VIPM.

0

On project open, have VIPM scan for package updates of packages used by the project.

Christopher Relf 11 lat temu zaktualizowano 11 lat temu 1
0

On LabVIEW open, have VIPM scan for package updates of installed packages.

Christopher Relf 11 lat temu 0

...and maybe tell me about updates to packages I don't have installed?

+1

On scanning a repo, VIPM should tell me if there are new packages

Christopher Relf 11 lat temu 0

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.

+1

Add the Default Data directory as a target folder

Ton Plomp 11 lat temu zaktualizowano 11 lat temu 2

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.

Image 32


Ton

+1

Ability to categorize VI packages and show category in the form of "stars"

Brandyn Adderley 12 lat temu Ostatnio zmodyfikowane przez David_L 12 lat temu 1

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


Furthermore, once this information is gathered, you can then possibly search and install only Rock solid packages, for example


+3

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

olivier-jourdan 13 lat temu Ostatnio zmodyfikowane przez Michael Aivaliotis (VIPM Product Manager) 12 lat temu 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. 

+13

Native Support for Dynamic Palettes

Jonathon Green 13 lat temu Ostatnio zmodyfikowane przez Michael Aivaliotis (VIPM Product Manager) 12 lat temu 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...


Image 10
+2

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

Aristos Queue 12 lat temu 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

Add a better interface to set up a repository

Christopher Relf 12 lat temu Ostatnio zmodyfikowane przez Michael Aivaliotis (VIPM Product Manager) 12 lat temu 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.
+9

Install package for all supported LV version

olivier-jourdan 12 lat temu Ostatnio zmodyfikowane przez Michael Aivaliotis (VIPM Product Manager) 12 lat temu 3
It would be great to be able to install a package for each compatible version installed on a computer.
+1

customise autogenerate icon

Bela Komoroczy 12 lat temu 0
In the VI package buider in the 'Palettes' section you have the possibility to edit the icons.
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.
+2

LabVIEW Tools Network should show what packages are already installed

John Lokanis 12 lat temu 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.
+10

Build vip packages from the project explorer "Build Specifications"

Christopher Relf 12 lat temu zaktualizowano 12 lat temu 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?

Image 29

+5

Allow duplicate vi name in the same package

olivier-jourdan 13 lat temu Ostatnio zmodyfikowane przez Michael Aivaliotis (VIPM Product Manager) 12 lat temu 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.  
+2

Allow Defined Destination of Included Dependent Code

Jonathon Green 12 lat temu zaktualizowano 12 lat temu 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).

Image 25

This topic relates to this thread here.
+4

LabVIEW Version Specific Deprecated Packages

Jonathon Green 12 lat temu 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.  
+3

Create Package from Windows Explorer Right Click Menu

David_L 13 lat temu Ostatnio zmodyfikowane przez Christopher Relf 12 lat temu 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.  
+7

Preview pane for packages

Greg Sands 12 lat temu Ostatnio zmodyfikowane przez Jonathon Green 12 lat temu 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:
Image 23
+20

Replace Table View with Tree View in Main GUI

chrisreed 13 lat temu zaktualizowano 12 lat temu 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..

+6

user ranking of packages

Jubilee 12 lat temu 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.
+2

Insert LabVIEW SubVI...

Jonathon Green 13 lat temu zaktualizowano 13 lat temu 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.

Image 21

+1

Double Click Icon to Insert LabVIEW Primitive

Jonathon Green 13 lat temu zaktualizowano 13 lat temu 0

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


Image 19

Here is a quick edit (not complete) of what may be cool - to show all search hits with icons and text that could be scrolled through and double-clicked.

Image 20

+1

Insert LabVIEW Primitive Defaults to Previous Search

Jonathon Green 13 lat temu 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.

Image 18
+2

Cache Palette Search

Jonathon Green 13 lat temu 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). 


Image 17
+3

Ability to snapshot palettes (.png) to disk

Jonathon Green 13 lat temu 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:
Image 14
Image 15

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

Support for Multiple Installation Locations for a Palette

Jonathon Green 13 lat temu zaktualizowano 13 lat temu 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.

Image 11
+4

Easy Synch to upgrade Custom Category

Jonathon Green 13 lat temu 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:
Image 12

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:
Image 13

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

Visual Indication of Auto-populating Field

Jonathon Green 13 lat temu 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.