Settable defaults for package properties

[hfettig]

It would be great if it were possible (in the professional version) to be able to set defaults for Package Description, etc. rather than auto filling it from the package name and organization name. I find myself re-typing things for each package (although I am starting to include a default .vipb file for each new package source).

 

While your at it it would be nice to have a bit more control over the package name as well, especially the _lib_ part. Maybe an enum with a couple of options, e.g. _rsc_.

 

Cheers,

Heiko

[Jim Kring]

It would be great if it were possible (in the professional version) to be able to set defaults for Package Description, etc. rather than auto filling it from the package name and organization name. I find myself re-typing things for each package (although I am starting to include a default .vipb file for each new package source).

 

While your at it it would be nice to have a bit more control over the package name as well, especially the _lib_ part. Maybe an enum with a couple of options, e.g. _rsc_.

 

Cheers,

Heiko

 

Hello Heiko,

 

Thanks for the great idea -- configurable defaults would sure make things easier when you are creating new packages. Your solution, to have a "template" VI Package Source Folder (or ".vipb" file) that you use as a starting point for new packages is what we recommend for your use case. This is especially useful for organizations where one or more individuals might be creating new packages -- since, default settings would only apply to individual developers and not all developers in the team.

 

Can you provide more information about the nature of the items that you are packaging? For example, what types of items are you packaging, where you need the "rsc" (vs. "lib") in the package name? If we can understand all the use cases, it would help us consider the design of this feature.

 

Thanks,

 

-Jim

[hfettig]

Can you provide more information about the nature of the items that you are packaging? For example, what types of items are you packaging, where you need the "rsc" (vs. "lib") in the package name? If we can understand all the use cases, it would help us consider the design of this feature.

 

So far I have only one use case for the rsc and that one I created using OpenG package builder. Basically I created a package that creates a category for my company in the palettes and points to a DynamicPalette folder in user.lib/_RFpis.lib. This is where I put all the mnu file for the packages I create with VIPM.

 

Incidentally do you have an idea how to create a category in the Control Palette? I put an mnu file into menus/categories and get a category entry on the functions palette, but when I put an mnu file into menus/Controls nothing happens.

 

Other use cases:

 

I have a set of templates that I packaged and install into the templates folder. Those currently have _lib_ but might be more accurately called _tpl_ or something to that effect.

 

I was also thinking of packaging Mark Balla's icon editor to easily install it. Here I would probably use _rsc_.

 

Of course packaging those things are completely different use cases from packaging re-use VIs. There are no palette entries involved and you might want to be able to support multiple destinations. So maybe it is simpler to just continue using OpenG package builder for those cases.

 

Heiko

[Jim Kring]

Hey Heiko,

 

Thanks for the details on the various use cases:

• Palette Category
  
• Templates
  
• Editing Tools
  

> do you have an idea how to create a category in the Control Palette?

 

An MNU can (but doesn't have to) have one functions palette and one controls palette inside of it. I can help with this, off-line, if you want.

 

> So maybe it is simpler to just continue using OpenG package builder for those cases.

For an advanced user with highly custom use-cases that are not related to packaging and installing reuse libraries, I think you're right. That said, please continue to let us know about your use cases and ideas. We want to be able to include support for common packaging use cases inside VIPM and thus simplify the process.

 

-Jim