When you look at the Linux desktop software stack, I can't condemn anyone for choosing js+html+css over what's available.
There's no consistency between the dozen "toolkits", each one with its own way of doing things and a lack of interoperability. If you ever had to work with X11's concepts of drag'n'drop, windows, input etc. you probably know what I'm talking about. Dozens of toolkits, few of them talk to each other. It's a mess. Electron just works.
People who would have built a proper desktop application simply don't because the tooling, the environments, the standards (and lack thereof) are awful.
The whole concept of "toolkits" is what makes the situation a complete mess.
Admittedly (as a Plasma user) I'm a little biased here, but the answer is to just use Qt (Widgets) and move on. QGnomePlatform and QGTKStyle means Qt works just fine in a GTK-based desktop, while the reverse just isn't true.
Unless you have a good reason (in which case, you'll know), you can just ignore everything other that Qt and GTK.
It's not just about development, there are numerous applications built in different toolkits which many of us use everyday. Some of these apps are closed source, so suggesting a rewrite in Qt is out of question.
Don't get me wrong, it would be awesome if we could compromise on any given toolkit, but do you honestly see any of them waving the white flag?
Meanwhile, on Windows for example, there's a standard way to write GUI apps, standardized, well-known and consistent APIs to deal with GDI's toolkit etc. It's awful to write GTK apps just as it's painful to write in pure WINAPI GDI, but GDI has the advantage of being the default, so that "native look" is consistent across most applications since the 3.1 days.
Then comes the community: we have 20+ years of GUI programming happening on Windows, most people simply stick to GDI + self-made custom controls. The outcome is a huge knowledge base that helps get anything and everything done on Windows. Here in the UNIX world over the same time period the GUI developers are spread among different toolkits, so we have many "ok" people in a dozen toolkits and few experts on each one.
> Some of these apps are closed source, so suggesting a rewrite in Qt is out of question.
Qt is LGPL. So long as you dynamically link to Qt, it doesn't matter what license your app is under. If you don't dynamically link, you lose the integration benefits anyway, so there's no downside, really (Qt is backwards compatible within each major release, so just build against the earliest version of Qt 5 your app works with).
> GDI has the advantage of being the default, so that "native look" is consistent across most applications since the 3.1 days
History means we have two defaults on Linux: Qt and GTK. Qt integrates well in a GTK desktop though, so you can just use Qt.
> Don't get me wrong, it would be awesome if we could compromise on any given toolkit, but do you honestly see any of them waving the white flag?
No doubt it will be years before everything moves over, but at this point Qt is the clear winner: it's always looked better, its licensing issues are now solved, it's the only option that has remotely decent bindings for a remotely decent language. A month or so ago there was a new release of Wx and the comments here were universally "that still exists?"; GTK will go the same way.
There are other options, there are people who really like those options, but Qt has the momentum and has the knowledge base. Just use Qt and you'll be fine, or at least you'll be no less fine that you were with GDI on windows.
Sure I can use Qt. And deal with C++ and the MOC. Well, by C++ I mean whatever dialect of it Qt chose to support to be backwards compatible with apps from 1995, certainly not C++14 or even C++11 last time I looked and oh yeah - have to use their smart pointers and string/container classes, and learn yet another build system, Qmake was it? And use their “interface builder” and cheap looking Visual Studio knock-off?
Orrrrrrrr - JavaScript/Typescript with the amazing Chrome debugger and get my work done in half the time?
You’re really really not selling Qt at all, least of all to people who might have NodeJS (lots of those) experience and want to get something done quickly.
Yes I’m also aware of Qt’s 200 language bindings and funnily enough, a lot of shitty, slow, crash Qt apps on my Ubuntu desktop are Python with the PyQT bindings. Because even those guys want to get their job done quick.
So, basically - Electron seems like a really nice default choice.
> Yes I’m also aware of Qt’s 200 language bindings and funnily enough, a lot of shitty, slow, crash Qt apps on my Ubuntu desktop are Python with the PyQT bindings.
So much like Electron then?
Use Qt, use Python, and get on with your life. Or use Electron if you prefer, that's fine too. But don't make out like it's the only reasonable option and everything else is too confusing. If you ask 10 developers the right way to do a simple GUI application on Linux, 9 of them will tell you: do it with Qt and Python.
Moc integrates beautifully with cmake and "all" other build tools. There is no need for the interface builder (though I hear people seem to like it, barely tried it myself).
No need to use their smart pointers either, I certainly never have. Never saw any reason to since C++11.
Yes, I have. Here's some to name a few: GTK, Qt, wx, Fox, fltk...
Yes, I agree, Qt just works. My initial point was and still is about interoperability. They don't all speak well with each other and there are many good, useful applications in toolkits other than Qt or GTK.
What do you even mean by "they don't all speak with each other", what are they, and what can't they do (that electron can do?).
With Qt I can use the clipboard, sockets, and so on, set an icon for the application. Linux applications have standards to follow, as long as they do they look the same to the desktop environment.
Are electron apps magically able to speak with other electron apps, in a simpler way (to implement) than Qt applications? I don't think so.
That's not what i'm talking about. Qt is cross-platform after all. I'm saying there's no consistency in the concepts, how things are built. A Listview in GTK is very different from a Listview in Qt or wx, for example. They fire different events at different points of their cycles, they have different properties, different ways to be customized etc.
You can't, for example, simply fire Spy++ and check what a given widget is doing, as you can with GDI. The lack of a basic widget building block in X11 makes each one implement the very basics their own different way. And when they need to talk to each other, it's at the very least an unpleasant ordeal.
There's no consistency between the dozen "toolkits", each one with its own way of doing things and a lack of interoperability. If you ever had to work with X11's concepts of drag'n'drop, windows, input etc. you probably know what I'm talking about. Dozens of toolkits, few of them talk to each other. It's a mess. Electron just works.
People who would have built a proper desktop application simply don't because the tooling, the environments, the standards (and lack thereof) are awful.
The whole concept of "toolkits" is what makes the situation a complete mess.