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
posted by Christopher Relf , 10 hours 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.
Vote
+7
UNDER REVIEW
posted by Ton Plomp , updated 7 days 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.

Vote
+5
COMPLETED
posted by Aristos Queue , updated 7 days ago , 1
If you open the LabVIEW Class Properties dialog, on the first page, you'll see a selection ring for "Default Palette". This allows you to select among any .mnu file that is a member of the class. This mnu file becomes the one that users see when they right click on a terminal or wire of the class data type, just like the shortcut palettes that are shown for other types.

It would be useful if I am building a package that contains a LabVIEW class to be able to specify one of the palettes that are built by the package to be the default palette for that class. I cannot just add them to the class because the palettes do not exist at edit time -- they are created by the installation process so that they have the right paths/names/etc. The VIPM editor would need to provide some mechanism for picking a class and providing a name of one of the palettes in the installed hierarchy, and then would update the class after installation to add that .mnu file to the class and set it as the default palette (all of which are available through the published scripting API).
Vote
Official answer
This has been implemented and now available in VIPM 2014
Official reply posted by Michael Aivaliotis VIPM Product Manager , 7 days ago
+5
COMPLETED
posted by Mje , updated 7 days ago , 5
When defining the Install Requirements of a package we can already restrict to target operating systems and LabVIEW versions. However we can't distinguish between 32-bit and 64-bit LabVIEW. It would be nice to be able to make this restriction as not all of our re-use packages can be used in either architecture.
Vote
Official answer
We've implemented this in VIPM 2014. You can now specify a bitness (32 vs 64 bit) requirement\restriction for both the Operating System and LabVIEW.
Official reply posted by Michael Aivaliotis VIPM Product Manager , 7 days ago
+1
COMPLETED
posted by Ton Plomp , updated 7 days ago , 2
I'm using source control and if I review a package configuration I sometimes hit the 'save configuration' button to make sure any changes I made are saved.

Then I have to commit my changes in the SCC, however if I review the diff of the .vipb file I notice that nothing substantially has been changed:


@@ -1,4 +1,4 @@

-<VI_Package_Builder_Settings Version="0.3" Created_Date="2011-08-24 21:12:58" Modified_Date="2012-04-11 09:40:24" Creator="u0850289" Comments="" ID="6b0414ba979d04a3d150a198945e988b">

+<VI_Package_Builder_Settings Version="0.3" Created_Date="2011-08-24 21:12:58" Modified_Date="2012-04-11 09:41:03" Creator="u0850289" Comments="" ID="8a01c93d378fe2cdf243b84854296d99">


The only thing that is changed is the modified date and the ID of the save. In my opinion that save is unnecessary, it would be nice if the save routine would check whether there are actual changes that need to be saved.
Vote
Official answer
We now disable the save button if there are no changes to be saved. You should never get unnecessary saves now. This is available in VIPM 2014.
Official reply posted by Michael Aivaliotis VIPM Product Manager , 7 days ago
+2
posted by Mathieu Fortin , updated 2 weeks 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
Vote
+2
posted by Ulrik Karlsson , updated 2 weeks ago , 3
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

Vote
+2
UNDER REVIEW
posted by Andy Soukup , updated 2 weeks 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).

Vote
+4
UNDER REVIEW
posted by Christopher Relf , updated 2 weeks 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.
Vote
+1
UNDER REVIEW
posted by Steen Schmidt , updated 2 weeks ago , 1
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
Vote
+2
COMPLETED
posted by Andy Soukup , updated 2 weeks ago , 3

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.


Vote
Official answer
Andy.We've implemented VIP templates in VIPM 2014.
Official reply posted by Michael Aivaliotis VIPM Product Manager , 2 weeks ago
+2
UNDER REVIEW
posted by Steen Schmidt (GPower) , updated 2 weeks ago , 3
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
Vote
+15
UNDER REVIEW
posted by Jonathon Green , updated 3 weeks 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... 

Vote
+4
COMPLETED
posted by Fabiola , updated 3 weeks ago , 0
I know this can be done via a post action, the problem is the way I am doing it now, it requires to save the changes in source and I would like that to only be done in the packaged VIs.

So either let's add an option to add the name and version to the VI documentation of every VI in the package or implement this other idea:
http://ideas.jki.net/topic/79442-custom-action-for...

