> fairness, Linux GUI toolkits suck a lot
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.
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.)