Thursday, February 10, 2011

Portable software...

Over the last year and a half I've had the opportunity to work with Qt in software development, and I've enjoyed it greatly.

In a previous job, I looked at what it would take to port our software from being just on Microsoft Windows to also running on Linux, Mac, and various UNIX operating systems. In the course of that research I looked at several options: (i) Qt, (ii) Gtk, and (iii) WxWidget. The problem I ran into then was (a) Qt simply cost too much for the project (due to our budget), and was a security concern - not from the bug aspect but from the aspect that the target market was military and getting Qt certified for the environment would be hard - and a failure there could keep the project from certification as well. WxWidgets and Gtk both has the same security concerns; however, Gtk also had a licensing concern given its LGPL nature and our software was proprietary - Qt provided a great way around that if we could afford it, but we couldn't. So alas I was unable to get into Qt at that time, but as a result I was able to write a good portion of code for doing the same thing - writing my own platform abstraction API.

Now, of the three I loved the ideas and concepts introduced by Qt the best. Gtk, at least at that point, was still very much Message Mapping based from what I could tell. MFC was more than enough of that for me, and was just a pain - everything was determined at compile time and there was little flexibility. One of the great concepts that sold me on Qt was the Signals & Slots system that replaced the message mapping. WxWidgets supported both. Otherwise, all three seemed to be fairly equivalent at that time.

Now, before I go on let me state that I am not trying to convert anyone from Gtk or WxWidgets to Qt with this post. However, if you are using .NET or MFC or anything else (especially on Windows) then you need to start looking elsewhere for numerous reasons which I'll save for another post.

I had written applications in MFC and Win32 for a number of years - both GUI and services. They met the need at the time they were created but are no longer sufficient. .NET, on the other hand, does seem to be vastly updated by comparison but still has quite a few issues - at least patent wise if you want to have portable software.

Now, portable, multi-platform software is going to become ever increasingly important, and unless you are doing certain things that are very tied to a specific environment (e.g. extensions to Windows Explorer or KDE Plasma) then you can reach all your customers on all their platforms with a single code-base using the right tools. WxWidgets, Gtk, and Qt are some of these tools - and probably the best and most portable of all available. They are also Open Source. WxWidgets is completely public domain; while Gtk is solely LGPL. Qt, however, has several licenses - GPL, LGPL, and commercial licenses to choose from, so from a business perspective it makes the best sense - at least, as long as they continue the commercial license program; while from an Open Source perspective all three are really about equal in choice.

All that said, I must certainly say that the creators of Qt have done an excellent job and really gotten the platform right - one that is also continuously improving as well. Perfect just gets better.

So, now why do I say that?

Well, Qt is split into several modules, and they're working on making it more modular yet. Of course, you have to use the core (Qt-core) to use any of it, but the rest is pretty much optional - everything from networking to XML to services (daemons), and more - even in-program scripting. Additionally they also made it very easy to convert from Qt to Standard C++ and back - most all of their classes have functions to convert back and forth where overlapping occurs. The layers make sense and work; consistency abounds throughout the APIs.

So now with a single API you can reach from Linux, to Mac, to UNIX, to Windows; from Desktop to Server to embedded devices (tablets, netbooks, cell phones, specialty devices, etc.). There's not much you'll need a specialized, platform dependent code-base for - which basically comes down to Kernel-land software, and integration environments whose requirements prohibit being able to choose what API set you want to use (e.g. Windows Explorer ala TortoiseSVN). And you get all of it at native performance and looks, with bindings to most languages (e.g. Python, Java, Perl).

Businesses can certainly save themselves a lot of money by using APIs such as Qt, as well as preserve their businesses should anything happen to Microsoft or MS Windows - it's quite a gamble to put all your eggs in one basket, but yet so many software development houses do.

No comments: