Writing Tiny Desktop Apps in C and GTK3 (2022)
danielc.dev
danielc.dev
Ok thats clear. But then ten sentences later:
> Of course, you aren't going to write your UI in C, only an idiot would do that. Instead, you want to write it in some kind of markup language.
Now, let me think of some markup language that is universally known and has at least some pretence to be about laying out information on a screen... Thats right, html.
The thing with UI frameworks in the 21st century of flying cars, AGI and rapidly approaching Singularity, is that its a stagnating mess.
There should be a nice, standardized, cross-platform, easy to get started and progressively expandable way to build high quality visual apps. For some elusive reason, we cant have good things.
Does that mean SMTP and related email protocols succeeded simply because they were really early in the Internet game?
Sure, if you have low standards for UI.
Ultimately making decent UI experiences cross-platform is impossible without some sort of catering to each platform that HTML/JS largely has no access to.
React-native has made some headway here, as have electron + native bindings. But neither are really capable at this point of reproducing apps that clearly excel at leveraging platform-native frameworks.
Aside from that, instead of writing a GNOME app in C, isn't Vala or GJS the preferred language now?
The same is true for a lot of languages and frameworks: Programming education, and tutorials on the Internet, start with Hello World and stop at some very small, trivial application with the complexity of about 1-4 source files. Final class: How to write a notepad-like application, or a TODO list with check boxes. There are a lot of resources that get you started but very little about how you'd approach what would turn into a medium-sized or large application, with hundreds of source files and many third party dependencies.
I would recommend looking at the GNOME apps and picking one that is written in the language that you want to use.
(Note: I'm not saying anything about this specific code, which I have not looked at)
Apple isn't going to follow (or cooperate) with anybody, and that's fine. Frankly, I find it really, really dumb that everyone doesn't just implement Cocoa already, even if only in order to provide a lowest common denominator.
(Don't try to sell me on the virtues of Qt. Enough already. Qt fans seem to be afflicted with real problems concerning the ability to come to grips with the shortcomings of Qt.)
To be fair, as you say, Qt definitely has shortcomings and some things I don't like. If you're trying to minimize your disk space footprint, it's hard to get anything under 50MB with Qt. The difficulty of navigating the licensing for a closed-source app is (while often exaggerated) quite real, especially for someone using Qt for the first time. And while I understand why they did it, it's often annoying to have to use the Qt equivalents of standard library types (e.g., don't use std::string...use QString! don't use int64_t...use qint64! etc.)
The problem is there really just isn't a perfect library or tool for building desktop apps, and writing your own would be...a lot of work. I share the linked post's distaste for Electron, which without a lot of work tends to result in horribly bloated software (often very nice look and feel, but bloated just the same). GTK sounds nice in principle, but you very quickly find yourself missing all of the functionality built into Qt. So Qt often for me ends up being like what someone once said about democracy: it's the worst system EXCEPT for all the other alternatives we've tried from time to time...all of which are worse.
The open-source Qt is licensed under LGPL. It's not really a mystery. I've built a proprietary app[1] on top of that, and as I explained in my blog post[2], the LGPL allows you to statically link your executable as long as you provide the object files and allow users to relink your app with a different version of Qt.
There's also a lot you can do to drastically limit your binary size. I wrote a little about it on my blog post but haven't experimented that much with it yet. Things like: 1. Compiling Qt from source with only the specific modules needed and using static linking. 2. Use the -optimize-size flag and Link Time Optamization flag -ltcg. 3. Running strip on the resulting executable to remove unused symbols. 4. Use UPX to compress the executable.
BTW, Qt can look very native, if you know how to use it properly (I wish to make it more commoditized!), for example, something I'm cooking at the moment:
Windows: https://imgur.com/8lT0u24
macOS: https://imgur.com/a/GKWSDaK
I also think that the vast majority of people that complain about the lack of "native look" are bad takes from people that don't actually ship apps professionally and listen to their customers. End-users don't actually care and it really simplifies things a lot to do it the way they are. wxWidgets uses platform native APIs and I would argue that it looks much worse (and old) compared to Qt.
One thing I will say though is that the fact that Qt specifically now uses LGPL version 3 as opposed to v2 (switched in 5.6 I think), can actually be quite significant and a non-starter for some people. If you're developing something where Qt is embedded fairly deep in to the system, especially if it's a critical system, you don't want to have to give the user the ability to swap out your Qt library with who-knows-what and now all your safety testing/validation/warranties etc. are void... which I guess for bigger companies they just buy a commercial license in that case.
Yep, I agree. And I hope so too.
> I also think that the vast majority of people that complain about the lack of "native look" are bad takes from people that don't actually ship apps professionally and listen to their customers
Ding ding ding. Exactly. I would argue that most Qt developers aren't targeting the same audience that native iOS developers target, for example, which causes all Qt apps in the wild to look embarrassingly ugly and out of place. The Qt Company's own lack of taste in design (and their examples) doesn't contribute. It's only when developers with a strong taste for aesthetics and for creating experiences that delights people will take on Qt to develop apps, we will see and be able to show the world the power of Qt. I hope to be part of this change, I'm trying to push Qt limits with every new app I make. And honestly, QML is just an amazing joy to program in. Here's a cool window animation you can do in 1 minute using QML:
https://custom-downloads.s3.us-west-2.amazonaws.com/qml-anim...
What we also need is to create a set of beautiful, easy to use components that work out-of-the-box for developers to tinker with. This is very lacking in the Qt ecosystem compared to other frameworks.
The gist I'm trying to get at is that Qt is not the limiting factor, the limiting factor are developers whose both their target users don't care about aesthetics (or so they think), and developers who themselves lack a good taste (or the know how) for good design.
Not sure about the difference between LGPL v2 and v3, but like you said, if you're a big company, paying for the license is a non-starter (and also helps fund Qt development so why not?), but for almost all developers the LGPL version should be more than enough.
I've got a medium sized hobby project I work on that has a macOS and iOS version, separate GUIs, but sharing a lot of underlying code. Every once in a while, I think to myself "It would be nice to port this to Windows and Linux, just for the fun of it" and it always goes this way:
I end up reaching for Qt, but getting absolutely mired in things like: creating the .ui file in Qt Designer, making each screen and dialog equal to the original macOS app in features, converting things back and forth to QStrings and QObjects and QThis and QThat, cobbling together UI logic from scratch that we just get for free from Cocoa like bindings and connecting events to Objective C methods.
Then, when I'm absolutely not having fun here, I'll tell myself "OK, let's just create a native Windows application. Hmm, what's the recommended idiomatic windows way to create an application these days? Is it Win32 still? No, is it WPF? Is it UWP? Is it WinForms? Should I use C# and .NET or not? Before I even write a line of code, I'm already exhausted and demoralized.
Then I think, fuck it, let's start playing with Javascript and electron and all these other things that I only read about on HN but never learned or dove into. By the time I'm done yak shaving to get an environment set up and going through "How to declare a variable" tutorials, I'm wondering why not just add some fun features to the macOS app instead...
You mean all the other OS's reverse engineering Cocoa? That exists, more or less, in the form of GNUstep. There are good reasons why GNUstep isn't heavily used: it doesn't feel native anywhere but macOS, macOS apps tend to use a lot of OS APIs (e.g. Metal) that are outside Cocoa so just implementing Cocoa doesn't buy you much, Objective-C isn't that productive of a language by modern standards, etc.
More realistic, honestly, would be for everyone to implement Win32 as a lowest common denominator, which is kind of the world we live in already thanks to Wine.
I mean the mainstream toolkits and their vendors all providing a Cocoa-shaped API that solves the problem described in the article and solved in a way that is relevant to the context.
> it doesn't feel native anywhere but macOS
"even if only in order to provide a lowest common denominator"
See also the alternative we're talking about: Electron—how native does it feel?
> macOS apps tend to use a lot of OS APIs (e.g. Metal) that are outside Cocoa
You're moving the goalposts.
> Objective-C isn't that productive of a language by modern standards
I never mentioned Objective-C.