Yes, it is yet another Electron app.
I’ve often thought about making my own toolkit, but there’s so much that we forget about from things like focus to accessibility to text layout and rendering (much text has been rendered on why text rendering sucks). My hope is that Rust breathes new life into native (as opposed to electron) cross-platform GUIs, and indeed there are some interesting efforts underway.
You can't distribute a commercial, binary app for 'Linux' easily unless you statically link everything (which you cannot do with Qt without breaking the license) and compile on something ancient.
Even using something like Qt, writing a C++ GUI app for the 3 major platforms (macOS, Windows and Linux) is about 10x more work than getting something like Electron working and distributed.
In my case, I did most of my development for an embedded target, which meant my org shipped the entire OS and therefore we only had to worry about the packages we were shipping. Packaging wasn't much of a problem in that context, but it was still many times more effort than an Electron app--my issues tended to be related to tooling and language.
Well, this is GTK password manager https://gitlab.gnome.org/World/PasswordSafe - UI works really well, use it every day.
Guess GTK will be much more popular 'cause Qt LTS going to be proprietary.
The Qt approach with QML + JavaScript with a C++ backend worked in that regard quite well, expose low level system calls from C++ and call it from JavaScript, but QML had other issues.
And funny thing is that if you do JavaScript you can't escape that build step anyway when you use TypeScript, but there is hot reload at least.
One problem is that many GUI toolkits are not adopted for being consumed from a scripting language, bindings become complex and then needs to be constantly maintained.
I'm experimentering with the IUP GUI toolkit, a very well written toolkit in C. Designed from the beginning to able to be consumed by a scripting language, in this case Lua. So it doesn't rely on weird macros or overcomplicated structs, you work with opaque handles, this makes it easy to be called from any language that has FFI support, which makes bindings even easier. Unfortunately no MacOS support for IUP.
Perhaps rather than "bindings" you're thinking something like GTK and Qt's JavaScript integrations (embedded scripting languages vs bindings)? These are bummers in that they use some home-grown JS interpreter implementations which don't implement any standard version of JS (or at least not a very recent standard) and it's very confusing what is and isn't supported, and IIRC the docs aren't great here either.
1) Scripting language is still the driver of the application, it uses "bindings" against a GUI library to implement the application. This is the one I'm most interested in. And if you need low level stuff, you implement that as dll/so library and uses that from you scripting language.
What usually happens is that you need to read the GUI library C or C++ code and examples to understand it, because the bindings documentation is not enough, and then translate that to your scripting language, can become a bit tedious with trial and error if it not obvious how to do it.
XML as descriptive source sounds good in theory, that is why I'm somewhat intrigued by how Microsoft has done it the past with COM and now how they have expanded that with WinRT where you can implement language projections that can handle cross language types (projected types?) so you can get a natural interface in the language you are working in. But I'm not a .NET developer.
I think I looked at Go-Qt binding but if I remember correctly it was alpha and had problems. Python-Qt exist but I don't know much about it. Read somewhere that I was just easier to use C++ directly, less hassle, don't know if that is true.
Vala looks like a nice solution if you want to go full GTK. Problem with GTK is that it is not truly cross platform, Gnome team does not prioritize other platforms as Qt does. And GTK breaks existing functionality too, even between minor versions (still true?).
That is why I started too look at IUP, IUP uses GTK on Linux, but win32 on Windows. Tried to do a C++20 project with IUP, but gave up, even with all the new fancy stuff for C++ it is still awful, better yes, but same old problems are mostly there. When you are writing a GUI code you don't really care if your string is a const ref or pointer or what not, you spend the time on all the wrong things and C++ invites to think and micro optimize all those decisions(use or not use auto in for loop? how to write to best constructor? Optimal initializer?). Then before you know it you binge watch C++ talks with Nicolai Josuttis and have difficult sleeping at night. And if you go heavy into smart pointers, why not just use a GC:ed language to begin with? Qt solves that well with QString, QList etct, doesn't matter if pass by value or not, but then you need to handle qmake. I'm tired of awful build systems, they are everywhere, still scarred for life by cmake and when I tried CLion. Now I do things over FFI instead, sleeps much better.
2) Scripting language has "bindings" to a GUI application/framework, more of a plugin system. Gnome is a good example there, but as you say, different JavaScript engines between these "bindings", and for Gnome, poorly documented.
I think for Gnome and other desktops that uses this technique, it is in the right direction, but the quality of the plugins I have used is most of the time poor, memory leaks etc, you end up using just use the approved ones if you don't like to restart your desktop once a day. If that is because of poor bindings or poor plugin implementations I don't know.
Yes, this is very true.
> XML as descriptive source sounds good in theory,
Agreed, and it could probably work in practice with enough investment (ideally forego XML altogether in favor of a markup language that isn't hostile to humans and machines, document the schema thoroughly, provide reference implementations, etc).
> I think I looked at Go-Qt binding but if I remember correctly it was alpha and had problems. Python-Qt exist but I don't know much about it. Read somewhere that I was just easier to use C++ directly, less hassle, don't know if that is true.
Yeah, the Go-Qt binding was just incomplete. There was a Go/QML project early on, but I don't think it allowed for data to flow both directions, which seriously limited its utility and then it just kind of faded into obscurity. Pyqt (there was a competing Python/Qt binding as well, but I forget what it was) was okay, but again it didn't have very good documentation and it would still segfault all the time. One or both of the Python/Qt bindings were also poorly supported.
> Vala looks like a nice solution if you want to go full GTK.
I tried this as well, but it's a thin veneer over GObject and still has many of the same problems. It also lacks any kind of build tooling or package management, and again, it's not adequately invested in and the documentation is poor (or this was the case when I last tried it).
> I think for Gnome and other desktops that uses this technique, it is in the right direction, but the quality of the plugins I have used is most of the time poor, memory leaks etc, you end up using just use the approved ones if you don't like to restart your desktop once a day. If that is because of poor bindings or poor plugin implementations I don't know.
Agreed.
It may suit some people's taste, it is more open than Qt in some aspects and it has better language integration by virtue of being written in C.
But, as a Plasma/i3 user, I avoid GTK apps as much as possible. Thankfully At/KDE apps are plenty and fully functional.
- C++ dynamic linking used to be slower on Linux than C dynamic linking
- A lot of Linux die-hards are simply C++ haters
- Qt's licensing used to be unfavorable to purists, which lead directly to the Gnome-vs-KDE schism.
(Though I've always had the feeling that the license fight may have just been a palatable cover for a C-vs-C++ fight.)
I was following your comment until the end - I don't have any probems with Rust but how will that help the situation?
> I do research on fundamental UI technology and 2D graphics, with a focus on Rust and fonts. Currently on the Google Fonts team.
Rust also addresses many of my grievances with GTK and C++, notably the need to bolt on (although "bolt on" seems to imply less fragility than is the case) language features to give a higher level facade or otherwise deal with the deeply impoverished C and C++ build tools. Related to the previous point, Rust makes it much easier to bring in a dependency and write tests. Similarly, Rust benefits from a long tail of minor tooling improvements including documentation generation and hosting to text editor integration (Qt ships their own IDE which is of decent quality, but you have to go all-in on it; you don't get to use the plugins, keybindings, etc that you know and love from vscode / vim / emacs /etc and even then IIRC it only knows about things in the Qt project but not necessarily third party libraries--although with enough blood, sweat, and tears you can probably cobble together something based on clang metadata).
[0]: https://github.com/linebender/druid [1]: https://news.ycombinator.com/user?id=raphlinus
It's just a hard problem and its a boring, loveless space to work in.
> We believe that native apps with deep integration create a better experience, so 1Password for Linux will feel right at home on your desktop, whichever flavor of Linux you choose.
> Out of the box, you’ll find:
Automatic Dark Mode selection based on your GTK theme
Open network locations (FTP, SSH, SMB)
Integration with GNOME, KDE, and your favorite window manager
System tray icon support for staying unlocked while closed
Open and fill in your default browser
X11 clipboard integration and clearing
GNOME Keyring and KDE Wallet support
Kernel keyring integration
DBUS API support
Command line API
Integration with system lock and idle services
There's no logically correct definition of "native" which is also useful. Its just a buzzword that a few otherwise smart people use to mean "its fast". Every single stack out there can be engineered to be slow; some stacks cannot ever be engineered to be fast; Electron is not one of them.
Native is short for native code or native UI depending on context. Native code means AOT compiled. Native UI means it uses one of the platform's conventional UI frameworks. You can have native UI without native code.
Classic Windows apps are great compared to most alternatives.
But then let's say you have mobile apps as well, built with Cordova. What collective term would you use for your Desktop and Mobile apps?
It is certainly a bit verbose to specify every platform so I don't think that is a viable option.
Honestly you can build quite a list if we are not constrained with dev tools only.