Thanks,
Fab
Vote
Official answer
This is now available in VIPM 2014.
Official reply posted by Michael Aivaliotis VIPM Product Manager , 3 weeks ago
+6
COMPLETED
posted by James Jones , updated 4 weeks ago , 10
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:
 
  • Refactor Palettes or Destinations without risk of destroying the original
  • Create a subset/superset of the original distribution (customize contents/palettes for internal divisions, groups or teams)
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)
Vote
Official answer
This feature will be released in VIPM 2014.
Official reply posted by Michael Aivaliotis VIPM Product Manager , 1 month ago
0
posted by Stephen Wong , 1 month ago , 0
Can we set font size? the current font of the software is too small.......hard to see....
Vote
+3
COMPLETED
posted by Christopher Relf , updated 1 month ago , 5

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.

Vote
Official answer
This feature has been completed and will be included in VIPM 2014
Official reply posted by Michael Aivaliotis VIPM Product Manager , 1 month ago
+10
COMPLETED
posted by Jonathon Green , updated 1 month ago , 4
I would like the functionality that is available in OpenG Package Builder where I can specify VIs or LLB to be included in the package however, they will not get compiled. 

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. 
Vote
Official answer
This feature has been implemented and will be released in VIPM 2014
Official reply posted by Michael Aivaliotis VIPM Product Manager , 1 month ago
0
posted by Patrick Simmons , 1 month 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.
Vote
+3
posted by Jonathon Green , updated 1 month 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.

Vote
+12
UNDER REVIEW
posted by Jonathan Jay , updated 1 month 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.
Vote
0
posted by Eichimat , 2 months 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.
Vote
+5
posted by Christopher Relf , updated 3 months 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.
Vote
0
posted by Ninad Regundwar , 4 months 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/
Vote
+2
posted by K Q , updated 4 months 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.
Vote
+5
UNDER REVIEW
posted by Thoric , updated 4 months 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?


Vote
+5
UNDER REVIEW
posted by Jubilee , updated 4 months 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.
Vote
+5
UNDER REVIEW
posted by Jonathon Green , updated 4 months 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
Vote
+5
UNDER REVIEW
posted by Jonathon Green , updated 4 months 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.


Vote
+6
posted by Jonathon Green , updated 4 months ago , 2
There are times where I want to update code to be distributed e.g. iterate over it and do some custom changes, but I don't want these changes to persist in the source code e.g. update version/build information of a tool, add reuse VIs to a LabVIEW Project Library and mark private etc...

When using OGPB this is doable because of two reasons:
  • There is a API available (see VIPM idea here)
  • I have access to the distributed location of the code before it is packaged 
One way to solve this is to be able to run a script on the copied source code location (which I am guessing would be the hidden folder .source) - immediately after it has been copied.

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.
Vote
+10
UNDER REVIEW
posted by Jonathon Green , updated 4 months 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). 



Vote
0
posted by David Staab , updated 4 months ago , 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?
Vote
+1
posted by Jed D , 7 months ago , 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

Vote
0
posted by Thoric , 7 months ago , 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.

Vote
+1
posted by Thoric , 9 months ago , 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.

Vote
0
posted by Ashish.uttarwar VIPM Support Engineer , 9 months ago , 0

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.

Vote
+4
posted by Steen Schmidt , 9 months 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

Vote
0
posted by Ton Plomp , updated 11 months ago , 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

Vote
Official answer

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

Official reply posted by Michael Aivaliotis VIPM Product Manager , 11 months ago
+1
posted by Andy Soukup , updated 11 months ago , 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

Vote
0
posted by Bela Komoroczy , 1 year ago , 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.


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.

Vote
0
posted by Christopher Relf , 1 year ago , 0

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

Vote
+1
posted by Christopher Relf , 1 year ago , 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.

Vote
+1
posted by Ton Plomp , updated 1 year ago , 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.


Ton

Vote
+7
posted by Jonathon Green , updated 2 years ago , 3

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 


Vote
+1
posted by Brandyn Adderley , updated 2 years ago , 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.  


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


Vote
+1
posted by Olivier-jourdan , updated 2 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. 

Vote
+13
posted by Jonathon Green , updated 2 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...


Vote
+2
posted by Aristos Queue , 2 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.)
Vote
+2
posted by Christopher Relf , updated 2 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.
Vote