G Interfaces for LabVIEW 2020

[Aristos Queue]

LabVIEW Community Edition 2020 is now available for download. The commercial edition will follow sometime in May. We prioritized the Community release for all the engineers stuck at home under quarantine.

LabVIEW 2020 introduces interfaces as a companion feature to LabVIEW classes. I and Allen Smith will be presenting what would have been our NIWeek presentations as a webcast this Friday.

Two topics, one time:
Intro to Interfaces (Stephen Loftus-Mercer)
Interfaces and the Actor Framework (Allen Smith)

Friday, May 1 10am, CDT
Join here (Microsoft Teams required): LabVIEW 2020: G Interfaces

[EDIT] The same link above will let you watch the recording for the next 90 days. After that, NI will find some place to more permanently host the video.

Youtube Link

If you have any follow up questions, Allen and I are both monitoring a specific forum thread on ni.com for this presentation for the next couple weeks.

To start learning about interfaces today, please see

• the Fundamentals>>LabVIEW Object-Oriented Programming section of the LabVIEW 2020 shipping documentation
• the shipping examples in
  examples\Object-Oriented Programming\Basic Interfaces
  examples\Object-Oriented Programming\Actors and Interfaces

If you are someone who already knows about interfaces from other programming languages and want to understand why G interfaces work the way they do, you may be interested in reading LabVIEW Interfaces: The Decisions Behind the Design.

[Ansible]

Excellent, can't wait to see it.  

[JKSH]

8 hours ago, Aristos Queue said:

Friday, May 1 10am, CDT
Join here (Microsoft Teams required): LabVIEW 2020: G Interfaces

Thanks, @Aristos Queue! I'll be tuning in.

Quick note about branding: The event title is currently "Intro to G Interfaces in LabView 2020" (I peeked at the event on Microsoft Teams)

[crossrulz]

Will this be recorded?  I will attempt to attend, but have appointment that will likely cover the first half.

[Aristos Queue]

17 hours ago, JKSH said:

The event title is currently "Intro to G Interfaces in LabView 2020" (I peeked at the event on Microsoft Teams)

Had IT team fix that. Thanks.

[Aristos Queue]

4 hours ago, crossrulz said:

Will this be recorded?  I will attempt to attend, but have appointment that will likely cover the first half.

The plan is to record it. Lots of new technology involved in this, so fingers crossed.

[Aristos Queue]

I added notes on follow-up questions and getting the video recording to the original post above. 

[Michael Aivaliotis]

It would be great to have a project menu item, goto parent interface:

[Mike Le]

1 hour ago, Michael Aivaliotis said:

It would be great to have a project menu item, goto parent interface:

How would this work if a class has multiple interfaces? Maybe instead of a right-click menu option, some kind of visualizer that only shows the class's interfaces?

Edited May 1, 2020 by Mike Le

[Michael Aivaliotis]

3 minutes ago, Mike Le said:

How would this work if a class has multiple interfaces? Maybe instead of a right-click menu option, some kind of visualizer that only shows the class's interfaces?

Maybe a fly-out menu.

[Michael Aivaliotis]

As a side-note. In 2020, NI changed the "change inheritance" dialog to "change parent class". Most likely due to interface nomenclature. But this triggered a thought in my head. Why can't we get this class relationship view inside the project tree? It seems useful.

 

[0_o]

I've been waiting for this since graduating my CS degree in 2005.

Thanks!

[Aristos Queue]

16 hours ago, Michael Aivaliotis said:

Why can't we get this class relationship view inside the project tree? It seems useful.

The project tree is an all-files view. Not every file is a member of a class. There are VIs in libraries, loose VIs, non-LabVIEW files (like readme.txt). We talked about a class view in project back at start of LVOOP project and repeatedly since then, and we repeatedly decided the project window was the wrong place for that. That is the reason the LabVIEW Class Hierarchy window exists. 
 

For a better view overall, checkout OpenGDS or NI-GDS toolkits (although neither is updated for interfaces at this time).

[Aristos Queue]

17 hours ago, Michael Aivaliotis said:

It would be great to have a project menu item, goto parent interface:

16 hours ago, Mike Le said:

How would this work if a class has multiple interfaces? Maybe instead of a right-click menu option, some kind of visualizer that only shows the class's interfaces?

 

Wouldn’t be “Go To...” it would be in the project item’s Find menu with Find>>Callers. Like all of those, Find>>Parent Interfaces would jump directly if there was only one and pull up a results list if multiple. 
 

We had it on the proposed task list and cut it out of this release. It goes in the iteration bin to compete with other priorities. 

[Michael Aivaliotis]

11 hours ago, Aristos Queue said:

Wouldn’t be “Go To...” it would be in the project item’s Find menu with Find>>Callers. Like all of those, Find>>Parent Interfaces would jump directly if there was only one and pull up a results list if multiple.

That works.

11 hours ago, Aristos Queue said:

The project tree is an all-files view. Not every file is a member of a class. There are VIs in libraries, loose VIs, non-LabVIEW files (like readme.txt). We talked about a class view in project back at start of LVOOP project and repeatedly since then, and we repeatedly decided the project window was the wrong place for that. That is the reason the LabVIEW Class Hierarchy window exists.

Ya, I get it. But a new view wouldn't hurt for those passionate OOP users. Similar to the Files tab, you could have a Class tab.

[Rolf Kalbermatter]

On 5/2/2020 at 4:57 PM, Aristos Queue said:

The project tree is an all-files view. Not every file is a member of a class. There are VIs in libraries, loose VIs, non-LabVIEW files (like readme.txt). We talked about a class view in project back at start of LVOOP project and repeatedly since then, and we repeatedly decided the project window was the wrong place for that. That is the reason the LabVIEW Class Hierarchy window exists. 
 

For a better view overall, checkout OpenGDS or NI-GDS toolkits (although neither is updated for interfaces at this time).

Well, it would be along the line of Visual Studio then. There you have the sub-view, typically located on the left top side with the Solution Explorer, Class View and Resource View tabs (all configurable of course so it may look different in your installation, but this is the default setup.) 

It's not like you can't claim that the LabVIEW project window drew quite a bit of inspiration from that Solution Explorer window in Visual Studio. 😃

[Aristos Queue]

On 12/14/2020 at 3:31 AM, Rolf Kalbermatter said:

Well, it would be along the line of Visual Studio then. There you have the sub-view, typically located on the left top side with the Solution Explorer, Class View and Resource View tabs (all configurable of course so it may look different in your installation, but this is the default setup.) 

It's not like you can't claim that the LabVIEW project window drew quite a bit of inspiration from that Solution Explorer window in Visual Studio. 😃

What you’re asking for is the dockable panels that NXG had. NXG was able to use more of that VS pattern. But LabVIEW doesn’t have the same setup. A class tree isn’t another view of the project tree — where do you put all the VIs and libraries that aren’t part of a class?

[Rolf Kalbermatter]

On 12/22/2020 at 4:42 AM, Aristos Queue said:

A class tree isn’t another view of the project tree — where do you put all the VIs and libraries that aren’t part of a class?

To be honest, I would probably not put them anywhere in that view. It’s called Class View for a reason. 😀

It hadn’t really occurred to me that you would want to have the non-class VIs visible in there. Is that a flaw or just out of the box thinking?

[Neil Pate]

Ditto to what Rolf said.

[Aristos Queue]

It’s a project window, not an arbitrary information pane window. And while we could make it an arbitrary info window, there are usability issues with that. VS doesn’t create a single window/pane with various modes. It has many panes that can be rearranged as different dockers or windows. As a project window, it should provide different views on the whole project, not one aspect of the project. 

It is software — we *can* do anything. But various UX reviews suggest this particular approach would be a less-than-ideal solution. Is the downside worth the gain? Our answer up to now has been, “No, don’t introduce a bad hack, just wait and do it right in NXG.”

A variation that is in line with UI design expectations would be a splitter bar in the window that has the project pane above and the class pane below. The project pane would still have two views (virtual and files). Or a completely separate window. Or introducing a docking/undocking system. Any of those are things that would be more likely to fly. Do any of those appeal? Obviously a full docker pane system would take longer to develop.