Hacker News Reader

Comment by xcambar | Hacker News Reader

From the website:

> 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.

View on HN

The main cross platform open source offerings are GTK and QT.

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.

> There are lightweight electron alternatives

The very definition of an oxymoron... ;)

Why is that an oxymoron?

Because electron consumes CPU cycles and RAM like there's no tomorrow.

Which is the very reason alternatives to Electron, that are more lightweight exist, of course.

I suspect a parse error somewhere.

Indeed, the person you're replying may have experienced a parse error, but this isn't the same person as the one who claimed it's an oxymoron.

Maybe they made that claim because an alternative to Electron probably still uses HTML5 and JavaScript, and HTML5 and JavaScript are huge so it's hard to believe such a thing could be lightweight.

Anyone who says "JavaScript" is "huge" needs to be asked to both qualify and then substantiate the claim (along with the implicit suggestion that they have any idea what they're talking about, instead of just trying to participate in the pile-on with cheap remarks).

There's javascript runtimes for MCUs with <16MB of RAM (no, they are not the same as V8 in Chrome/Node/Electron, but that's the point: large range with many possible solution sizes)

Qt (and not QT) is licensed under LGPL3 and GTK is licensed under 2 and later. So if you are not compiling a proprietary application on embedded device, it doesn't make any difference.

> There are lightweight electron alternatives

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.

I was thinking of sciter (5mb) and another similar crate that I can't remember the name for

That's about one order of magnitude smaller than Electron. Good to know.

My gtk-rs project is intended to replace a small, self contained win32 application. The application is 132KB. So although 5MB is small it's an oom larger than my benchmark.

However, my gtk-rs hello, world GUI application is 14.6MB in release mode and that does not include the GTK DLLs that are also needed. Yikes. That's crazy.

Perhaps 5MB is a reasonable price to pay for cross platform GUI. Not taking 7+ seconds to build a GUI hello, world would be nice as well.

There's also https://tauri.studio, which uses Chromium Edge on Windows and WebKit on Linux and macOS. You can get ~2MB binaries with it.

