LabVIEW Developers Feature Brainstorming

[jdunham]

LabVIEW User Documents Directory

C:\Documents and Settings\<user>\My Documents\National Instruments\LabVIEW <ver>

Default Data Directory

C:\Documents and Settings\<user>\My Documents\LabVIEW

So these two folders are almost identical, except for "National Instruments" in one.  From the document (Proposed changes to the LabVIEW directory structure) it seems like the former is for code, and the latter is for data.  I've been pushing for different locations, but I don't think this is quite the right answer.

Maybe the Default Data Directory should be "C:\Documents and Settings\<user>\My Documents\LabVIEW Data".

I would also be in favor of removing "National Instruments from the LabVIEW User Documents Directory.  I think it's appropriate for the two Application Data folders (where users don't change much, and a lot of applications add other folders, but it just adds more indirection into the User Documents folder where we should be keeping files that we edit and copy and back up etc. all the time.

[Daklu]

I don't really like the idea of having so much data data dumped in the Documents directories.  I am probably in the minority but I view My Documents as My space, not yours.  (Not 'yours' as in you specifically, but a general 'you' applied to application developers.)  That's where I organize my work to suit my style.  It irritates me when applications decide to pollute my work area.  Right now ~50% of the folders in My Documents are items I neither put there nor want there.

Furthermore, if items are put in a Documents folder, they should be items I am likely to access through the start menu.  I don't know about others but not once have I needed to get into a ..\Labview Data\persistence data\Local Connection\xxx.dat file.  If I'm interested in examples or a specific device driver I'll start up Labview and navigate from there rather than launching through the explorer shell.  The only time I use the shell to launch directly into a vi is when I'm working on one of a handful of current projects.  In those cases I typically move the project into My Documents while I'm working on it.  When I'm done I send it away.  Everything stays neat and tidy--just how I like it.

</rant>

I realize I can be pretty ana... um... particular... about my directory setup.  I also realize much of this might be imposed on you by Microsoft and other OS vendors.  Having a bunch of device drivers lurking in my Documents folder would really burn my buttonholes.

I do have two comments regarding the proposed enums for the System Directory.vi.  (Hopefully these are a little more constructive.)  It would be nice to have a tooltip indicating where these constants are actually directed.  I've been using computers actively since the C-64 (just a pup... I know) and I admit I didn't know what directories the User Home or User Preferences referred to until I read it.  I also think it is important to include easily accessable instructions on what each directory should be used for.  (Read "easily accessable" as "in the linked help file," not "buried in documents on the NI webserver."  )

[Noel]

Sigh...

I didn't proof-read the Default Data Directory entry in my table very well.   You caught another typo --  As I tried to mention earlier, there are no plans to change the disk location associated with the Default Data Directory.   The current location on Windows XP is :

C:\Documents and Settings\<user>\My Documents\LabVIEW Data.  

The only planned change related to this directory is that application data will be moved out (e.g., autosave, dependencies, error logs, etc.). 

While this is still similar to the proposed LabVIEW User Documents directory, there are some key differences I'd like to point out.  Just to be clear, on XP the location will be:

C:\Documents and Settings\<user>\My Documents\National Instruments\LabVIEW <ver>

The LabVIEW User Documents directory is version-specific while the Default Data Directory is not.  Therefore, each LabVIEW version will have their own set of directories to look for version-specific files.   

As for inserting National Instruments in the path...well this is primarily to ensure consistency with other NI products.   This need for a updated directory strucutre is not limited to LabVIEW.  All NI software is transitioning to a dispersed directory structure.   I empathize with those of you who don't like your applications putting files into your User directory hierarchy -- but if an application does save files, you'd probably prefer they be consolidated under a single company directory. 

The reason the LabVIEW Data Directory isn't under National Instruments is because it is shared by multiple versions of LabVIEW.   For future versions of LabVIEW, we could move the locations to be under National Instruments too -- but if you have (had) previous versions of LabVIEW on your system, you'd probably have two "LabVIEW Data" directories that you could easily confuse.   Furthermore, since this is the default location for .lvm files -- there might be some compatibility issues for Express users.

Which brings me to a few ideas to throw out....

a)  It might be possible to introduce a redirect mechanism such that you can redirect some of these LabVIEW paths to somewhere else on your system.   Would this be beneficial?

b)  Would you prefer that the LabVIEW Data directory move to be under the "National Instruments" directory tree? 

