UTF-8 text, SVG images, inheritable GUI components, dynamically composed GUIs, layout management, splitters-in-tabs, MDIs, taskbar integration, and much more!

[JKSH]

Hi all,

I'd like to introduce LQ Widgets, a library to bring advanced GUI features to LabVIEW. It is powered by the Qt toolkit plus the Qwt library (Qt Widgets for Technical Applications).

This library consists of two major subcomponents that might interest LabVIEW users:

1. A GUI framework that is powerful, flexible, and comprehensive (see demos below).
2. A event-driven, intra-process communications framework. You can establish connections using (i) LabVIEW user events, (ii) callback VIs, or (iii) string specifications.

Here it is in action:

 

Why a GUI library?
The Idea Exchange has many, many posts about improving LabVIEW's GUI capabilities. However, we likely have to wait several years at least before these wishes are granted (see AristosQueue's post at http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Make-updating-the-GUI-a-priority-in-a-near-term-LabVIEW-release/idc-p/2710511#M26394).

The required technologies are actually available right now. In fact, they have been available for many years. All we need is a way to access them easily from LabVIEW. LQ Widgets aims to provide this access.

 

Why yet another communications framework?
Providing a comms library wasn't part of my original goal. Nonetheless, the system used by the GUI components can also be used for non-GUI purposes, so it's here for you to try.

 

Where to get it?

• Downloadable packages:
  • Package for LabVIEW 2014 (recommended; take advantage of the the new web-based documentation)
  • Package for LabVIEW 2013
• Quick start guide at https://github.com/JKSH/LQWidgets#usage. The C++ source code is also easily accessible from here, if you're interested.
  • EDIT: Most importantly, you must either extract the package to C:\LQWidgets\, or modify the output of src\LabVIEW\LQ Core\_Internal\Library Path.vi (thanks, mwebster!)

 

Project roadmap
See http://github.com/JKSH/LQWidgets/wiki/Roadmap

 

Known Issues
This is a pre-alpha release, which means (i) the API will likely change in the near future, (ii) the library is far from feature-complete, (iii) performance is not optimized, and (iv) you might experience crashes. Other issues include:

• You currently can't free any resources or disconnect signals, except by calling LQCoreEngine.lvclass:Stop Engine.vi
• QWinThumbnailToolButton cannot be applied to non-Qt windows, such as LabVIEW front panels
• After you start and stop the engine, QWinThumbnailToolButton no longer emits any signals when you click on it
  • Workaround: Restart LabVIEW
• There are a few small memory leaks, which will persist until you close LabVIEW.

 

Request for feedback

1. What do you think of the GUI-related API?
2. What do you think of the communications-related API?
3. What is the single most promising aspect of this library?
4. What is the single most frustrating aspect of this library?

All comments and critique are most welcome.

Thanks for your time!

Edited May 19, 2016 by JKSH
Highlight library path requirements; provide direct links to downloadables

[mwebster]

Trying out examples:

Lib path is hardcoded instead of relative.  Must install to c:\LQWidgets or modify lib path VI.

I will try to provide more feedback when I have a chance to play with this more, but I wanted to point this out ASAP so others don't give up on trying this out prematurely.

I also want to say that from a just toe-wet perspective, I'm very impressed by the organization, documentation, and depth of the examples so far.

 

Edit:

And, obviously, you document this in the README file.  Who reads README's? 

Edited May 12, 2016 by mwebster
Idiot

[JKSH]

@mwebster, thanks for your kind words, and for swiftly posting your tips to help others. I'm looking forward to hearing your thoughts!

 

On 5/12/2016 at 0:40 AM, mwebster said:

Edit:

And, obviously, you document this in the README file.  Who reads README's? 

I can relate  I've added the path tidbit near the download link in my original post.

[ShaunR]

On 5/12/2016 at 5:40 PM, mwebster said:

And, obviously, you document this in the README file.  Who reads README's? 

You do, obviously

[mwebster]

