At first, I ran with the Mono reimplementation of Winforms on Linux. That didn't work very well. There are a lot of little incompatibilities, like differences in how keystrokes are translated, and very buggy text boxes.
So I reimplemented the UI in Gtk-Sharp. That was mostly a matter of translating existing Gtk documentation to the OO API presented by the C# wrapper. I could write this in Visual Studio and run using Gtk on Windows to test; Mono itself wasn't actually needed here.
I then ran the app using Mono on Windows. Once all the DLLs were in the right places, it mostly just worked. Running it on Linux - specifically, Ubuntu 12.04 LTS - was a little trickier, as Ubuntu has split out many of the different assemblies into separate packages, and you have to grovel around a bit to get what you want, if you don't want everything. But again, it mostly just worked.
Compiling using Mono took a little bit of figuring out - mainly, finding out I had to use dmcs rather than mcs or gmcs to enable the right language features. But again, once the right assemblies were referenced on the command line, it mostly just worked.
Writing a cross-platform app in Mono? I wouldn't really try that. Having a separate UI layer for each platform gets you a much better experience. Gtk programming itself is extremely clunky compared to Winforms, which itself is quite clunky - albeit in different dimensions - compared either with Delphi's VCL or WPF. But it was the only way I could see to go to get a reasonable experience on Linux.
Look at an actively maintained solution like Xamarin or Unity; Xamarin lets you write your UI specific code for each platform; Unity lets you share UI across platforms but you won't get a 'native' look and feel on any.
For both of these you won't be able to use the majority of existing .Net infrastructure (nlog, nject, nhibernate, etc) because they are locked into the windows CLR, but there are a few ports and you can often get away with compiling the source from codeplex yourself (the prebuilt DLLs just wont work).
(Unfortunately, porting your existing application is absolutely out of the question in most cases, for the reason above. Perhaps if you've carefully isolated concerns it might be possible...)
You could also take a look at Juce, depending on what you need to do with it.
But, if you don't mind large binaries you could easily embed a chromium or awesomium layer as your frontend and do your frontend in html/css/javascript and use JavaScript to communicate with your backend.
As people as said, the best idea would be to write one backend and three or two frontends. That will give you the best experience on all three platforms, and the native GUI look, something that on Mac Qt still suffers with.
I have just started working on GUI apps with Clojure and the story is much better so far! Seesaw[0] definitely slims up the Swing code, and I've been using Core.Async[1] to remove a lot of the callback handlers. So far, so good. :-) It's definitely worth looking into.
Swing is used by two kinds of people: developers, because the tools that use it are just too good to go elsewhere (IntelliJ etc) and enterprise users that have it forced upon them.
I don't think anybody is using Swing willingly -- or enjoying it. Besides the "uncanny valley" effect to native widgets, it suffered from the start from the main negative of Java's culture: it was overengineered. On top, it underdelivers in many areas.
The only cross-platform GUI toolkit that I loved working with and that does a much better job than Swing is Qt. Unfortunately Qt is C++ and it's not even standard C++. So language bindings are hard to build and (compared with Gtk) working with C++/Qt is not so painful. The bindings for Mono are dead. Trolltech released at some point Qt Jambi, the Java bindings, which were awesome, unfortunately the Java community hasn't been interested in it, so Qt Jambi also died after Nokia acquired Trolltech - for the moment at least (the wonderful thing about open-source stuff is that it can be revived with enough interest). The only well maintained language bindings for Qt is PyQt.
And yes, building the UI using the platforms native stuff yields better results, but it's also more expensive to do so. We're all moving in that direction anyway, given the emerging mobile platforms. Sometimes I'm thinking that for desktop apps it's just better to embed a web browser and build the UI with HTML/CSS and JS.
Both statements I agree with!
I think it's a sad state of affairs, that the tens of billion s IT industry, and the whole OSS community, cann't produce, and maintain, a decent, cross platform UI, based on C with hooks for various languages.
GTK has dropped the ball even on Linux (Mac/Windows support is crap, and the library is essentially what it was 10 years ago content wise).
wXWidgets is at the same level more or less.
QT is nice, but is C++, so you either by into the whole thing or you face the not so good support and bindings to other languages (Python has the best support, but even that is mediocre).
Mozilla's XUL was never wrapped and maintained properly (as once promised), to be use to use for cross platform development.
SWT needs Java, and is too tailored to Eclipse's needs.
I, for one, don't need native look in all apps -- I could do with something like the cross platform widget library Adobe built for Lightroom -- that and a webkit view.
Just out of curiosity, what other gui tool kits have you used that you compare Swing too? I always wonder what gui toolkits those who decry Swing have experience with.
Myself, I've used Win 32 api, MFC, SWT, and gtk. Imo, Swing is by far the best of those; relatively consistent api, a wide variety of widgets, customizable, ... True it can be very complex (ie editor kits) and some things are/were missing for a long time (close buttons in tabbed panes). Also true that it doesn't look 'native' on all platform, but no gui tool kit can. I have not used Qt, but it seems to be equivalent to, or surpass Swing in all those areas.
I've used Cocoa, GTK on Linux, and Windows Forms (or whatever .NET v1 and v2 had called) in Windows. Have also used Swing.
Quality of results wise, Cocoa beats them all down, but single platform unfortunately. The .NET solution was also nice, but limited to a single platform too. (I know of, but don't care for small-time hacks to make Cocoa/.NET play on other platforms, only for officially supported projects).
Swing had been a pain in the ass to create UIs with, overengineered, with missing functionality (how long did we have to wait for a HTML control?) and ugly too boot.
Swing has one thing going for it: it does work on all platforms. I just wish it was better designed (API wise), more complete, and less uncanny valey-ish.
Seesaw is the only reason why I'm still bothering with Swing too, it actually makes the thing fun to use!
I'm a Java developer and I would write the software using Java if only Java isn't stigmatized by "bad software" in the desktop market. It's too bad because so far only Java that provide some of the solutions for me in a few areas to tackle in the cross-platform desktop market, namely: dealing with dependencies, rich 3rd-party libraries (and most of them are FOSS) and a packaging tool for Mac App-Store!.
I wouldn't mind writing 3 different UI code as long as I can share the back-end part and that shareable code works consistently across platform (i.e.: something that communicate with an embedded database like SQLite).
Can anyone share their experience using Mono for cross-platform desktop application that requires DB connection and potentially deal with Service API (i.e.: Twitter, Dropbox, etc)?
My requirements are as follow:
1. Installer/Packager
Something that can help me to generate installer for Windows 7, Mac AppStore, Ubuntu software center (or .deb). RPM would be nice but I can live with writing shell script.
2. Build+Dependency management (don't know if NuGet works flawlessly or not in Linux/Mac)
Maven spoiled me (people who dislike Maven please close your eyes...). I've read that Mono has xbuild but the documentation seems... lacking.
3. Unit-testing
Something where I can run unit-tests through the IDE so I can debug directly from my unit-tests when bugs are found.
4. Good enough 3rd-party libraries
I'm down writing missing libraries if needed but my first priority is the app itself.
We used Wix for the Windows installer and the included OSX tools to make the Mac installer (http://s.sudre.free.fr/Stuff/PackageMaker_Howto.html was helpful).
A TeamCity build system using NuGet worked fine for building both flavors, though the Mac build was really just a shell script that TeamCity launched. We used the Xamarin compiler for Mac.
In hindsight I wish we had taken (found?) the time to go all the way and write separate OSX specific UI code and not used GtkSharp. And not require the install of the Mono framework for Mac users-- that really kills the experience. Supposedly you can bundle in Mono with the Xamarin .Mac product but we haven't found the time to get that far yet.
*EDIT: I failed to mention explicitly this was C#/Mono. Also for those interested I used http://www.signal11.us/oss/hidapi/ as a wrapper around the Mac HID USB APIs and it worked fine.
Granted, for many people, it's about as hip as Rails is to a newly converted node.js fan, but Tcl and Tk are still a pretty good way of writing smaller apps that run cross platform. Like someone else says, if you want a native GUI, you really need to write that separately for each platform. But that's a big investment, and for some systems, it might not be worthwhile.
Might be worth trying out. You can still run your application on Microsoft's .NET stack on Windows, GtkSharp supports it just fine, and because it uses GTK it will look native on all of the supported platforms.
Disclaimer: I haven't actually tried any of the above.
It's hardware accelerated, so I can write my own custom GLSL shaders for the UI, which is pretty cool. I bet I could even implement a Mario-style game using Kivy. The main application window is just a GL context, and all the UI widget rendering is done via GL.
Unfortunately the Kivy UI seems to be riddled with bugs, and the UI widgets themselves are very alien. For example, the Kivy file browser widget seems to be incomplete (it lacks basic features) and confusing (it behaves nothing like a native file selector). So Kivy is probably too jarring of an experience for users... if I use Kivy in its current form, all my users would balk at the unintuitive UI, since Kivy's widgets don't look or feel anything like native platform widgets. And since users would also be fighting Kivy's UI bugs, I predict every user would immediately ragequit my app. (E.g. drag-selecting text within multiline textboxes seems to be broken, etc.)
That said, Kivy is very close to being an effective way to effortlessly write crossplatform GUI apps. The main reason to use Kivy is because it's so easy to write useful apps with it. I wrote one in about 15 minutes from start to finish. The API is a pleasure to use, and the data binding design is especially brilliant.
Kivy seems pretty fantastic for writing internal tools. Data visualization via Python is now a cinch thanks to Kivy. For example, it'd be easy to write an app that shows the current status of all your server instances. And of course at that point it'd be easy to extend your app's functionality with features like "right click on a server instance to spawn an SSH session into it". Stuff like that is a breeze thanks to Kivy.
Time to try out everyone else's suggestions. Up next: Clojure + Seesaw. (This thread has been incredibly helpful... So many interesting ideas. Thanks, everyone!)
That being said, even when compiling for PC it's worked very well for me when a client wants an internal tool and is willing to give up a native feel in exchange for fast (cheap!) development. I wrote this for UCLA a few months ago, and I think the whole thing only took me about 20 hours: https://github.com/sbrother/wassum-lab-lick-program/
I ended up doing the multi-touch UI in JavaScript and HTML instead. It felt much clunkier to work with, but I wasn't comfortable with wrangling Kivy's instability for the rest of the project.
[0] http://cleichner.blogspot.com/2011/02/multitouch-project.htm...
Speaking of Mono, does anyone know of a good resource for C#/.NET devs to learn how to port their Windows apps to Linux/Mac relatively easily?
I did a writeup a month ago about my first impressions of Mono: https://news.ycombinator.com/item?id=6744622
In short, there don't seem to be very many "Here's how to write cross-platform C# code that runs on all three platforms without much effort" type resources. It seems like most Mono newcomers will find it difficult to get up and running, especially if you've been developing your app with Visual Studio 2010 or later. So it seems like there aren't very many good tutorials written specifically to teach Windows C# devs how to quickly get up to speed with Mono.
After spending some time researching the idea of writing GUI apps using C# and Mono, I gave up because it just didn't seem straightforward. Maybe I was going about it the wrong way, but it seemed like Python + Qt bindings would be a more effective approach, even though you lose out Visual Studio's awesome GUI designer. But I haven't actually tried python+qt yet on all three platforms, so maybe it isn't as easy as it seems. And my Qt knowledge is somewhat dated, so maybe there's a better solution nowadays.
Does anyone have any recommendations for the easiest way to write cross-platform GUI apps that can run without an internet connection? I was thinking maybe making it a webapp, but the offline requirement seems to rule that out. (Has localstorage progressed to the point where people can start up a browser "app" without an internet connection? I haven't looked into it for awhile.)
Plus I'm not sure how easy it is to write custom webapp GUI objects compared to the fantastic ease of writing custom .NET GUI objects via the VS GUI designer. Although anything that lets you quickly and easily write powerful GUI apps that run on all three platforms would be pretty fantastic. What toolset would you use to get the job done?
EDIT: Hmm, just thought of another idea... Would Clojure work well for writing native GUI apps? It's based on the JVM, so it seems like it could leverage existing GUI libraries. (All the Java GUI libs used to suck, but maybe the situation's improved now that Clojure is popular.)