Daklu -- that is a great suggestion about the tip strips.  We'll need to look into how that can be implemented since you can redirect some of your system directories so that even on a single platform the tip strip would need to be dynamic.   But -- certainly some sort of quick reference would be beneficial. 

A few other notes:

a)  I still plan to mock up some directories and post.   Just got a bit busy these past few days.

b)  Because of my various typos, I've created a "revision history" at the bottom of the LabVIEW Directory Changes document.  I'll note any future changes in the revision history table.   If there is a need to update the System Directory API document, I'll create one there too.

c)  There are a few other posts I plan on responding to, but not tonight.

Keep the ideas coming!

- Noel

[Noel]

After my last post, I realized there was a more compelling reason why the Default Data Directory should NOT be under a "National Instruments" folder.   The Default Data Directory constant is valid for both the development environment and the runtime engine.   Although customers can choose not to use the Default Data Directory in their built applications, for those that already do use it -- they probably don't want the location to be under a "National Instruments" folder. 

API access to the new version-specific LabVIEW directories, on the other hand, should be limited to use within the LabVIEW development environment and not for use with the runtime engine. The intended uses for the various version-specific directories are very ADE-specific.  Furthermore, the ADE does not exist on most machines with deployed applications.

- Noel

[Kevin_Price]

---

a)  It might be possible to introduce a redirect mechanism such that you can redirect some of these LabVIEW paths to somewhere else on your system.   Would this be beneficial?

b)  Would you prefer that the LabVIEW Data directory move to be under the "National Instruments" directory tree? 

a. Yes, PLEASE PLEASE provide a redirect mechanism to shift some of those LabVIEW paths.  I'm a cranky old DOS user who just HATES the way modern apps insist on dribbling my files where THEY want to instead of asking me where I want them.  And I personally NEVER want them in the Windows default My Documents or Documents and Settings hierarchies.  Something about the Microsoft nomenclature of "My this, My that" has always rubbed me the wrong way -- it just seems so irritatingly condescending.  Would you ever label a sock drawer "My Socks" unless it was for a 5-year old?  But, ahem, I digress...

   Some apps, though not all, provide config settings that let me redefine the default directories.  Please let LabVIEW provide such settings in a convenient way, such as via the Tools-->Options menu.

   In my opinion, it should further be possible to define a default data directory that associates to a LabVIEW executable being built, perhaps as part of the executable's ini file.

b. I'd have said no anyway, but it appears you already found your own better reasons to reject this.

-Kevin P.

[AristosQueue]

> Something about the Microsoft nomenclature of "My this,
> My that" has always rubbed me the wrong way

In my case, I've always been bugged by the implication that the rest of my harddrive belongs to Microsoft. ;-)

[Noel]

Jim:  I have a mocked up directory -- I'm just trying to figure out best way to post it.   I'm considering a .doc attachment but want to think about options before I blindly post.

Kevin/Aristos:  Your posts about "My Documents" and Microsoft owning the directory structure made me LOL.   I think Microsoft learned their lesson as Vista no longer uses the "My xx" directory names. 

Jason:  I understand your point about using File dialogs and their need to be aware of the context in which they are invoked.   I'm not sure how much we can bite off as part of this directory change initiative.  Certainly we need to facilitate access to the new directories.   As I understand it, LabVIEW has around 80 different permutations of our File dialog.  The complexity increases when you consider we support both Native file dialogs (Mac/Windows and a LabVIEW dialog (all platforms).   Considering that Vista's native dialog differs in look,feel, and implementation from the XP dialog, I shy away from customizations to the Native dialogs as the answer.  So, below are some things we brainstormed on to help facilitate access to new directories:

a)  Update the LabVIEW dialog to include pre-populated links to the new LabVIEW directory structures.

b)  Add support for the native Vista File dialog.  The Vista dialog allows quick access to the Public directory.  It is also easily customizable by users to add their own quick links (much easier than XP).

c)  If possible, LabVIEW can prepopulate the quick links in the various Native File dialogs.  This might not be supported on all platforms.  Plus, the quick links aren't specific to a single application.  I'm not sure that users would want LabVIEW adding quick links to File dialogs that are used in, say MS Word.

d)  Expand our file browsing capabilties in LabVIEW by adding stratigic "Explore" options in the VI Properties dialog, right-mouse click options on VI and subVI icons, etc, so users can quickly get to their VI and file directories.

Other ideas?

- Noel

[jdunham]

---

Noel wrote:

After my last post, I realized there was a more compelling reason why the Default Data Directory should NOT be under a "National Instruments" folder.   The Default Data Directory constant is valid for both the development environment and the runtime engine.   Although customers can choose not to use the Default Data Directory in their built applications, for those that already do use it -- they probably don't want the location to be under a "National Instruments" folder. 

