> GTK is the core of the GNOME development platform, but it can also be used to write applications for other Linux environments, as well as applications targeting Microsoft Windows and Apple macOS.
I'd love for some hn folks to share feedback on portability and overall value of using GTK for multiple platforms.
What other engines/platforms exist? I know of Kotlin for mobile/web but besides Electron, I'll have a hard time picking something for desktop apps, should portability be a requirement...
PS: I have a love-hate relationship with Electron. I guess I'm not the only one, so I won't elaborate.
There are lightweight electron alternatives - HTML/CSS engines with a scripting DSL. Sciter is a paid option but I know there are free options depending on your language of choice
I’ve been working on a cross platform music player and went with GTK over QT because I preferred the Rust bindings, QT seemed to have a lot of non UI code I didn’t need, and I was skeptical of dealing with QT licenses (but a lot of people seem to work with it just fine - I just didn’t put the research in to see if it was right for me).
Compiling linux / mac was very easy for me. Cross compiling linux -> windows via mingw64 was also pretty easy. I had some trouble compiling mingw64 on windows, but that was due to SQLite / MSys issues that I never really figured out.
Not really. Gtk UX just isn't an acceptable standard outside Gnome and seems to have approximately ~nil cross-platform share apart from GIMP and perhaps one or two more apps. There are really only two cross-platform toolkits that enable an acceptable level of UX: Qt Widgets and wxWidgets. wx has a smaller and generally more limited selection of widgets and some quibbles (awkward APIs, poor rich text support, docs aren't that great), while Qt Widgets is more on the "does it all" side of things, but that means it's less simple. E.g. a model-backed list is pretty darn simple in wx, but wx is also quite limited. Meanwhile Qt requires you to understand a relatively large model API and more code for basic models, but on the flipside it's also much more powerful. For anti-bloaters, Qt has a larger binary size than wx. wx has a bunch of stuff that only works on one platform or the other and there are a number of behavioral differences as well, since it mostly wraps an underlying toolkit. Qt tends to have largely uniform behavior and features across all platforms.
FWIW all of these (Qt, wxWidgets, Gtk) are LGPL.
Are there? I know of alternatives, but none that are particularly 'lightweight.'
I started a new project based on gtk-rs for exactly the same reasons as you.
The very definition of an oxymoron... ;)
We would like to move away from all desktop toolkits in theory (GTK and Qt as the prime examples) because they really don't offer us a lot. Unfortunately, they do offer:
1. Treeviews
2. File Selector
3. Text Entry
4. Menus
1.) I've written only a little bit using GTK, starting over this past month, and it has been very pleasant. The real issue I have is not knowing what documentation to use, or being a bit confused by the tooling. The existing open source projects using GTK I've been poking at over the last month written using JavaScript, Python, or C are all pretty (relatively) easy to grok and start working on. I'll definitely be back for more... FWIW- I do tend to learn by reading code; so for me, jumping into something totally foreign or unknown is pretty normal.
2.) I'd highly recommend trying Flutter+Dart for cross platform desktop applications. I've been writing my first, for about a month now, on Linux, and it has been fucking great mostly because it works. It uses Skia under the hood so rendering is fast and applications aren't totally bloated. I can speak nothing to building Flutter projects for the mobile or web variants but it seems neat in theory.
I'd definitely prefer to not write Dart, but I also accepted long ago, when you want to write GUI you pretty much have to learn a new language. It's close enough to JavaScript and/or Java learning it is pretty much just figuring out "WTF? Is X called?"
It's also a lot nicer, IMHO, than things like Electron because there's an actually useful SDK [1]. Electron, like the web, will require to you DIY a lot of really boring shit like wiring up list views to only use/reuse the displayed elements. Flutter, like most desktop GUI SDKs, brings a useful set of widgets to the table you can easily customize.
[1] No hate on Electron here; there's zero fault to be had for the web SDKs lacking useful APIs for making web apps... but that's a wholly different conversation I'd rather not have right meow.
Are you using another language for your app, or is your entire stack in Dart and not just the UI?
All cross platform frameworks are a compromise though so you should avoid them unless you know you will definitely need it.
Tk has language bindings for Tcl, C, C++, Ada, Common Lisp, Perl, Python, Ruby, Haskell, etc.
Tk also provides the standard GUI framework for Python: https://docs.python.org/3/library/tk.html
* Inkscape has a macOS version that looks, feels, and functions fairly nicely
* Documentation for how to ship a GTK app for macOS is severely lacking (not sure about Windows)
* Many cross platform apps choose Qt over GTK
I tend to see a lot of developers think of Eclipse Platform UI/JFace[2] when they see SWT. Eclipse Platform UI is Eclipse's abstraction over SWT that allows them to make consistent components across platforms. SWT is lighter weight and it's just platform native components. Also since you are dealing with native components you get easy access to platform accessibility.
Eclipse has some great documentation for the platform as well as loads of snippets[3] and examples[4] to pick apart.
There is also an incredibly useful charting library[5] that is used heavily by OpenChrom(Uses Eclipse platform)[6].
I have only tried it with some small samples, but SWT does work with GraalVM native-image[7]. This should allow you to develop a nice little statically link executable instead of deploying a jar if needed.
[1]https://www.eclipse.org/swt/
https://github.com/eclipse/eclipse.platform.swt/tree/master/...
[2]https://github.com/eclipse/eclipse.platform.ui
[3]https://www.eclipse.org/swt/snippets/
[4]https://github.com/eclipse/eclipse.platform.swt/tree/master/...
[5]https://github.com/eclipse/swtchart
[6]https://lablicate.com/platform/openchrom
https://lablicate.com/static/media/openchrom-GC-MS.722d5aa3....
We had tons of problems and they where almost never easy to fix. Layouting in SWT is hard. Custom widgets are hard. SWT did not play nice with Swing/AWT on Linux so it would crash if you needed to use both. I remember I spent a lot of time getting automated testing working reliably (on mac) but eventually just gave up.
Things might have improved since I worked on this 7 years ago but I would not bet on it. SWT is basically a support library for Eclipse and therefore Eclipse is more or less the sole driver for any development.
I would rather just use Swing. Compared to when SWT was started Swing has evolved a lot and IMO the rationale for going with SWT does not exist anymore.
To save me the clone/compilation time, any approximate numbers of how small the binary is for a SWT app?
I suspect that Qt is a slightly better (both look and dev ergonomics) and more portable solution, but not sure.
If anyone has used GTK in their Windows applications, I'd love to hear about it.
[0] https://medium.com/flutter/announcing-flutter-linux-alpha-wi...
I understand breaking backwards compatibility a first time, maybe out of a failure to plan ahead, but not multiple times.
It would be easy enough to add new subroutines to add more functionality. Is there a reason to change or remove old subroutines of which I’m not aware? Otherwise this is just causing extra work for application developers for no good reason and in many cases killing old stable applications which are no longer developed.
Of course they do not have to care about backwards compatibility since GTK is just a library that happens to be popular enough to be widely available but not really part of any platform. The OS itself (Linux) is binary compatible going back decades.
It is a bit frustrating though, but really if you want a stable GUI API either write against pure xlib or use something like Motif which even though it barely gets any updates probably wont go away any time soon as it is used in several long standing scientific and enterprise applications (ie. the unsexy stuff you rarely hear about but still work behind the scenes).
It might be interesting to see what it'd take to make Motif a bit more themeable though.
Jumping to pure Xlib or Motif is a bit beside the point, to that end you might as well use GTK1 or GTK2 if you don't mind using an old stable API that is not really being updated anymore.
At this point I cannot imagine a sane third party application developer choosing to build on top of GTK. The clock starts ticking on the life of your application the moment you choose GTK.
Microsoft has introduced just as many new toolkits during the same time, but nobody expects WinForms to be backwards compatible with MFC.
That would have given application developers a better chance to keep maintaining the toolkit long after GTK developers lost interest.
If it's too much work for application developers, the can keep on an old version of the library or maintain a shim. (There are still a lot of GTK2 applications out there, although distros seem to be removing them because nobody is interested in maintaining a shim or backporting things)
https://github.com/libguestfs/virt-p2v/blob/master/gui-gtk2-...
https://github.com/libguestfs/virt-p2v/blob/master/gui-gtk3-...
And that's just one very small and limited application.
One of the main reasons we abandoned Pinta (https://github.com/PintaProject/Pinta) is we had to rewrite a significant portion of the app if we wanted to move to GTK3, as we had many custom UI needs.
See also: GIMP, still on GTK2. Inkscape released on GTK3 just within the past year or 2
The price of backwards compatibility is keeping backward design. Microsoft stated a few times that they couldn't keep the exact interfaces of Win32 without leaving security problems inherent in the mis-design of original interfaces. I have no idea if they intentionally broke the interfaces, but Wine is sometimes more compatible with old win32 than windows.
And for older games there are often alternatives in Windows (e.g. dgVoodoo2 which reimplements older DirectX and Glide versions under Direct3D 11 and i think nowadays 12) that provide even better compatibility and features.
You can run two applications with GTK3 and GTK4, and maybe 10 years into the future GTK10 in parallel. They will just look different, but nothing else will change. It's not as if the old application built with GTK3 will crash or not start.
But if you break the Win32 API, a whole lot of desktop applications will crash.
My 20 year old projects run perfectly on Linux with WINE
Now there is Lazarus to port Delphi code to a native Linux version, but it is using GTK2 and that is running much worse. (or through qt4 but that is even worse) The good thing is, if Lazarus gets a GTK3/4 update, my old code is supposed to run on the new GTK unchanged. The bad thing is, Lazarus is not popular so hardly anyone is working on those updates.
The parent thread is comparing a runtime API (Win32) with a compile-time library (GTK).
Binary compatibility is mostly irrelevant, any sane distribution scheme is based on static binaries.
Now, breaking source backwards compatibility is a real tragedy.
because otherwise I'm still going to go out of my way to avoid using anything based on GTK
At the time it did look somewhat dire.
Important note from Bryce Harrington:
[On a personal note, this will be my last release for Cairo. My Cairo time availability has been non-existent (particularly this crazy past year). The release process is well documented and hopefully will help whomever picks up the baton from here.]
Looks like that the situation was mitigated for this release, but the situation will be more dire the next time someone needs a new Cairo release cut.
