Every platform has downsides. One of the downsides of Linux is that there are so many different distributions. Here at Xojo, Inc., we can’t officially support them all. However, that doesn’t mean Xojo and apps made with Xojo won’t work on them all. @Kevin Cully took the time to test Xojo on most of the major distros and wrote about it on his blog. If you’re using Xojo on Linux, take the time to read this informative post.
Yup, for the most part Xojo “Just Works” on Linux. There are exceptions however. There are some font sizing issues and the HTMLViewer issue, but as long as we know where those road bumps are, then as Linux developers, we can handle them. Mostly with the #TargetLinux compiler directive.
One key point I want to make and say it loud and proud is that Linux is Linux, from distribution to distribution. It’s not like Fedora is really that different from Debian. For the most part the commands are all the same. The packaged software is all of the same. They might have changed the desktop environment or tweaked it, and there may be a different package manager. For the most part, I’m disappointed on how similar all of the distributions are to each other. Of course this is to Xojo’s benefit. Xojo works well.
One distribution that I really want to take for a spin is Deepin Linux. It uses a HTML5 based desktop environment and is supposed to be beautiful. I expect Xojo to work just as well on it as the other distributions.
Maybe I’ll have a chance to get a few more benchmarks done before XDC so us Xojo Linux developers can kick around the results.
HTML5 as a desktop environment? That’s … weird. I wonder if the performance is as bad as I imagine it to be.
It’s not weird at all. It’s can be good to be able to program in one language (HTML5) and have it work not just for the web but also for the desktop. Windows 8 uses HTML5 for its metro desktop.
Not all Windows 8 new API apps are in HTML5, far from it. HTML5 has very real limitations that make it unsuitable for a lot of powerful apps that require C##, C++ or even VB.
I forgot JavaScript.
Why not a scripted desktop? This blog post on embedded languages by Havoc Pennington is quite interesting.
Window’s ‘Live Tiles’ were probably inspired by KDE’s Plasmoids (which can be backed by their own ‘data engines’ created in a variety of scripting languages):
KDE’s Application Launcher Menu is also a Plasmoid as is the lock/logout button, system monitor, etc, etc…
Enlightenment EFL (see Bodhi Linux in Kevin’s review) now has LuaJIT bindings.
Scripting languages are being used more and more for application UIs too. Developers at Nokia created QML as a response to Nokia’s management keep changing their mind about how they wanted the UI for their smartphones implemented. Digia has now extended that further with Qt Quick Controls.
I think many GUI admin tools on Linux are actually a Python scripted UI over a command line application.
Shhh! That’s a closely guarded secret and has been since Red Hat Linux 3.0.3 (circa 1996ish) 
While Kevin’s poke at the distros gives an idea of performance of the IDE on each platform (and his numbers mostly match my own earlier tests), the more pressing issue is version compatibility. Getting native 64 bit Desktop build support will alleviate so many of the problems that we see on a day to day basis thanks to missing libraries and unclear information on the distro vendor’s pertaining to getting 32bit app compatibility on their 64bit OSes.
I’m really looking forward to the day that native, 64bit builds are available for Linux desktop projects.