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

Questions: 

After reading over the proposed directory changes, what concerns do you have?   What changes are you interested in learning more about?  Are you concerned about any specific use cases being considered as part of the proposed directory changes?

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

[Jim_Kring]

I have some questions about the Plugins section of Changes to the LabVIEW Directory, which describes the following change:

From:

various directories under <LabVIEW Application Data>

To:

<LabVIEW User Documents>\Plugins
<LabVIEW Public Documents>\Plugins

Can you go into any more detail on the <LabVIEW Public Documents>\Plugins folder sub-structure and functionality as it would relate to specific directories and functionality currently under <LabVIEW Application Data>?  For example, the section mentions the LabVIEW/project folder (which adds Tools>> menu-launch items).  However, it does not state exactly how this will look under the new Plugins directory.

I have some thoughts on this.  First, I don't really like the name "project" for something that adds a menu item to the Tools>> menu (and, I don't really like the name "wizard" for something that adds items to the File>> menu).  This would be a great opportunity to rename the LabVIEW/tools and LabVIEW/wizard folders.

I would suggest structuring the Plugins folder like the following (with support for adding items to all the menus):

• <LabVIEW Public Documents>\Plugins\Menu-Launch           (menu-launch items subfolders go here)
• <LabVIEW Public Documents>\Plugins\Menu-Launch\File      (File>> menu-launch items)
• <LabVIEW Public Documents>\Plugins\Menu-Launch\Help      (Help>> menu-launch items and help documentation)
• <LabVIEW Public Documents>\Plugins\Menu-Launch\Tools     (Tools>> menu-launch items)
• <LabVIEW Public Documents>\Plugins\Menu-Launch\Edit      (Edit>> menu-launch items)
• <LabVIEW Public Documents>\Plugins\Menu-Launch\Window    (Window>> menu-launch items)
• <LabVIEW Public Documents>\Plugins\Menu-Launch\Browse    (Browse>> menu-launch items)
• <LabVIEW Public Documents>\Plugins\Call-backs            (all of the call-back items that are currently in the LabVIEW/resource/plugins folder)
• Others?

And, here are some specific questions:

• What will the new Plugins subfolder structure look like?
  
• Are we still going to be able to add items to the File>> and Help>> menus?
• Will there be support for adding items to the other menus (like Edit>>, Window>>, Browse>>)?
  
• Where should we install help documentation that is included with our toolkits?
• Will the current LabVIEW/resource/plugins scheme (which can contain call-backs for some built-in LabVIEW functionality like start-up, new VI, etc.) be exposed in the new Plugins scheme?

Thanks,

-Jim

[AristosQueue]

> I would suggest structuring the Plugins folder like the
> following (with support for adding items to all the menus):

Although the concept of allowing plugging for all the menus is a good suggestion, I've got reservations about the particular proposed implementation.  The suggested approach it ties us to the existing menu structure. LV has in the past moved the top-level menus around rather significantly. I've seen graphics packages gradually move many of their menu items into separate toolbars. Microsoft has changed their Office suite to the new ribbon system and largely done away with the menus, and LV might someday choose to follow their lead. All sorts of things could happen like that.

By defining particular directories for particular menus, then if we someday had a new menu structure, all the existing installers would have to be scrapped in favor of a new set of installers that used the new directory structure.

Rather than having a directory structure that controls which menu things get installed into, perhaps some method of tagging VIs could be used. Then installers dump the VIs into the "plugins" directory and LV interprets where they go based on the meta information. I don't have any particulars about the type of tagging used. Some suggestions: some naming convention for the VIs, a text file that installs along side the VIs, or actual flags saved with the VI through some tool that NI would release.

In this way, if LV did change its structure, older toolkit installers could continue to install into more recent LV versions, and LV would route particular tags to particular menus (or button bars or whatever) in whatever fashion it chose.

We sort of made a mistake along these lines once before, which is why you installed into the "Project" directory to put things in the "Tools" menu. :-)



Message Edited by Aristos Queue on 03-10-2008 06:12 PM

[Jim_Kring]

> Rather than having a directory structure that controls which menu things get installed into, perhaps some method of tagging VIs could be used.

I would prefer that, too.  Maybe there should be one subfolder for each plugin and inside it could be some manifest (perhaps an xml file) that describes what it is and how it should appear in LabVIEW.  We would need to define the different types of plug-ins and thier corresponding manifest parameters.  Each plugin should have a unique name, but that hasn't been a problem for plug-ins, in the past.

[jdunham]

In http://zone.ni.com/devzone/cda/tut/p/id/6926 -> Proposed Directories -> Usage

it says

Default Data Directory

N/A

Per-user directory for version-independent files containing program output data (e.g., LVM files).

However the section above says

Default Data Directory

C:\Program Files\National Instruments\LabVIEW <ver>

This seems like an edting mistake.  I don't think you should create per-user directories in c:\PF\NI\LV, nor store any program output there.  Based on the other stuff I am reading, you don't think so either.

[Noel]