So let me say at the outset, this is very impressive.  It allows for dynamic runtime creation of well-behaved controls and indicators that resize beautifully and have tons of customization options (lots of work has obviously gone into Qt Widgets).  I really like the way you can link objects together solely through the Qt framework or through events or through callbacks.  I hope I can find an excuse to use it.

However, I have absolutely no vision of how to use this on anything outside the smallest of projects.  The overhead required to do manual, programmatic layout removes one of Labview's biggest advantages ((relatively) quick GUI development).  And it's like the worst of both worlds, the complexity of text based GUI design with the interface of doing it through Labview.  It reminds me of how when I do anything beyond the simplest math, I reach for the equation node.  Oh, even more, it reminds me of the Labview TestStand OI.  That thing makes me cross-eyed every time I delve down into it.  So many callbacks and hooks.  I'm sure given the time I could replicate what I'm normally doing in a standard GUI, but the learning curve seems very daunting.

Other practical observations:

• Obviously the Labview crashing thing needs to be figured out.  I really wish Labview played better with external code, I ran into a hard crash to desktop just last month trying to use an external C# .NET library if everything wasn't cleaned up just right (accidentally hit abort button from muscle memory?  bye-bye labview).
• We should be able to rename event wires.  I dove into this a bit on the interwebs and apparently it isn't possible at runtime (you can cast it to a different, fixed name with a typecast, but not to a dynamic name).  I can see this being a real issue if you decide to use a bunch of events in your program.  I guess we could always cast them just before event registration, just a little painful.

You speak of possibly having a GUI editor in the far future.  Something like the QT Creator IDE frontend that figures out how to use VI scripting to create the equivalent Labview calls?  Unfortunately I feel like I would probably need something at that level before diving in headfirst.

All of that said, I do plan to keep an eye on this.  Some of the capabilities of QT are really cool looking, especially in regards to themes, graphs, and accelerated 3d visualizations.

Best regards,

Mike

[ShaunR]

10 hours ago, mwebster said:

However, I have absolutely no vision of how to use this on anything outside the smallest of projects.  The overhead required to do manual, programmatic layout removes one of Labview's biggest advantages ((relatively) quick GUI development).  And it's like the worst of both worlds, the complexity of text based GUI design with the interface of doing it through Labview. 

It's no worse than  having to use the property nodes and callbacks for ActiveX/.NET controls or the external windows of the Vision toolkit and this is, or is potentially, cross platform.

[mwebster]

1 hour ago, ShaunR said:

It's no worse than  having to use the property nodes and callbacks for ActiveX/.NET controls or the external windows of the Vision toolkit and this is, or is potentially, cross platform.

You're right, and I don't do entire projects with those either.

You raise a good point though.  I may find a way to use this like I do with the occasional ActiveX/.NET stuff, as a component of a project.  I could see using it for a sort of dynamic data viewer (Select 1 to n channels from a group performing active acquisition, add and bind indicators / graphs to a container and poof).

[JKSH]

@mwebster, thank you again for taking the time to test drive LQ Widgets. Very much appreciated! Thanks also for your vote of confidence. It has certainly given me the motivation to work faster  

14 hours ago, mwebster said:

(lots of work has obviously gone into Qt Widgets)

Indeed. Qt Widgets is very mature and stable; that's the main reason why I picked the widgets API as a starting point for this project.

The Qt Company is now pouring resources into the next-gen GUI framework; it's definitely more powerful than the widgets, but it's still evolving. I believe Qt Widgets will remain relevant for the core Qt users for many years to come.

 

14 hours ago, mwebster said:

I really like the way you can link objects together solely through the Qt framework or through events or through callbacks.  I hope I can find an excuse to use it.

Same here

 

14 hours ago, mwebster said:

However, I have absolutely no vision of how to use this on anything outside the smallest of projects.  The overhead required to do manual, programmatic layout removes one of Labview's biggest advantages ((relatively) quick GUI development).

Interesting. I was thinking the exact opposite, actually: Given the overhead involved in creating and wiring up the GUI, I thought it's an overkill for small projects. In contrast, LQ Widgets could be a good investment for large, long-term projects that need complex GUIs.

