G Idea Exchange

Community Browser
cancel
Showing results for 
Search instead for 
Did you mean: 
Guidelines for posting ideas

On behalf of the G Idea Exchange and GCentral, thanks for considering posting an idea for discussion. Here are a few guidelines to think about before posting the idea. 

Does the idea already exist in the community or on VIPM?

The effort of creating two competing ideas is usually not worth the time but is better spent to improve the existing idea with the functionality. If your idea differs significantly from the existing solution then write that in the idea post.

Is the Idea a request for a new LabVIEW primitive?

If the idea requires new LabVIEW primitives, the idea belongs on the LabVIEW idea exchange instead of here. 

Will your idea improve the productivity of everyone in the community?

It is important that other developers can see that the idea is something that they would vote for. Sometimes an idea is specific to a particular problem in your current project, which would be great if there was a solution, but it is hard to see the reusability of the idea.

Would you be willing to release the result of your idea under a permissive open-source software license?

In order for your idea to be used by others it would have to be released under a permissive open-source license, defining the rights of usage. The G Idea exchange can only support and possibly fund ideas that will be released as open-source. 

Discussions about an idea.

When you post an idea on this board it is open to discussion, and improvement by the community, and other developers can join in and ask questions about the idea. Consider these questions as sources for expansion and improvement of the idea rather than critique. When commenting on or discussing an idea please keep a respectful tone.

Best regards

The GCentral Idea Exchange

Post an idea
antsundq

Description
To cite Sam Taggart: "A good refactoring suite for LabVIEW is desperately needed. IMO the worst offenders are classes/interfaces", taking the words out of my mouth. 
 
Good tooling for automated refactoring can speed up development and reduce risk of making mistakes. By automating tedious tasks the developer may focus on design over housekeeping. Most other languages have good tools for refactoring through various IDE:s, and there is not really any reason we could not have that as well.
 
I'm sure there are a lot of tools out there I am not aware of, which could be leveraged. I think the right tools should be collected or developed, to be put into a suite of high quality refactoring tools.

Submitter
Anton Sundqvist
 
LabVIEW Compatibility
LabVIEW 2020 (first version supporting interfaces)
 
How would the user interact with this tool?
Through suitable LabVIEW project integration.

Distribution Method
VI Package (.vip)

Development Target Cost
$?

Other Notes
I'm happy to work on this myself together with whomever wants to contribute. I think we need some community guidance and suggestions for what tools are needed and how they should be implemented in LabVIEW. The purpose of this post is to gauge the interest within the community and gather ideas. 
I'll start with a few tools I would like to see, let's see if we can get it rolling:
- Extract interface from class
- Override and save all must override VI:s
- Generate constructors/destructors (not that they are strictly needed, but they are useful for communicating intent. Using them by convention makes it easier to locate each place a class is instantiated, compared to block-dropping)

Schliepe

Description
This would be a tool that is used to gather information about the licensing of dependencies in a project, specifically the open source attributions. The output would be a file with all of the dependencies and licenses and attribution statements that could be included as a readme or other appropriate file to comply with the requirements of the licenses.  In particular for deployed executables where some licenses require the inclusion of the open source license or attribution in deployed code. 
 
Really the idea is to make it easier to roll these up.  So I would see this being a developer tool that would create a text file that could be added to the build spec. 

Submitter
Erich Schlieper
 
LabVIEW Compatibility
The earlier the better.
 
How would the user interact with this tool?
Through suitable LabVIEW project integration.

Distribution Method
VI Package (.vip)

Development Target Cost
$?

Other Notes
 

JKSoerensen

Description
With hundreds or thousands of classes loaded, the LabVIEW class inheritance dialog can be very cumbersome to navigate. This utility would provide an alternate dialog for modifying a class' inheritance. The main enhancement would be the ability to filter classes by name (e.g. entering "hardware" would only show classes who have "Hardware" in the name) so that navigating to the class you intend would be easier.
Submitter
Thomas Robertson
LabVIEW Compatibility
The older the better
How would the user interact with this tool?
Right-click menu on class in project that opens a new inheritance dialog.
Distribution Method
VI Package (.vip)
Development Target Cost
$?

Other Notes

JKSoerensen

Description

Bowzer already allows you to view the payload methods associated with an actor's supported Messages. This update would also allow developers to browse the dynamic dispatch methods included with EVERY Actor:

  • Actor Core

  • Handle Error

  • Handle Last Ack Core

  • Receive Message

  • Pre Launch Init

  • Stop Core

  • Substitute Actor

  • Uninit (new in LV2022)

Developer

CaseyM

 

LabVIEW Compatibility
Should be compatible with LV2020

 

How would the user interact with this tool?

This would be an extension to Bowzer the Browser from Zyah Solutions

Distribution Method

VI Package

Development Target Cost
$400

 

Other Notes
Essential Features
This is an enhancement to an already existing utility, so everything listed in the description would need to be implemented.