I'll respond re: the plugins directory later.  Right now I'd like to comment on the "Default Data Directory" and "Default Directory".  These are two separate file constants.  I have two mistakes in the tables -- I mistakenly called the "Default Data Directory" the "LabVIEW Data Directory".  I also mistakenly call the "Default Directory" the "Default Data Directory" in one of the tables.  Yikes!  I'll fix this tomorrow in the published document.

Part of the reason I'm suggesting we get rid of one (the Default Directory), is because it is easy to confuse the two....

The original intended use of the "Default Data Directory" is the default save location for the output of Express VIs like the Write to Measurement File VI.  I still believe that for the Express user, that we should have a default save location and it should be under the User's directory.  Hence, I'm proposing we keep the "Default Data Directory".   

On the other hand, the "Default Directory" has all sorts of problems.   As pointed out, User files should never be written to the Program Files directory.  So, the current description and current disk location are at odds with future plans to disperse files to directories based on user access. So, I suggest deprecating the "Default Directory" constant.

Thanks for catching the mistake.

- Noel

[Jim_Kring]

Hi Noel,

Please let us know when the published document has been updated.  I'd like to re-read it in its correct form.

Thanks,

-Jim

[jdunham]

---

Noel wrote:

The original intended use of the "Default Data Directory" is the default save location for the output of Express VIs like the Write to Measurement File VI.  I still believe that for the Express user, that we should have a default save location and it should be under the User's directory.  Hence, I'm proposing we keep the "Default Data Directory".   

On the other hand, the "Default Directory" has all sorts of problems.   As pointed out, User files should never be written to the Program Files directory.  So, the current description and current disk location are at odds with future plans to disperse files to directories based on user access. So, I suggest deprecating the "Default Directory" constant.

Thanks for catching the mistake.

- Noel

---

I am in total agreement on this.  Labview's default data directory has always been problematic, and I am glad you are taking this on.  I think it's fine if you deprecate a folder, but I'm not sure why it would be included as an option in your new API.


One thing which I didn't really see clearly in the goals, is the idea to encourage LabVIEW programmers to store code in different a different folder from data.  LabVIEW has been particularly terrible about this, since the file dialog box shares the same start folder when saving Vis and when presenting a file dialog box initiated by block diagram code. I don't know if your scope of work can fix this, but you are fighting an uphill battle with your folder names if they are not obeyed by the internal LabVIEW dialog boxes.

[Noel]

The LabVIEW Directory Changes document has been updated to correct my typos regarding the "Default Data Directory" and the "Default Directory".   Note:  I've also added a few more links between the document and the forum questions. 

The reason that these two directory constants need to be discussed as part of this overall LabVIEW directory change game plan is because both return paths that relate to the current LabVIEW usage.  And, hence, people want to know how these path constants are impacted.

Just to be 100% clear....

After the directory reorganization, the intent is for the Default  Data Directory ( User Documents/LabVIEW Data) to be the default location for data files like .lvm files.   The plan is for features that currently use this directory for application files, such as Auto Save, Error Logs, etc -- to move their files to a version-specific directory under the User Application Data directory. 

As far as the Default Directory which, on Windows, returns the same path as App.Dir property -- should be deprecated.   As far as I'm concerned, there is no good reason for its continued existance except to support backward compatibility for someone who probably doesn't realize there are better choices that are self-documenting.

Sorry for the confusion.

- Noel

[jdunham]

---

Noel wrote:

The reason that these two directory constants need to be discussed as part of this overall LabVIEW directory change game plan is because both return paths that relate to the current LabVIEW usage.  And, hence, people want to know how these path constants are impacted.

...

As far as I'm concerned, there is no good reason for its continued existance except to support backward compatibility for someone who probably doesn't realize there are better choices that are self-documenting.

---

Right, but LV will still be supporting the old primitives which returned those paths (for compatibility).  I'm suggesting you don't allow the new directory API to return those paths, so that no one is tempted to keep using them in new code.

---

Noel wrote: 

After the directory reorganization, the intent is for the Default  Data Directory ( User Documents/LabVIEW Data) to be the default location for data files like .lvm files.   The plan is for features that currently use this directory for application files, such as Auto Save, Error Logs, etc -- to move their files to a version-specific directory under the User Application Data directory. 

---

So did you understand what I was getting at? 
The current behavior of LabVIEW can be illustrated with the following steps.

1. Make a new VI, and drop Write to Text File on the diagram, with some ordinary text input.
2. Save the VI somewhere.
3. Run the VI.  The file dialog box will start in the same folder where you saved the VI.  (I think this is just terrible)
4. Save the text file in some other folder
5. Create a new VI
6. Save the new VI.  The "Name the VI" file dialog box will start in the same folder where you saved the text file (I think this is just terrible).

Most new programmers and new users just use the folders LV suggests, so they tend to store their data and source code in the same folders, which I think is terrible.  My point is that you can make this API which is nifty, but since most people just use the dialog boxes, you are not going to get 'correct' behavior unless you fix the file dialog start path at the same time.

When I say "most people" etc.  I mean that as a consultant I have seen many different labview programs by many people, and it is somewhat rare for novice programmers to wire in a path at all (if wired, it's almost always a path constant, which I'm sure you've noticed too).