(that's a Rust-specific framework, but the underlying webview library is just a C library)

> The main cross platform open source offerings are GTK and Qt.

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.

Yeah good point, I forgot about wxWidgets - wanted to use it but the rust bindings didn't look maintained.

I think you forgot Swing and JavaFX. Both are cross platform, stable, backwards compatible for years and open source.

Ardour (0) continues to use GTK2 as a cross-platform GUI toolkit for Linux, Windows, macOS (as well as Solaris/netBSD/FreeBSD). There are a few tricky issues on macOS and Windows, but when I've spoken to people with large cross-platform code bases built on Qt, it seems no better or worse than the case there.

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

and we have no wish to reimplement these (TreeViews in GTK involve basically the entire toolkit). We slowly move towards a future vision based just on GDK (the lowest levels of GTK) but I doubt we will ever fully be able to drop the higher levels entirely.

(0) https://ardour.org/

Heh, I share the sentiment - Qt's tree widget is my n°1 reason for using it

How I wish there was a clean Swing implementation of the treetable widget/pattern in swing. JXTreetable makes me sad and wince everytime I have to open up the code. Cell renderers are OK... Until you want to go custom and synchronize events & drawing between renderers and you want them all coherent... And don't get me started on LnF and their interactions with JxTreetable... I know I should just shut up and go build mine own but this seems like such an oversight.

I hope eventually I can find the time to contribute some kind of graphics enhancements to ardour. (Maybe this means using GPU acceleration or using a newer GDK version, I don't know) I've noticed scrolling the view can get somewhat laggy on my system when there are a lot of tracks.

Edit > Preferences > Appearance > [ ] Disable Graphics Hardware Acceleration

Edit > Preferences > Appearance > [ ] Possibly Improve Slow Graphics Performance

We will not be moving to a new version of GDK at any time in the foreseeable future.

The first option seems to be misnamed. When it's disabled it will cache the canvas widgets in cairo surfaces, but it will still use CPU blitting when it actually copies the image back to the window.

I couldn't find the second option, even grepping for it in git master.

Two things:

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.

> 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?"

Are you using another language for your app, or is your entire stack in Dart and not just the UI?

Oh; it's all client-only (GUI) right now. So I've only been using Dart in this app (stack), if I need to add server components (which eventually I likely will) I'll write those in Elixir and/or Rust (i.e. languages I already know).

Nothing against the idea of server-side Dart, I just don't see a reason to bother with it. I've never really been sold on the idea of using the "same language" for both frontend and backend. I (try to) prefer the right tool for the job; which for my requirements, this time, is mostly how I ended up with Dart and Flutter... and I've been pleasantly surprised. It is the first cross-platform desktop language & sdk pairing I've used that I, personally, don't totally hate. Every other time, I've just said "fuck this" and gone and implemented it whatever the native SDKs were.

What do you dislike about Dart? I happen to like it a lot.

Oh, I don't mean I hate Dart by any means, I've just written UIs in a lot of languages at this point and would rather use something I'm more familiar with... The one very minor annoyance I've had with Dart that immediately pops to mind, and I think is going to be fixed soon (according to the github issue), is typedefs only working for functions. I personally think it makes things a lot more verbose and unnecessarily difficult to read at times ¯\_(ツ)_/¯

I certainly like it well enough to continue to learn and use both it and Flutter :)

Something that does bother me is the concept of Isolates vs actual multithreading.

It makes me wonder if the message-passing system may have performance concerns.

Qt is the main alternative. It's C++ but has bindings for many languages.

All cross platform frameworks are a compromise though so you should avoid them unless you know you will definitely need it.

For what it's worth, GTK and Qt (while being cross platform) are also effectively the native toolkits on Linux. So if you're developing for Linux in the first place, you get the cross platform bit for free.

Of course it also means extra effort to make them less alien on MacOS and Windows.

While less than popular, I'm more inclined to just target Electron or Carlo and leave it at that for my UIs. I know that it's much higher overhead, and if I was doing something with a minimal UI, or something that persisted in a tray I'd probably reach for something more minimal. It really depends on the use case.

React Native options may be another target that I might look into if I needed native, thought he UI kits aren't quite as interoperable as I'd necessarily like, it's a pretty decent option.

I mostly do full-stack service layers with react/web ui these days so anything that leans on what I already do is likely the best use of my time. A browser surface, while massive, memory hungry etc, is still often the best option for any app UI work as it solves so many issues and can run everywhere. It's the combination of those two that make it so appealing. Reducing friction. Of course it's also why we have mobile devices with 4gb+ ram on them these days.

edit: would also consider uno with .Net 5 - https://platform.uno/

I look at my Windows 10 desktop and you know what? Everything is alien. Even Microsoft's own stuff doesn't feel native any longer. Every program I care about is based on some widget tookit/framework that isn't now and probably never will be whatever Microsoft is pushing this year, and Microsoft's own software spans some unknown number of GUI evolution phases as well.

I used to think there was value in being well aligned with the native Desktop UI. Now I don't really know what that is any more and I no longer really care. I care that a given application serves it purpose and the degree of an application's alignment with the latest native UI trend is well down on my list of concerns. Coping with the delta between applications is a small problem I try not to get hung up on.

The same thing is happening to macOS. Big Sur is sealing the deal with a mishmash of iOS styles inconsistently applied across the desktop.

I was always a huge believer in native UI, following the platform HIG, never reinventing controls just to satisfy graphic design caprices; but Apple has essentially given up on these things.

The Mac UI is now just Windows 10 with rounded corners instead of sharp.

Well that's 0 for 3 then. Linux has always exhibited this 'problem.' Windows is effectively at parity with Linux now, and you point out the increasing divergence of even macOS.

What shall we conclude from all of this? I propose that simultaneously expecting a) an operating system to host a limitless diversity of graphical applications with origins that transcend platforms, programming paradigms and decades and b) that they all precisely align with your chosen operating systems ever changing GUI conventions and c) all of this be delivered at at least affordable if not no cost -- is simply unreasonable.

I suppose you could argue having a common style between macOS and iOS is more consistent. I'm still undecided about the new style in Big Sur. On the other hand I spend a lot of time in Windows and find the whole UI grating.

s/alien/fugly/g

