LabVIEW Developers Feature Brainstorming

[Noel]

Note (August 2008):  Thanks to all of the users who have provided feedback on these proposals.  At this time, NI is likely to proceed with the proposed LabVIEW API to access system directories.  However, NI has suspended plans to implement the proposed changes to the LabVIEW directory structure.  The proposed LabVIEW directory changes originated internally based on anticipated demand for NI to adhere to Microsoft Vista's directory recommendations. Since imposing a new directory structure impacts Alliance members and many of our other customers, we have decided to suspend these changes until there is a greater customer demand.

Forum post:   System directory access and LabVIEW directory changes

Proposal:  LabVIEW Directory Changes

Question: 

The proposed LabVIEW directory changes were based on a set of stated goals.   Do you agree with the goals?

Message Edited by Support on 08-21-2008 01:43 PM

[Jim_Kring]

Hi Noel,

I would like to see the following goal:

• To provide well-documented mechanisms for users and 3rd-parties to integrate addon libraries and plugins into LabVIEW.

It has always seemed to me that that most of the mechanisms for adding tools into the LabVIEW environment were for NI's purposes and users had to just figure them out.  I think that it should be a priority for NI to faciliatate 3rd-party extensions to the development environment.

Thanks,

-Jim

[Noel]

Hear, Hear!  I second your goal to document how 3rd parties can integrate addons and plugins into LabVIEW.

[Jim_Kring]

---

Noel wrote:

Hear, Hear!  I second your goal to document how 3rd parties can integrate addons and plugins into LabVIEW.

---

That's great -- I appreciate your support of this goal.  I've spent a bit of time figuring out how to integrate addons, so if you need me to review any documentation, I'd be more than happy to do so.  Also, I might be pressing my luck, but the folder reorganization effort might be a great opportunity for NI to revisit, refactor, and add additional capabilities for 3rd-party tools integration.  I've got a lot of thoughts on this, too, and I'm happy to share them.

[AristosQueue]

> and add additional capabilities for 3rd-party tools integration

Definitely not part of this discussion. The existing places where we have 3rd party plug-in capacity are being improved (and in some cases will be documented officially for the first time). But there are other places that we do not have 3rd party plug-in capacity that it might be desirable to have. If you want something to be pluggable that is not already pluggable, that's something to request from the developer(s) of that particular feature. What we're looking for in this conversation is
a) do all current plugging capacities have a well-defined location to plug in
and
b) does the overall framework and hierarchy of directories work to support plugging in the future should a new feature wish to add it?

[jdunham]

Hi Noel:  I agree with your goals.  However, I would like to add one

• Facilitate user environment customization and replication.

After 13 years or so of LabVIEW, mostly as a consultant, I hardly have any custom probes, or custom palettes, or a good way to install my library.  I have used a lot of different computers, and it's just too much trouble to migrate any of my favorite changes to a new computer.  So I make a handful of absolutely necessary changes to the LabVIEW options, and I use everything as it ships.  A lot of things like the palettes are truly annoying, but its much easier to memorize everything as is than it is to modify my LabVIEW environment.  I would love for this to be easier.

[Noel]

I have to be careful about making promises... but let's discuss your feedback...

Providing good documentation and guidelines to aid developers in creating addons and plugins is pretty much a “must have” for a successful transition to the new directory structure.  Without a well defined structure for both end users and NI internal developers, the structure might degrade over time as new features make arbitrary decisions on where to look for files. On the flip side, a well-defined new directory structure will facilitate more plugins/addons and higher quality plugins/addons.  Jim: I think you made the comment months ago about benefiting from economies of scale.  I’ve got you signed up for documentation review .

As Aristos noted, we should separate out requests for new plugin behavior with requests to ensure a smooth transition for existing plugin behavior.  A scalable directory structure will facilitate additional capabilities - both from NI and end-users! Hence, the two questions that Aristos noted are key!

Let's consider the first question – do all current plugin capacities have a well-defined location to plug in?  We need some level of refactoring to enhance consistency and use of the new directory structure.   For example, we currently have several features in LabVIEW that search for special files under the user.lib folder, such as error code text files, probes, example bin files, etc.  But, these tool lack consistency in their search locations – some files are in underscored subfolders (_probes), some are in non-underscored subfolders (errors), and some are not in subfolders (.bin3 examples files).  Furthermore, if third parties are to share an Addons folder, they probably would prefer if their addon files were in a product-specific folder – much like instrument drivers – where palettes, help, examples, API VIs, etc can easily be unzipped into a single product folder.  Tomorrow, I’ll try to mock up such a directory and post to the forum to get your feedback.

Facilitating environment customization and replication....I guess this would also include improved upgrade process.  Did you see the earlier post to this forum titled Improving the LabVIEW upgrade process?   After reading your post, you will likely benefit from having a directory structure that separates out application files from shared files from user files.  Right now your personal addons and plugins are mixed in with NI files and other 3rd party files.  Furthermore, if you share a machine with someone else, your files are mixed in with their files. If all your personal files and customizations were localized to your User space, identifying what to share between computers would be easier.

Whew...this is a rather long post.  I should call it quits...

- Noel

[jdunham]

---

Noel wrote:

...

Facilitating environment customization and replication....I guess this would also include improved upgrade process.  Did you see the earlier post to this forum titled Improving the LabVIEW upgrade process?   After reading your post, you will likely benefit from having a directory structure that separates out application files from shared files from user files.  Right now your personal addons and plugins are mixed in with NI files and other 3rd party files.  Furthermore, if you share a machine with someone else, your files are mixed in with their files. If all your personal files and customizations were localized to your User space, identifying what to share between computers would be easier.

Whew...this is a rather long post.  I should call it quits...

---

No, don't quit on us now!!!

My use case doesn't directly involve upgrades.  What I want to do is walk up to a new computer with  a fresh (or not-so-fresh) copy of labview on it, retrieve my personal environment from the Subversion server (source code control), and have all of my favorite settings, probes, palettes, and personal library VIs available when LabVIEW restarts.

I would prefer not to have to check out multiple folders, so I would want everything to go into the Preferences directory, and not have to drop some of my stuff into the Documents directory or anywhere else. 

Similarly I would like to have everyone on my team maintain a standard set of library VIs in the Public Preferences folder on each computer.

It sounds like you are headed in the right direction on this, but I wanted to clarify what my use cases are.

[Noel]

Jason:

Your request is very reasonable and I appreciate you clarifying your use case.  

I haven't used Subversion, but there are similarities with all source code control products.   I'm guessing you have some sort of client specification that maps your SCC depot structure to directories on disk.   Since the physical directory structures of Windows Vista differ from Window XP, you already need to account for this in your SCC setup (e.g., different client specifications per machine).   My guess is that you'd still need to account for these differences with the new directory structure since the actual physical directory path of Public Preferences differs between Windows Vista and Windows XP.  Is that OK? 

Also, keep in mind that there might be multiple directories to sync from your Subversion depot -- such as Public Preferences and possibly Public Documents, depending on how many files your group shares.  

Thanks,

- Noel

[AristosQueue]

Another thread lead me to recommend this as another goal of the spec:

• An app build with LV should look like a standalone app, not like a part of LabVIEW.

So directories that will be used by the application -- such as the error code text files or the default data directory -- should not have "National Instruments" or "LabVIEW" anywhere in their path. These should be directories specific to the built application.