Leaderboard

@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 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. Same here 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. 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. Did you encounter any crashes when test-driving LQ Widgets? If so, do you remember what caused them? 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. 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! 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…) 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.

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