I find LabVIEW GUIs great for rapid prototyping -- we can get something up and running very very quickly. However, it's somewhat limiting, and requires me to perform gymnastics to do anything fancy (e.g. dynamically composing a dialog requires image manipulation). I'm aiming to make this API less tedious and more intuitive than those gymnastics moves.

Anyway, LabVIEW front panels and LQ Widgets can coexist happily in the same project, as you mentioned already.

 

14 hours ago, mwebster said:

it reminds me of the Labview TestStand OI.  That thing makes me cross-eyed every time I delve down into it.  So many callbacks and hooks.

I think that's because TestStand OIs rely heavily on ActiveX, so you need to do the things that @ShaunR mentioned.

It's definitely a very different paradigm from LabVIEW's traditional dataflow. Having said that, GUI interactions are asynchronous, which doesn't fit neatly into the dataflow world.

 

14 hours ago, mwebster said:

Obviously the Labview crashing thing needs to be figured out.

Did you encounter any crashes when test-driving LQ Widgets? If so, do you remember what caused them?

 

14 hours ago, mwebster said:

We should be able to rename event wires

Yep, I've been looking for a good way to name events too (and so have many others).

The demo video above shows "casting" in action, at 3:37.

 

14 hours ago, mwebster said:

You speak of possibly having a GUI editor in the far future.  Something like the QT Creator IDE frontend that figures out how to use VI scripting to create the equivalent Labview calls?  Unfortunately I feel like I would probably need something at that level before diving in headfirst.

All of that said, I do plan to keep an eye on this.  Some of the capabilities of QT are really cool looking, especially in regards to themes, graphs, and accelerated 3d visualizations.

Yes, I can see how the WYSIWYG editor can lower the entry barrier. OK, I'll bump this up in my priority list. Stay tuned!

 

14 hours ago, mwebster said:

Some of the capabilities of QT are really cool looking, especially in regards to themes, graphs, and accelerated 3d visualizations.

Mm, my mouth watered the first time I saw the 3D stuff. They used to be restricted to enterprise customers only, but in about 2 months from now they will be released to the open-source community! (GPL only, so they can't be used in proprietary apps without buying a commercial license, but still…)

 

3 hours ago, ShaunR said:

this is, or is potentially, cross platform.

Exactly right. I'm very confident that LQ Widgets can be ported to Linux (including Linux RT CompactRIOs with Embedded UIs) with minimal effort. Not sure about OS X though.

Edited May 17, 2016 by JKSH

[mwebster]

1 hour ago, JKSH said:

Did you encounter any crashes when test-driving LQ Widgets? If so, do you remember what caused them?

 

It was the one you actually mentioned in your documentation with the dynamic GUI composition, where selecting Tab Widget, Splitter, or MDI Area causes LabVIEW to freeze when transitioning back to edit mode.

I do agree that the learning curve would be easier to absorb into a large scale project.  I guess my problem is I work on too many medium scale (1 or 2 developer) projects.  The intimidating thing to me was the thought of using this for the entirety of the project, I'm much more comfortable with using a piece of it to implement something LabVIEW can't do on its own.

I was wondering though, can you get any events from the widgets besides the signals they emit (valueChanged, sliderPressed)?  i.e. mouseover, mouse down with modifier keys, etc?

[JKSH]

On 5/17/2016 at 10:57 PM, mwebster said:

It was the one you actually mentioned in your documentation with the dynamic GUI composition, where selecting Tab Widget, Splitter, or MDI Area causes LabVIEW to freeze when transitioning back to edit mode.

This one looks like a LabVIEW bug. I've reported it at http://forums.ni.com/t5/LabVIEW/BUG-Certain-code-paths-make-LabVIEW-deadlock-freeze-when/m-p/3299411 (I hope they won't say something like "callbacks are only meant for use with .NET...")

If you modify the example and manually create the new Growable Widget yourself (without triggering any callbacks), you can dynamically add tabs/splitters/MDIs to the top-level tab without causing the freeze.

 

On 5/17/2016 at 10:57 PM, mwebster said:

I do agree that the learning curve would be easier to absorb into a large scale project.  I guess my problem is I work on too many medium scale (1 or 2 developer) projects.  The intimidating thing to me was the thought of using this for the entirety of the project, I'm much more comfortable with using a piece of it to implement something LabVIEW can't do on its own.

Agreed, using LQ Widgets to complement LabVIEW front panels is the most sensible way to start.

 

Regarding the learning curve in general: What are your thoughts on the "Hello World - Introduction to Widgets" example/tutorial? Was it easy to follow, and was it complete enough?

 

 

On 5/17/2016 at 10:57 PM, mwebster said:

I was wondering though, can you get any events from the widgets besides the signals they emit (valueChanged, sliderPressed)?  i.e. mouseover, mouse down with modifier keys, etc?

Kind of (not in LabVIEW yet). In C++, the most common way to act on these events is to override the widget's mousePressEvent method, for example. In your override, you can query the event parameters (which does include modifier keys) and run custom code. To integrate this mechanism into LabVIEW, we need to make the C++ side call your LabVIEW-defined event handling code and wait for your result before continuing. I've got an idea but haven't tried it yet.

Do you  have a use case in mind? Perhaps there's an alternative solution that doesn't involve handling these events.

Edited May 24, 2016 by JKSH
Link to bug report

[mwebster]

18 hours ago, JKSH said:

Regarding the learning curve in general: What are your thoughts on the "Hello World - Introduction to Widgets" example/tutorial? Was it easy to follow, and was it complete enough?

Yeah, the tutorials were great.  Maybe add an overview VI with one of each of the various widgets you've implemented so far?  I still don't really know what a DoubleSpinBox or FontComboBox is ...

18 hours ago, JKSH said:

Kind of (not in LabVIEW yet). In C++, the most common way to act on these events is to override the widget's mousePressEvent method, for example. In your override, you can query the event parameters (which does include modifier keys) and run custom code. To integrate this mechanism into LabVIEW, we need to make the C++ side call your LabVIEW-defined event handling code and wait for your result before continuing. I've got an idea but haven't tried it yet.

Do you  have a use case in mind? Perhaps there's an alternative solution that doesn't involve handling these events.

Nothing in particular, I was thinking of how to extend the chart functionality with a right-click menu popup or something.  Just thinking about what could be done.  The chart you have looks like maybe a wrapper for QChart without all of the properties exposed?

I also did a little playing around with the stylesheet property input and got some cool background gradient effects on the indicators.  Neat stuff. 

It would be cool if we could access the full QML markup (like drop this QML markup string into this container layer) to do things like control animations, but I don't know how you'd go about accessing those declared controls programatically back in LabVIEW.

Mike

[JKSH]

• Overview VI: The closest thing for now is the "Dynamic GUI Composition and Management" example. The Input Widget contains both QDoubleSpinBox and the QFontComboBox.
  • QDoubleSpinBox: Like a LabVIEW Numeric Control that holds DBL values only. (In contrast, QSpinBox holds I32 values only.) I plan to create a hybrid widget with a selectable numeric Representation, just like what LabVIEW users are used to.
     
  • QFontComboBox: A drop-down menu that lets you choose a font.
    
     
  • This page might also help: http://doc.qt.io/qt-5/widget-classes.html
     
• Charts: The pre-existing class (QwtPlot) require users to manage the data arrays manually, which is a bit unwieldy. I created LQChart specially for LQWidgets; I want it to be as similar to a native LabVIEW chart as possible. It's currently incomplete.
   
• Right-click popup menu (a.k.a. "Context Menu"): You can create a menu using QActions. The menu items emit the triggered() signal when selected. The "Porting XControls - Dual Mode Thermometer" example uses this.
  • Darn, I just found a bug. In the code below, only the first item will appear in the menu... but once that's fixed, this is how you can code it. As a workaround, you can call QWidget.lvclass:addActions.vi multiple times, and only pass 1 QAction into each call.
    
     
• QML: That's the next-gen GUI framework. The road to full LabVIEW integration involves quite a bit of work, but it's doable  I'll probably release QML support incrementally.

Edited May 19, 2016 by JKSH
Add workaround for bug