Cross platform GUI development

[trevwhite]

Thanks for all the discussion. I am currently reading a book on node.js. It looks very interesting and might be a nice way forward.

I was surprised though that no one really mentioned Java. I thought this is what it was created for? Is it just not recommended or are there not many people using it? I know Android is created from it but does Java have any place in the cross platform gui world?

[nctnico]

Not so long ago running Java on an embedded Linux platform was a no-go due to resources and you could only use a 'cut down Java for embedded devices' which is a major PITA to compile yourself. Nowadays with 1GHz ARM CPUs Java could be an option but it has a long road ahead to catch up. Also the stability of Java could be an issue. From what I have seen it is not trivial to write a well behaving Java application; I've seen too many Java applications with quirky bugs.

[jancumps]

Thanks for all the discussion. I am currently reading a book on node.js. It looks very interesting and might be a nice way forward.

I was surprised though that no one really mentioned Java. I thought this is what it was created for? Is it just not recommended or are there not many people using it? I know Android is created from it but does Java have any place in the cross platform gui world?

I'm a big Java fan. I held back from suggesting it because you asked cross-platform without specifying what platforms you were targeting.
I've run Java applications across Windows, Unix (Sun Solaris), Linux (Ubuntu) and AS-400 (non-gui on that platform) with Java.
But there are other platforms that don't support it. Hence I kept stumm on that option.

[tonyarkles]

That is exactly what most cross platform frameworks do: create a library which deals with the OS specific stuff.

No no, I mean the opposite. Create a library that handles all of the non-OS specific stuff (data processing, etc). Link that library with an app that you create for each OS. That way you end up with a nice native-feeling app for each OS, but you don't have to worry about copy & pasting all of the guts of your app, you just link the library.

[nctnico]

That is exactly what most cross platform frameworks do: create a library which deals with the OS specific stuff.

No no, I mean the opposite. Create a library that handles all of the non-OS specific stuff (data processing, etc). Link that library with an app that you create for each OS.

Ah I see. That sounds like a cumbersome approach because a library may be harder to debug than having all the code inside one application. A long time ago I did a project where I put the business logic into a seperate DLL (for a different reason) but that made things quite complicated because both the library and user application needed debugging.

[tonyarkles]

That is exactly what most cross platform frameworks do: create a library which deals with the OS specific stuff.

No no, I mean the opposite. Create a library that handles all of the non-OS specific stuff (data processing, etc). Link that library with an app that you create for each OS.

Ah I see. That sounds like a cumbersome approach because a library may be harder to debug than having all the code inside one application. A long time ago I did a project where I put the business logic into a seperate DLL (for a different reason) but that made things quite complicated because both the library and user application needed debugging.

Less challenging in my experience than trying to make sure that algorithm changes and business logic changes get patched into 4 different apps.

[nctnico]

And again that is why people use cross platform frameworks. One piece of source to maintain AND the cross platform framework takes care of the nasty idiosyncrasies of an OS so it's a win-win.

[tonyarkles]

And again that is why people use cross platform frameworks. One piece of source to maintain AND the cross platform framework takes care of the nasty idiosyncrasies of an OS so it's a win-win.

The only person who loses is the user, when they end up with an app that almost-but-not-quite feels like an app for their platform

This is definitely not the only way that works, but it's the way that's worked best for me in my experience. Another nice perk is that it makes it super easy to do:

- automated testing: you can test all of the features of the app (other than the GUI) using a unit test framework. The library doesn't have any GUI dependencies, so you can exercise all of the functionality in an automated way

- command-line tools: if you end up with a use case where you just want to use one or two features, it's super easy to link against the library. As an example, a client had a custom board that we wrote a GUI for and they were curious about how much a particular ADC on the board varied over time (and temperature in the room). I wrote up a 20 line CLI program that just queried the value of that sensor every 5 minutes and we left it to run for a few days. It just dumped out a csv that we loaded up in Excel later to look at. Way way way less work than building a new one-off feature into the GUI, plus we could easily repeat the test later on with new hardware revs.

Edit: a 3rd example

- I had a different client with the same kind of setup, custom board, etc. They had a desktop app, and they wanted to make a cut-down web version. All I had to do was load the library using Python ctypes (https://docs.python.org/2/library/ctypes.html) and right away my web app had access to all of the functionality of the hardware. Put together a few HTTP endpoints, and they had a super simple web app that could do exactly what they wanted. If the code that accessed the external hardware was tied in with their GUI code, it would have been *way* harder to do that.

[nctnico]

And again that is why people use cross platform frameworks. One piece of source to maintain AND the cross platform framework takes care of the nasty idiosyncrasies of an OS so it's a win-win.

The only person who loses is the user, when they end up with an app that almost-but-not-quite feels like an app for their platform

That totally depends on which framework you use. I have most experience with WxWidgets which uses the native platform controls. So an application compiled for Windows just looks & feel like any other Windows application because nothing is emulated. For embedded Linux platforms customers often want to have their own look and feel so I use a GTK theme to customise the way the user interface looks. Still both the Windows application and embedded Linux application are compiled from exactly the same source.

Edit: a 3rd example
- I had a different client with the same kind of setup, custom board, etc. They had a desktop app, and they wanted to make a cut-down web version. All I had to do was load the library using Python ctypes (https://docs.python.org/2/library/ctypes.html) and right away my web app had access to all of the functionality of the hardware. Put together a few HTTP endpoints, and they had a super simple web app that could do exactly what they wanted. If the code that accessed the external hardware was tied in with their GUI code, it would have been *way* harder to do that.

Usually you put the code which deals with the hardware and business logic in seperate objects/files so it shouldn't be hard to fork off a DLL/library from an application which is otherwise compiled into a user application. But that depends more on how clean the code is written. If the programmer puts the business logic and GUI together then it is hard to seperate them (and time for a serious talk about career opportunities ).

[tonyarkles]

And again that is why people use cross platform frameworks. One piece of source to maintain AND the cross platform framework takes care of the nasty idiosyncrasies of an OS so it's a win-win.

The only person who loses is the user, when they end up with an app that almost-but-not-quite feels like an app for their platform

That totally depends on which framework you use. I have most experience with WxWidgets which uses the native platform controls. So an application compiled for Windows just looks & feel like any other Windows application because nothing is emulated. For embedded Linux platforms customers often want to have their own look and feel so I use a GTK theme to customise the way the user interface looks. Still both the Windows application and embedded Linux application are compiled from exactly the same source.

Yes, WxWidgets uses native platform controls but... Most of the work I've done has been Windows and Mac. There's a lot more to a "native-feeling" app than just using native controls. A Wx app for Windows and Mac will either feel like a Windows app with Mac controls, or a Mac app with Windows controls (depending on which platform you use to influence the style of the app). Wx gets the "look" part of the "look and feel" idea right, but Wx apps usually feel right on one platform and feel weird on another.

Matlab is a great example (while not a Wx app). Matlab feels pretty right on Windows, and it just feels weird on a Mac. Doesn't fit with the rest of the apps that I've got running. All the details are off. It doesn't feel like a Mac app, it feels like a Windows app that conveniently runs on a Mac.

Edit: Thought of another simple example

Settings Pages. On Windows, it's super common to have a settings page be tab-based (separate tabs for different aspects of config). On OSX, it's usually either separate list-detail views (e.g. the "System Preferences" app), or a list on the left-hand side of different aspects, with the config details on the right-hand side. Unless you build two separate Wx GUIs, you're going to end up with one platform using a paradigm that's common on the other.