Disclaimer: This is a personal web page. Contents written here do not represent the position of my employer.
Wednesday, January 23, 2019
WORA-WNLF
I started my career writing web applications. I had struggles with PHP web-frameworks, javascript libraries, and rendering differences (CSS and non-CSS glitches) across browsers. After leaving that world, I started focusing more on the backend side of things, fleeing from the frontend camp (mainly actually just scared of that abomination that was javascript; because, in my spare time, I still did things with frontends: I hacked on a GTK media player called Banshee and a GTK chat app called Smuxi).
So there you had me: a backend dev by day, desktop dev by night. But in the GTK world I had similar struggles as the ones I had as a frontend dev when the browsers wouldn’t behave in the same way. I’m talking about GTK bugs in other non-Linux OSs, i.e. Mac and Windows.
See, I wanted to bring a desktop app to the masses, but these problems (and others of different kinds) prevented me to do it. And while all this was happening, another major shift was happening as well: desktop environments were fading while mobile (and not so mobile: tablets!) platforms were rising in usage. This meant yet more platforms that I wished GTK supported. As I’m not a C language expert (nor I wanted to be), I kept googling for the terms “gtk” and “android” or “gtk” and “iOS”, to see if some hacker put something together that I could use. But that day never happened.
Plus, I started noticing a trend: big companies with important mobile apps started to stop using HTML5 within their apps in favour of native apps, mainly chasing the “native look & feel”. This meant, clearly, that even if someone cooked a hack that made gtk+ run in Android, it would still feel foreign, and nobody would dare to use it.
So I started to become a fan of abstraction layers that were a common denominator of different native toolkits and kept their native look&feel. For example, XWT, the widget toolkit that Mono uses in MonoDevelop to target all 3 toolkits depending on the platform: Cocoa (on macOS), Gtk (on Linux) and WPF (on Windows). Pretty cool hack if you ask me. But using this would contradict my desires of using a toolkit that would already support Android!
And there it was Xamarin.Forms, an abstraction layer between iOS, Android and WindowsPhone, but that didn’t support desktops. Plus, at the time, Xamarin was proprietary (and I didn’t want to get out of my open source world). It was a big dilemma.
But then, some years passed, and many events happened around Xamarin.Forms:
- Xamarin (the company) was bought by Microsoft and, at the same time, Xamarin (the product) was open sourced.
- Xamarin.Forms is opensource now (TBH not sure if it was proprietary before, or it was always opensource).
- Xamarin.Forms started supporting macOS and Windows UWP.
- Xamarin.Forms 3.0 included support for GTK and WPF.
So that was the last straw that made me switch completely all my desktop efforts toward Xamarin.Forms. Not only I can still target Linux+GTK (my favorite platform), I can also make my apps run in mobile platforms, and desktop OSs that most people use. So both my niche and mainstream covered! But this is not the end: Xamarin.Forms has been recently ported to Tizen too! (A Linux-based OS used by Samsung in SmartTVs and watches.)
Now let me ask you something. Do you know of any graphical toolkit that allows you to target 6 different platforms with the same codebase? I repeat: Linux(GTK), Windows(UWP/WPF), macOS, iOS, Android, Tizen. The old Java saying is finally here! (but for the frontend side): “write once, run anywhere” (WORA) to which I add “with native look’n’feel” (WORA-WNLF)
If you want to know who is the hero that made the GTK driver of Xamarin.Forms, follow @jsuarezruiz which BTW has been recently hired by Microsoft to work on their non-Windows IDE ;-)
PS: If you like .NET and GTK, my employer is also hiring! (remote positions might be available too) ping me
Labels: CSharp, General, Gnome, Ingenieria, Mono, Programacion, SoftwareLibre, Xamarin
# posted by knocte @ 8:55 am 
Comments:
<< Home
Now let me ask you something. Do you know of any graphical toolkit that allows you to target 6 different platforms with the same codebase?
Qt.
Qt.
# posted by 
: Wednesday, January 23, 2019 9:49:00 am
: Wednesday, January 23, 2019 9:49:00 am
"Do you know of any graphical toolkit that allows you to target 6 different platforms with the same codebase?"
Well, yes, way before that one ever hit six platforms we always had Qt that targets Linux, Windows, Mac, Android, iOS, Qnx, Tizen and a few more. I am a bit scared about desktop applications going the C# / .Net route (mostly because the runtime performance penalty)
Why not keep applications running native, without runtimes?
Well, yes, way before that one ever hit six platforms we always had Qt that targets Linux, Windows, Mac, Android, iOS, Qnx, Tizen and a few more. I am a bit scared about desktop applications going the C# / .Net route (mostly because the runtime performance penalty)
Why not keep applications running native, without runtimes?
That's not true, at all. I recomend you to watch Dirk Hohndel's awesome talk "From Gtk to Qt, a Strange Journey" where they also talk about having native look and feel was a choice for Qt.
https://www.youtube.com/watch?v=ON0A1dsQOV0&t=5s
Now I know that `it's not true, at all` is also not true as Qt doens't uses the native libraries but paints itself, but it has theme-plugins, so in windows it looks like windows, in mac it looks like mac, in linux it looks like Qt (as there's no default.)
https://www.youtube.com/watch?v=ON0A1dsQOV0&t=5s
Now I know that `it's not true, at all` is also not true as Qt doens't uses the native libraries but paints itself, but it has theme-plugins, so in windows it looks like windows, in mac it looks like mac, in linux it looks like Qt (as there's no default.)
Tomaz: you can compile .NET to native, it's called AOT. And Xamarin.Forms apps run this way in mobile (e.g. iOS).
Thanks for the link! I'll def. watch that talk.
But yeah with native I really meant "true native", so as to avoid any rendering bugs completely (which is the thing that I was referring to when I pointed out about GTK bugs in Windows/Mac).
Post a Comment
But yeah with native I really meant "true native", so as to avoid any rendering bugs completely (which is the thing that I was referring to when I pointed out about GTK bugs in Windows/Mac).
<< Home