Tk (https://en.wikipedia.org/wiki/Tk_(software)) is an older, but still quite viable option for a multi-platform GUI.

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

I was pretty happy to port some small Go programs using Gtk from Linux to the Mac. Just a recompile would do, worked out of the box.

what library did you use for Gtk with Go?

gotk3 is the goto package for using GTK

thanks!

Yes, I was using it.

How large is GTK this way? I like Qt, but adding 50-100MB library is a bit of an issue for small tools.

I do not have first hand experience with distributing GTK apps on non-Linux systems, but I do know that:

* 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'm a big fan of using plain SWT[1] without JFace. In fact GTK4 support is already being work on!

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....

[7]https://github.com/mbarbeaux/graalvm-swt-native-image

Curious - why would anyone choose SWT over Swing/JavaFX?

It used to be that Swing/AWT really sucked. The default theme on every platform (Metal) was really ugly. Everything was purple. The "native" look and feel was emulated (poorly). It was also very slow. That's the reasons why SWT was started in the first place. Swing would just not cut it for any app that wanted a nice UI.

Nowadays the situation is completely different. Swing looks and performs great compared to SWT. IMO it would make much more sense to just use Swing.

JavaFX never happened. People just went web instead. No one uses it and it's officially deprecated.

JavaFX was split out from the JRE and is now its own package[1]. It very much "happened" and there are plenty[2] of people using it.

If you are looking to build a fully themed app similar to a web app Swing or JavaFX are definitely the way to go. Swing still uses an emulated native look and feel and it is pretty decent. If you are planning on building something with real platform UI I would still go with SWT, especially if accessibility is on the table.

[1]https://openjfx.io [2]https://github.com/search?q=javafx&ref=simplesearch

JavaFX may be the most feature complete cross platform GUI framework after Qt. I have recently used it for a project and it tuned out much better than if I had used Swing.

> his should allow you to develop a nice little statically link executable instead of deploying a jar if needed.

To save me the clone/compilation time, any approximate numbers of how small the binary is for a SWT app?

A super simple test on Ubuntu I did back in November got me a 14mb executable consuming about 23mb of ram and about 38mb once the app was full screened. I'm pretty happy with the size considering the smallest runtime I can get with jlink around 40mb. I have also found GraalVM devs to be very responsive to issues on Github.

I should note I am using Haxe here instead of pure Java, so a pure Java app might be a few kilobytes smaller.

Screenshot: https://imgur.com/3otiHA2

I've worked professionally on a fairly large SWT-based project. This project was started when Swing was slow and ugly so SWT probably seemed fresh. Also, having a native L&F was important in those days.

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.

I haven't found the Layout system to be lacking or too difficult to deal with. My only issue with it is how verbose it feels sometimes. The operation of layout and layoutData can be a bit confusing.

You can always roll your own layout system using Control setBounds and moveAbove. I have toyed around with a custom layout system on top of SWT that uses Cassowary Constraints (in fact the imgur link in my other comment shows a sample).

As for custom widgets it really depends on how you want to do it since there are so many options. SWT can embed Swing or JavaFX components, so it allows the developer to make custom widgets in whichever tech they feel most comfortable. In this case I would stick with Swing since JavaFx can be a decently sized dependency, where as Swing is built into the jre.

The eclipse nebula project is also a pretty big repository of community made custom widgets. These can be really helpful for figuring out how to implement custom widgets in pure SWT. https://github.com/eclipse/nebula

I have never implemented automated testing with it though, bummer it was such a hassle.

Also SWT does grant access to a bit more of the underlying OS than Swing does with its org.eclipse.swt.internal.* package. For example I've had to embed a GLFW window inside a SWT window. This is done with the following api in GLFW: https://www.glfw.org/docs/3.3/group__native.html

Using the internal apis you to map GLFWs native window handle to something SWT understands pretty easily. Then it's just a matter of writing the platform specific code to reparent the GLFW window into App which was 3 or 4 lines of code per platform. Then once the GLFW app was inside the SWT App it was a matter of creating a dummy Composite that when resized would overlay the GLFW app. I don't believe this would have been possible in Swing without addition JNI. I know this is a pretty obscure use case, but the internal package can be extremely handy.

Lastly, SWT has a built in browser component that uses the OSs browser or there are optional embedded V8 and webkit packages. The feature set of SWT just blows other Java toolkits out of the water. Unfortunately, this does lead it to be a bit more complicated than the others. I'm sorry about your experience, but give it another whirl sometime maybe you'll be pleasantly surprised.

GTK 3 worked pretty well for a side project on Linux and macOS. I like C, so I went with GTK as opposed to C++ with Qt.

I suspect that Qt is a slightly better (both look and dev ergonomics) and more portable solution, but not sure.

wxWidgets uses the operating system's native widgets, is cross-platform, and has bindings for most languages.

If anyone has used GTK in their Windows applications, I'd love to hear about it.

Yet so many wxWidgets apps end up looking like Audacity - completely foreign on every platform.

Is that because audacity does their own weird buttons and controls and drop-down menus etc?

I went digging a bit, and there's work being done to making it possible to use react-native for cross-platform desktop apps too: https://github.com/status-im/react-native-desktop-qt Doesn't look production-ready yet, but seems promising.

wxwidgets is reasonable

I am also looking at the same question. JavaFX remains a viable choice, and perhaps Xamarin could be another option as well.

I've been pleasantly surprised with JavaFX as a student. Although I haven't built anything that's beautiful with it.

Flutter[0] is also very promising. It's like Qt but simpler and more productive. I've already used it in mobile apps and it's great.

[0] https://medium.com/flutter/announcing-flutter-linux-alpha-wi...

Reply on news.ycombinator.com