API access to the new version-specific LabVIEW directories, on the other hand, should be limited to use within the LabVIEW development environment and not for use with the runtime engine. The intended uses for the various version-specific directories are very ADE-specific.  Furthermore, the ADE does not exist on most machines with deployed applications.

---

Well this opens a bit of LabVIEW dichotomy.  For me, LabVIEW is a development environment.  I write programs, and most of them get built and distributed.  I would probably never use an API call for "LabVIEW directories", but rather always prefer the "System Directories", even if I don't end up building the application.  I realize that some other of your customers may thing of LabVIEW as an end-user application, which they use to take measurements.  They don't have the slightest interest in letting other people use their apps, and they may be more inclined to share data with other NI tools.  I compare LV to Visual Studio, whereas the other type would compare LV to Matlab or MS-Word.

Don't listen to me when adding features to benefit the latter customer, because I don't know and I don't care.  However, I feel that LabVIEW development has often neglected the developer in favor of the end-user and I hope you are seeing the difference and catering to both camps as fairly as possible. 

Specifically I was disappointed not to get any relevant response to the earlier post where I hope that more effort is made to separate the storage of code and data (which may be irrelevant to the end user but is vitally important for the developer).  I just think it is awful to have the file dialog prompt for saving vis start in the same folder as you last saved some data.  Having an API for getting folders is nice, but not as useful if the development environment doesn't itself follow good practices.

Edit: I see that Noel addressed my point just a few minutes ago.

Message Edited by jdunham on 03-18-2008 01:59 PM

[jdunham]

---

Noel wrote:

Jason:  I understand your point about using File dialogs and their need to be aware of the context in which they are invoked.   I'm not sure how much we can bite off as part of this directory change initiative.  Certainly we need to facilitate access to the new directories.   As I understand it, LabVIEW has around 80 different permutations of our File dialog.  The complexity increases when you consider we support both Native file dialogs (Mac/Windows and a LabVIEW dialog (all platforms).   Considering that Vista's native dialog differs in look,feel, and implementation from the XP dialog, I shy away from customizations to the Native dialogs as the answer. 

---

Well since every other program I use on windows seems to get this right, and LabVIEW does not, so I don't think you can blame this on the Vista API.  In Word, if you insert a picture into your document, the dialog box starts in "My Pictures".  If you insert a picture from another location, it remembers that location next time you want to load another picture, but when you want to open another Word document, it starts in your document location, not in your latest picture location.

If LabVIEW could do the same thing, then the world would be a better place.

All LabVIEW has to do (as far as I can tell) is store two separate starting folders in the registry, one for code, and one for data, and use them at the appropriate times.  I just can't imagine this is difficult.

If you really wanted to make life easier for me, you would store the starting directory for code with the project, so that LabVIEW wouldn't constantly encourage me to cross link my code when working with multiple projects.  However, I know this is just too much to hope for.

I'm sorry to hijack your thread, but I will bring it back to relevance by repeating that a new API doesn't do much good if LabVIEW itself doesn't follow similar practices.

[Noel]

OK, I took a crack at mocking up the directory structure for both the Plugins directories and Addon Libraries directories.  I'm sure you'll be able to throw some tomatoes at it. 

To answer some of Jim's specific questions:

What will the new Plugins subfolder structure look like? 
See attachment.

Are we still going to be able to add items to the File>> and Help>> menus?  
Yes.   See my notes/questions re: Help files in attachment.

Will there be support for adding items to the other menus (like Edit>>, Window>>, Browse>>)?   
Ideally, yes.  I've passed on your feedback to the owning developer.   I've also passed on the various suggestions re: a possible directory structure for menu plugins.

Where should we install help documentation that is included with our toolkits? 
Again, see my notes/questions re: Help files in attachment.   I personally would like to see toolkits be able to group help files with other toolkit files.   This would make it easy to grab items from your source code control depot, unzip files, etc.

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?  
In my mind, any plugin that is already documented in the help is a "must have" to continue support with the new directories.   For plugin features that are undocumented, we need to hear from you as to your expectations and interests (e.g., customizing the getting started window).   These can be provided on a priority basis.  For plugin features that are not open to the public (i.e., require internal code modifications), such as the Tools>>Options page, these will likely NOT move to the new directory structure until they are implemented such that users can plug into them without internal code modifications.

Looking forward to your continued feedback and ideas.

- Noel