Choosing a Desktop Application Framework

Triumph is a desktop application that is used by PHP developers to write their programs. As with any application, a early task of the project is to choose a framework from which to base the project on. Choosing a framework is an important decision because it dictates the application structure. A good framework can make maintenance easier and eliminate certain classes of bugs. Here are some factors to that I took in consideration when choosing an application framework for developing Triumph. Feel free to play along.

  • Which operating systems is the app going to be deployed to? Triumph has chosen to be deployed to all three major operating systems: MS Windows, Linux, and Mac OS X. The reason for this is that developer environments are as heterogenous as they have ever been; Windows, Linux and Mac OS X all have their following and all are used for development. The chosen app framework must play nice in all three environments and look good in all three environments.
  • What are the deployment dependencies? Is the user going to need to have an interpreter, compiler, or support library installed? This is an especially tricky issue for developers, as they already have interpreters, compilers, and support libraries that they use for their day-to-day work. Installing it should not result in breaking their dev environment due to multiple versions of interpreters, compilers, or supporting libraries.
  • What are the performance requirements?. Performance is a vague term; Triumph has chosen to define performance as the ability of the program to function without the user seeing "Application not responding" messages, experiencing app freezes or whitescreens. There are other performance requirements, like optimizing binary size, which are not important to Triumph.
  • Is the framework in heavy use? Good docs will only go so far. A framework that is used by many projects will result in more internet discussions about it. A framework that is in heavy use is more likely to get bug fixes and new features sooner.
  • What are the license terms of the framework? The license terms affect deployments, as deployment is "distributing" (allowing users to download Triumph) and we must adhere to the framework's license terms.

As part of our due-dilligence we should ask, do we even need a framework at all?

Going it alone

Let's admit, we all get frustrated with frameworks. We think they are slow, complicated, and bloated. We all think of ourselves as rockstar 10x developers that can build an app without a framework. If Triumph chose to go without an app framwork, the biggest hurdle would be dealing with building GUIs in the three operating systems. Without a framework, Triumph would need to be 3 different applications; 3 different code bases that share a library. The end result is that user interface features may get out-of-sync among all three apps. This is something that is a deal-breaker for Triumph.

Option 1: How about java?

Java is a good choice for cross platform apps. It allows us to write code that runs on all 3 operating systems, It is stable and well-documented. Java comes with 2 UI packages in its standard library.

Pros:

  • Java is a solid language with good cross platform support and excellent tooling.

Cons:

  • Deployment may get tricky; must bundle java or have the user install it. If the user already has it installed, will it be a older version that is no longer supported?
  • The performance of other IDEs that are written in Java is a point of discussion. Are the performance problems of IDEs due to the application code itself, or are they inherent in the chosen app platform? Without the source code, we are left to speculate.

Option 2: C++ with Qt

Qt is a cross platform UI toolkit. It renders its own widgets; and the widgets are drawn to closely mimic the host operating systems' widgets. The license is a bit complex; Qt can be used for open source, but it does require a commercial license for commercial apps in some cases.

Cons:

  • Triumph has chosen the option wanting to leverage the host operating system widgets as opposed to having total control over the look and feel of widgets. Qt does not help us in this regard.
  • The license may not fit this project. I am not sure if Triumph will be an open source project at this time, and I am not an established company with recurring income.

Option 3: C++ with wxWidgets

wxWidgets is a C++ cross platform UI toolkit. Rather than rendering its own widgets, it is a layer on top of an operating systems widget system. wxWidgets has its own license, the wxWidgets license. The license is basically the LPGL with the exception that a derived work can be distributed on the author's own terms.

And the winner is ...

I admittedly did not explore too many options once I discovered wxWidgets. I was seduced by the challenge of creating a non-trivial app in C++. I wanted to create an app that would better integrated into the host operating system. I wanted an app that would look and feel like a desktop application. The wxWidgets license gave me the option of creating a commercial or open source project. Choosing a C++ app would alleviate users from having to install Java, potentially breaking their development environments.