Cross Platform GUI Development Is Hard

by Andreas Schipplock

Introduction

Today I had a conversation about how cross
platform gui development can be accomplished as easy as possible and whenever
one asks that himself the first time he might be in that illusion that cross
platform gui development can be easy and that it's not a hard thing to
accomplish but whenever one is thinking like that he is probably just wrong.

The first idea many people come across is
to develop the gui application in Java most likely with the SWING gui toolkit
which is shipped with SUN's java distribution and which can be used to create
cross platform gui applications that almost look native and almost feel native.
Most people fear SWING because they got reminded of the old times where swing
had the metal look by default which was a lot of a difference to what the
native os widgets looked like.

However, today JAVAs SWING toolkit is not
the worst idea if you want to go cross platform. You can deploy your
application to linux, windows and even os-x but you will fight with a big
drawback that almost any SWING application has to fight with: a slow gui. There
are SWING based java applications that are quite responsive but the majority
just feels slow. They don't even need to _be_ slow but they feel slow and for a
desktop application there is this one criteria that's very important but
underrated by most programmers: startup-time.

Startup-time for a desktop application is
very important as the user, when he clicks the icon of the application, expects
the app to be started immediately. It's a simple criteria but it exists and as
you know the java virtual machine takes quite some time to start up which is
not a problem for server based software but for desktop apps it is.

If you still want to go the java route and
hate swing there is an alternative which in fact is quite a good idea. It's
called SWT, is part of eclipse and implements the native ui of the os
specifically so if you want to deploy your app on os-x you'll have to ship the
os-x jar explictly. The drawback is that there aren't many gui builder
available (there is one which seems buggy).

There are some other gui libraries for java
but the most stable are AWT, Swing and SWT which you can consider to use if you
want to develop cross platform gui applications.

If you aren't the java guy, but like c++,
the fastest way to develop cross platform gui applications is to use Qt from
Nokia. Really, the lib is one of the best you may come across when hacking c++
plus Nokia gives you the Qt IDE for free which is a killer app
productivity-wise. Learning the Qt API is also very easy if you are used to
programming in general and building for different platforms is a breeze. The
only drawback is the license which is restrictive if you want to modify the
core of Qt itself. If you just want to develop your next commercial software on
top of Qt it's absolutely no problem but it's still a bitter taste in your mouth.
Consider this license 'issue' when you are doing serious development.

So what else do we have to cross develop
gui applications? C with Gtk? C++ with FLTK? Flex? Na'we want it native! Almost
at least!

Depending on what specific operating
systems you want to support it may change your decision on what to use. If you
are just want to target Windows and Linux it's easier to choose the right tool
for the right job compared to supporting OS-X, Linux and Windows at once just
because the whole desktop and usage of OS-X and Linux or Windows is quite
different. There are so tiny differences that make you cry out loud like OS-X
not having a 'tray notification bar' which is available under most Linux and
Windows desktops and which can be very usable for desktop applications. There
is such a thing in OS-X as well (upper right corner) but it's still different.

Window management under OS-X is different.
You close the main window of an app in windows and it will close the entire app
(standard behaviour). You can still add that behaviour to your OS-X variant.
Sure but you'll have to take all those tiny differences and make it work.

Sometimes it even makes more sense to write
for each platform than to have all the hassles fixing the differences with a
lot of conditionals in your code.

Under OS-X your best bet is Xcode which is
on the second DVD and which is free but you'll have to learn objective-C which
is quite a strange language if you are used to C or any other c-style language.

And now I'm going to tell you one big secret
about me and my plans in the future and why this topic ruined many weekends
trying to figure out how to develop the most generic app that runs on Windows,
Linux and OS-X and I tell you what: I failed'I failed all the times and the
reason is that you simply can't code that generic. It's just impossible.

I _really_ downloaded Realstudio 2010 trial
because they promised cross platform development with that tool is possible and
simple plus you can create binaries for Windows, Linux and OS-X under one OS
(cross compiling).

I tried that and yes, you can do all that
and it's really a breeze to work with realstudio and I even bought a license in
the end but there is still the issue of different concepts for each operating
system. Realstudio handles these quite well but at some points you still have
to workaround with conditionals.

I'm still hacking perl and clojure to
develop web services and all kinds of things but for cross platform gui
development realstudio 2010 is really one way to go though you have to code in
a basic dialect. The only drawback is the licensecosts but the prices are quite
low. I bought an os-x pro license so I can test on all supported operating
systems.

So what? Nothing! Just that cross platform
gui development needs careful thinking before you invest time that will be
wasted somewhere. Think about it before you start.

This text was written almost 7 years ago. Most
of the problems still exist though with the appearance of 'electron' companies
started to create cross platform gui applications with the help of web
technologies. Electron is more or less a chrome webbrowser without the control
elements and with added functionality.