In one of my last articles I mentioned that I’ve been keeping myself very busy, over the past year. My stated excuse was that I was writing a LabVIEW book (which has, by the way, just started shipping from the printer), but that wasn’t the whole story. What I intentionally omitted, was that I was also working with the rest of the JKI team on something that, to the best of our knowledge, has never been done before. We created a professional-quality, cross-platform, desktop application, written in LabVIEW. At the beginning of this past week, we unveiled VI Package Manager, a package management framework for LabVIEW VIs that allows you to find and download VIs, over the Internet.
Why did we undertake such a large and daunting task? (Believe me when I say that this was far from easy.) We did it, simply because it had to be done and we wanted to be the ones to do it. To the best of our knowledge, nobody has ever developed a cross-platform desktop application, written in LabVIEW, and we needed to prove that it could be done. And, if it couldn’t be done, we absolutely needed to figure out why not and then overcome any obstacles. At JKI, we have (putting all modesty aside) some of the best LabVIEW developers in the world. And, if you have that kind of LabVIEW talent sitting under the same roof, then you had damn well better be doing something great with it, otherwise your just wasting a perfect opportunity. That’s why we did it.
So, what did we learn? Lot’s of things. For example, how to secure subVI calls, create a self-extracting installer, configure and communicate with the LabVIEW development environment using VI Server, create a cross-platform context help solution, create a listbox with glyphs, implement a check for updates feature, use splitter bars to make a really slick user interface, completely automate the build process, create a cross-platform application that uses several platform-dependent functions, and much more.
In the coming weeks, I am going to write more articles about our experience developing VIPM and some of the techniques that we learned. For example, I am very interested in discussing how we used OpenG Builder to execute over 10 separate build steps and also how we used LabVIEW Scripting to inline subVIs (at build time) for security. I also want to talk about the LabVIEW bugs and issues that really chewed up enormous amounts of time. I want to talk about how we use FogBugz and Subversion for issue tracking and source code control. (Because, if your going to create great software, you definitely need the best tools.) And, I also want to discuss how we used an automated daily build, in order to improve our development and testing.
We’ve proven that creating great desktop applications, written in LabVIEW, is certainly possible. And, the future is full of possibilities for other new and exciting applications (written in LabVIEW, of course).