openrisk 3 days ago | next |

> You'd better not dare write your desktop application in HTML. What has this world come to???

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.

lylejantzi3rd 3 days ago | root | parent | next |

Maybe we should revisit the idea of a RAD IDE built on top of video game libraries, like raylib. Video games don't have a problem with cross-platform UI.

Santosh83 3 days ago | root | parent | prev | next |

Nothing elusive. The reason is major vendors are not cooperating for even a common baseline standard. Its not impossible. They do it with Whatwg, but when it comes to native apps everyone and his dog head off in their own NIH incompatible direction. Just goes to show that social & economic problems are harder than flying cars and the singularity.

abnercoimbre 3 days ago | root | parent |

> Just goes to show that social & economic problems are harder

Does that mean SMTP and related email protocols succeeded simply because they were really early in the Internet game?

PittleyDunkin 3 days ago | root | parent | prev |

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

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.

plowjockey 6 days ago | prev | next |

Trivial examples of Gtk+ apps seem to be legion but to find a decent tutorial that works its way through a moderately complex and usable app seem to be scarce. In particular I haven't found a decent example of using the GTKBuilder class and complete documentation of the XML properties seems almost nonexistent.

Aside from that, instead of writing a GNOME app in C, isn't Vala or GJS the preferred language now?

imtringued 5 days ago | root | parent | next |

I wanted to try and follow this blog, but write the app in Vala and I haven't figured out how to use gtk4 with meson yet. I personally want to build a nautilus extension, but that seems very far off considering the sorry state of their documentation.

ryandrake 3 days ago | root | parent | prev | next |

> Trivial examples of Gtk+ apps seem to be legion but to find a decent tutorial that works its way through a moderately complex and usable app seem to be scarce.

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.

senkora 3 days ago | root | parent | prev |

GObjectIntrospection is very good, so GTK has usable bindings to essentially every language.

I would recommend looking at the GNOME apps and picking one that is written in the language that you want to use.

nopelynopington 6 days ago | prev | next |

Nice post but the images don't load for me

hk1337 3 days ago | root | parent | next |

It appears to be using some sort of encrypted file uploading service that has gone offline.

https://github.com/petabyt/eggnog

https://eggnog.theres.life

cxr 3 days ago | prev | next |

The author complains about Electron, but even setting aside programmers who choose it only because NPM is all they know, there are legitimate grievances to be had about desktop vendors' lack of coalescing around a common set of APIs.

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

jlparkinson1 3 days ago | root | parent | next |

Funny...I was just coming here to talk about 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.

rubymamis 3 days ago | root | parent | next |

Just wanted to let you know it's not all gray in Qt land.

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

[1] https://get-notes.com

[2] https://rubymamistvalove.com/block-editor#10-qt-license

ranger_danger 3 days ago | root | parent |

Heavy Qt user here... I agree with everything you said. I think a lot of people are rightfully confused about the licensing because I think the Qt Company is vague about it on purpose, they want to sell licenses of course. I just hope their agreement with KDE never ends.

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.

rubymamis 3 days ago | root | parent |

> I think the Qt Company is vague about it on purpose, they want to sell licenses of course. I just hope their agreement with KDE never ends.

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.

ryandrake 3 days ago | root | parent | prev |

Yea, Qt is a pain, but so is any kind of porting work.

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

pcwalton 3 days ago | root | parent | prev | next |

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

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.

mwcampbell 12 hours ago | root | parent | next |

The best reason I can come up with to mimic Cocoa, rather than Win32, is that macOS users are the most... discerning about native versus non-native apps. So a Windows-first app on macOS will certainly be noticed, but that's not as true for a macOS-first app on Windows.

Tossrock 3 days ago | root | parent | prev | next |

A funny story: Ambrosia Software was, for many years, THE name in Mac gaming. Their biggest series was the Escape Velocity space sim titles. The final release in the series EV Nova, was popular enough to be released for Windows, as well. Years passed, Ambrosia went the way of the dodo, and now, if you try to run Nova on a modern Mac, it's basically impossible due to all the platform changes since the release... except by running the Windows version, via Wine.

cxr 3 days ago | root | parent | prev |

> You mean all the other OS's reverse engineering Cocoa?

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.