10 replies to this topic

[David_L]

Hey all,

As you may know in order to have a toolkit placed on the LabVIEW Tools Network it has to pass Compatible With LabVIEW certification. One of the requirements for the Compatible With LabVIEW program is that tools may not be located on the top palette, but should exist within one of the existing top-level categories such as Programming, Measurement I/O, Data Communication, etc.

The reason behind this requirement is that the LabVIEW Palette can get quite bloated when you have many toolkits/modules installed. With just the full Developer Suite installed, there are over 20 top level palettes. Adding third party tools to this list will very easily bring the functions palette to grow off of the screen for a standard 1024x768 monitor. The secondary reason behind this is that this layout will help users find the functions more easy that will help them. For example if the user is looking for some data communication protocol, they are more likely to look in the "Data Communication" palette then in a sub-palette called "My Data Protocol" under a top level "DavidSoft Inc".

I wanted to point this out so as you all start creating their toolkit for submission to Team LAVA or the LabVIEW Tools Network, you can take this into consideration ahead of time. However, with many things in our program, nothing is black and white. If there are special cases in which a toolkit especially should be on the top level, we will consider letting it go as such. One of these cases is OpenG. Since OpenG has a long-standing reputation and is known to be found on the Top level, it would be more hurtful than beneficial to require it moved to the Programming palette.

If anyone has suggestions or ideas of other corner cases that would benefit from this top level location, or have comments or opinions for or against this policy, please feel free to bring them up here for debate/discussion.

--David Out

[jgcode]

Thanks for the information David.
I will update the Team LAVA requirements in the near future to be inline with these requirements.
I like the idea of grouping all toolkits under the one LAVA palette as (from looking at the LAVA-CR) a lot of submissions are unique.
If a developers has a package that fits a NI palette then it should go under that palette (providing we have access of course).
However, I would still like that palette under the LAVA palette as well, so I can find everything in the one spot.

What do others think?

[Roderic]

IMO, it would be best to have the toolkits under the palette that fits. I mean its easier to have all the communication functions under the same palette right? But, I understand it would be nice to have all the LAVA tools under the same palette from a "marketing" point of view. So both ideas make sense to me.

[ShaunR]

Well. there is an "Addons" palette. So shouldn't "Addons" be in there? I know your post is against top level folders but I also don't prefer bunching other tools in the labview installed locations as I prefer separation between the standard labview installed software and addons/toolkits.

It's already a case that we have to drill down 3 or 4 layers of folders to find (for example) the TCPIP vis. It is that that causes menus to roam across the screen rather than having them further up the hierarchy. There is (as I have mentioned) the addons folder. There is also the User Libraries and Favourites on the top level which rarely have much in them...if anything. Better use of the top level palette folders would make more sense. But we are being told that we shouldn't use the User Libraries folder?

[rdr]

User.lib is really intended for customers to store their own code re-use libraries and add-ons/toolkits for LabVIEW should really move to either Addons or one of the other existing palette categories. As for usability, I find it easier to locate related palettes in the same category over having multiple large top-level palette sets, and with some common branding on the palette icons one could clearly identify a subpalette as being part of a suite of libraries like OpenG, LAVA, MGI, etc. However, with the case of OpenG I have gotten used to first looking in the palette/category where I expect to find a function before looking in the OpenG palette, and this has not been frustrating at all...

-Bob (the other David_L)

[GregSands]

Some years back, the OpenG palettes were scattered through the categories - OpenG Array routines under Programming/Array and so on - rather than collected under a top-level category. I think that was incompatible with some new version of LabVIEW, so everything changed to the top-level OpenG palettes. I'm with Bob on this - if I'm looking for an array function, I don't care whether it's OpenG or MGI or whatever, I really want to look in just one place for it. Quick Drop makes this somewhat easier (there's no connection to any palette here) but it's not so usable for browsing for a half-forgotten routine that you're pretty sure someone had written somewhere...

[David_L]

Greg - Your description exactly reflects the reason we want developers placing palettes under the existing top-level palette. As you mentioned, you can't place them inside lower level palettes, but at least the top level is a start. Perhaps we could get some momentum on the idea exchange for allowing palettes to be placed under the lower level palettes (i.e. arrays, timing, etc). I'll post an idea for this and update this thread when I do so.

[David_L]

Idea-ified

[Michael Aivaliotis]

I would like to see both allowed actually. Why not?. Allow top level categories and palettes within the correct programming sub-palette. People access functions in different ways.

A different long-term solution would allow me (as a user) to quickly switch the palette into different views depending on what I'm interested in. I would like to see a Company view for example.

[jgcode]

Perhaps we could get some momentum on the idea exchange for allowing palettes to be placed under the lower level palettes (i.e. arrays, timing, etc). I'll post an idea for this and update this thread when I do so.

OpenG used to support this functionality (by recreating all the NI palettes I believe?)
This was something I posted to JKI last year as a feature for VIPM however, I understand it is a limitation of LabVIEW palettes.
So, I am all for this Idea happening!!

[rolfk]

OpenG used to support this functionality (by recreating all the NI palettes I believe?)
This was something I posted to JKI last year as a feature for VIPM however, I understand it is a limitation of LabVIEW palettes.
So, I am all for this Idea happening!!

Originally OpenG VIs were located under the OpenG palette only. Then, I believe Jim, figured out the Dynamic palette feature and the OpenG VIs were also added to the respective subcategories. However this dynamic palette feature was quite bristle as it didn't seem to be a designed feature and NI broke it in later versions somehow.