Tobias Kaiser
A Computer Engineer's Projects and Ideas

My GUI toolkit choice for desktop applications in 2017

This is not an attempt to provide an exhaustive list or detailed comparison of all graphical user interface toolkits (what is a GUI toolkit?) that are available. It's the result of my experience as a user and developer, research, and my personal (emotional) opinion about a few graphical user interface toolkits that are out there. As I am planning to write a password manager desktop application soon, this list will remind me how I chose the GUI toolkit. It could also be of help to other developers who face the same problem and want an outside opinion.

My requirements:

  • The toolkit has to be more or less platform-independent. I want the program to work at least under Windows, Mac OS X and Linux. This is why I will not look at Cocoa or Windows Forms here. I do not want to write the GUI code three times or more just to support all major operating systems. Anyhow, I recognize that in some situations those native GUI frameworks might be a clever choice.
  • Stable code base. Please do not break the code that I am writing now with every new version of the GUI toolkit.)
  • Large user base. There are many small GUI libraries out there which might also fit my needs, but I do not want to get into a situation where I have to change to another toolkit, because nobody uses and cares the toolkit that I foolishly decided to use.
  • The programs that use the toolkit should be beautiful and usable.
  • Open source software, free of charge, permissive licensing would be preferable.
  • Easy to deploy to users.

My requirements of the stable code base and large user base also ruled out many experimental bindings of popular GUI toolkits to various programming languages. For many people their favorite programming environment might already suggest a certain GUI toolkit. As a fan of Python and GNOME, my default choice for GUI applications in the past was Python and PyGTK in the past. Further down you can see what I disliked about that.

1. Place: wxWidgets

Language support: C++, Python, others


  • Already 25 years old, still maintained, is probably still going to be around for a long time.
  • wxWigets uses native user interface elements on all platforms.
  • KiCad and [Audacity](, two pieces of software which I find work well across platforms, use wxWidgets.


  • There are no serious downsides to wxWidgets that I have discovered so far.

2. Place: Electron

Language support: JavaScript


  • Follows the latest trends of web technology.
  • Lightweight and easy to use for developer.
  • Same user experience across all platforms.
  • Classic desktop applications are not nearly as important anymore as they used to be. Web development is where most progress happens. Electron allows you to take advantage of new stuff form the web world for desktop applications.
  • As there are many users (such as the GitHub Atom editor), this toolkit will probably live for a long time.


  • Difficult to integrate with code in other programming languages.
  • Electron has no native controls.
  • We might see many changes with this platform in the future.

3. Place: Tk

Language support: Tcl, Python (Tkinter), others


  • It is of similar age as wxWidgets. Tk is very stable and is probably still going to exist for a long time.
  • Many old and reliable programs like Mentor Graphics ModelSim use Tk.


  • Learning the language Tcl would be advisable when using Tk. In my opinion Tcl is not as usable and polished as many other modern programming languages.
  • There seems to be very little ongoing development with or on Tcl/Tk.
  • While there are ways to get native widgets, most UIs built with Tk do not use those and look pretty ancient.

4. Place: Qt

Language support: C++, others


  • Growing user base, even more as GTK becomes more unpopular with developers.
  • Qt also somehow aims at mobile devices.
  • Clean code, few dependencies.


  • GPL and commercial licensing.
  • I disliked the installer from their website, which filled my hard disk with gigabytes of data.

5. Place: GTK

Language support: C, C++, others


  • Very nice integration into GNOME desktop environment, if you happen to pick the right GTK version.


  • GTK version 3 breaks everything. The entire user interface philosophy has been changed, in order to support the new desktop environment GNOME 3, which some users like and others dislike. Now there are many programs using GTK 3, and many programs using GTK 2, there is no backwards compatibility, theming is totally different. A big mess for developers and users alike.
  • User interface does not integrate smoothly into Mac (and Windows), as it does not use native widgets.
  • Depends on many related libraries and from my experience difficult to install.

6. Place: Swing

Language support: Java


  • Very platform-independent. You do not even need to recompile the Java bytecode.
  • Probably suitable if you want to work inside the Java universe.


  • Somehow there any many more Java based GUI toolkits around now, and this confuses me very much. Swing is probably not the most modern choice as a GUI toolkit in the Java world, but which of the others is the right choice?
  • I am not sure about ongoing development or support in the future.

Other toolkits

To get a full picture of what GUI toolkits are out there, there is a list of widget toolkits on Wikipedia. There are a few lightweight toolkits such as the Fox Toolkit and FLTK that I find nice, but they are not used by a lot of applications, so I left them out here.