Qt backend?

[flying-sheep]

on my system, GTK isn’t the native toolkit

[Chaz6]

I would like a Qt backend also, thanks!

[Abscissa]

Was just going to file this, but looks like it's already been posted. Problem is, this...

"...uses the native GUI technologies of each platform it supports"

...and this...

"Unix: GTK+ 3.4 or newer"

...directly contradict each other. GTK is only native on some Linux systems. On many, native is Qt. Many Linux users can't stand GTK software, it's just as bad for them as non-native.

[andlabs]

GTK+ and Qt are equally native in that a) most modern Linux programs either use one or the other b) there are ways to make each look nearly identical to each other for many common themes.

Writing a Qt backend seems pointless; libui already aims to do what Qt does, so what's the point of providing a less powerful frontend in C to Qt? Just use that directly instead. (While it's true that GTK+ also does this to some extent, it's not as important of a goal for GTK+ as it is for Qt.) GTK+ is also a lot lighter and is more likely to be present than Qt is...

[FraGag]

I'm using Plasma 5 along with the Breeze theme, which is primarily a Qt theme. The theme has also been ported to GTK2 and GTK3, but the GTK3 version (I have breeze-gtk 5.6.4) has been broken since the release of gtk3 3.20.x, so I use the default GTK3 theme instead, which is OK but definitely distinct from Breeze, making GTK3 applications feel nonnative.

By offering a Qt backend, libui-based applications would use the user's Qt theme. While it's true that Qt also uses the native look and feel on platforms that have one, it's also true that Qt defines the native look and feel on other platforms (especially Qt-based Linux distributions).

Now, having two available backends on Linux poses an interesting architectural challenge. What backend(s) should the built library use? Should the library select the backend at runtime, or should it be selected at compile time? If the latter, should it be possible to install both libui-gtk3 and libui-qt5 system-wide? IMO, I'd go with having distinct libui-gtk3 and libui-qt5 libraries, which would be provided as separate packages by distributions with appropriate dependencies, as well as a virtual libui package (with two options, libui-gtk3-default and libui-qt5-default or something like that) that just installs a symlink to the selected implementation. Applications that don't depend on the backend would link to libui, whereas applications that depend on a specific backend would link to the specific library.

[flying-sheep]

Writing a Qt backend seems pointless; libui already aims to do what Qt does, so what's the point of providing a less powerful frontend in C to Qt?

1. libui has a C API
2. libui uses the real native UI toolkit instead of using native draw calls to create things that look almost perfectly native
3. what @FraGag said

GTK+ is also a lot lighter

lolno. GTK 2 maybe, GTK 3 not. the world changed. chrome is the fat browser and GTK is less efficient than Qt. try using one or the other in an embedded context and Qt will obliterate GTK 3.

[ssokolow]

I have to also agree here.

I have some ideas I'd like to experiment with using the Rust bindings to this, but my main target platform is Linux and, given that I don't like the direction the GTK+ 3.x ecosystem is going, I'm forced to use PyQt and burn myself out "writing Rust's type system in my unit tests" since GTK+ 2.x will never get Wayland support.

(And, given how much of my code either is glue code or relies on tight coupling with Qt's functions and event loop for performance, that makes using Rust at all a net negative, since it'd basically just be an extra layer of effort for anyone who wants to set up their own build.)

[kristjanbb]

Wrapping Qt in a non-leaky fasion isn't that hard. They just tend to be very limited so they leak more and more, or die out because people find them too limiting. Hence I find this project somewhat interesting.

It seemed like a decent weekened project.

Here is my initial fork with Qt5 backend. It's more or less feature complete and on pair with the Gtk version, but it's still unpolished and minor quirks here and there.

Build with make OS=qt5 and drop in the new libui to see the different.

Or just run the tests/examples.

make OS=qt5 -j8 examples test
out/controlgallery
out/cpp-multithread
out/histogram
out/test

Some screenshots for the lazy.

I've submitted a pull request #80, but I won't be actively maintaining this. I might polished and fix some of the architectural flaws with next weekend.

[andlabs]

Ultimately whether I do add a Qt backend will depend on #100, and vice versa. I do have a KDE setup working now to test it with, if I do decide to allow it. It will not be until after the next packaged release (likely to be called Alpha 4).

[mixedCase]

Well, I really hope libui does end up getting a Qt backend since it's posed to be the best GUI library with Go bindings. This is the last straw for me as far as Gtk goes and would really like to distance myself from the toolkit from now on.

[andlabs]

I'm not going to change my mind based upon public dislike.

I still hold that having a Qt backend is redundant, since Qt has the exact same goals as libui, but with much more maturity and many more features. (GTK+ seems to have this, but it doesn't really try to blend in with Windows and OS X, even though there is a win32 theme.)

[ssokolow]

I was hoping libui would gain Qt support because Rust has libui bindings but the only bindings directly to Qt are for QML and QML's support for native widgets is still unacceptably incomplete. (And it's QML, which means runtime overhead and limited compile-time verification.)

(Since repeating ourselves without addressing points raised seems to be the "to do" thing right now. To be honest, I was just in a hurry and assumed that your repeat was actually the first time you'd said it and, therefore, that I hadn't already said this. File it as an example of "libui has a C API and Qt doesn't")

[flying-sheep]

@andlabs i stated my arguments why it isn’t redundant here. idk why you repeat your claim of redundancy without addressing any of those points.

[Abscissa]

I still hold that having a Qt backend is redundant, since Qt has the exact same goals as libui, but with much more maturity and many more features. (GTK+ seems to have this, but it doesn't really try to blend in with Windows and OS X, even though there is a win32 theme.)

Pardon me for asking, but if you really do see Qt as having "the exact same goals as libui, but with much more maturity and many more features", then what is the purpose of libui in the first place?

Personally, I do have reason to be interested in using libui rather than using Qt directly: Binding Qt to other languages (D, in particular) can be a huge undertaking due to its overall size, use of C++, and (from what I've heard) use of a custom preprocessor. But being a lightweight C-based lib, libui is, by comparison, trivially easy to bind to. For me, this alone makes a Qt back-end for libui very much non-redundant.

I assume you also see value, as I do, in using libui vs using Qt directly, otherwise you wouldn't likely be developing/maintaining libui, since after all, Qt can already be used directly and has "the exact same goals as libui, but with much more maturity and many more features". I'm just a bit puzzled by this stance.

[emersion]

Another point to keep in mind is that if we add QT support now, we'll need to maintain it in the future. This means supporting one more platform when adding features. We can't leave one platform behind others, with some features missing.

Is there a simple way to make platforms pluggable, e.g. to host the QT backend in another git repo and make it easy to compile it with the rest of libui?

[wasamasa]

I support this, as GTK intentionally breaking their API left and right concerns me: https://davmac.wordpress.com/2016/07/05/why-do-we-keep-building-rotten-foundations/

As for the problem of how one would pick the "right" backend on their Linux system, other graphical applications simply come with compile-time switches for choosing the used widget toolkit. See Emacs for such an example. Packagers could then create conflicting packages that allow the user to install either flavor.

[andlabs]

Merged with #327.

[foresto]

For what it's worth, I think a Qt backend would be sensible, mainly because of these three facts:

GTK's recent UI direction has become intolerable for many people. For example, the push toward client-side window decorations, the removal of tray / status icons, and the theme engine that breaks themes with every point release (or is not intended for actual use, depending on whom you ask). It was once the toolkit that helped developers present a comfortable interface to our users, but it has become a vehicle for its maintainers to impose questionable designs onto our software. I don't want my apps to be held hostage by modern GTK's bad ideas. I don't want to keep spending my development time working around them. Importantly, I don't want my users to have to run a desktop environment full of GTK-isms in order to enjoy native toolkit integration with my apps. GTK has spent the last several years turning itself into a disadvantage. I suspect I'm not the only one who is fed up, and now avoiding it.

Qt is the obvious alternative. It yields great results if you happen to be developing in C++ or Python, but it's not practically available in any other language, mainly because its API dependence on C++ and the meta-object compiler makes foreign language bindings nontrivial.

Meanwhile, we seem to be entering something of a language renaissance, with several new ones solving the major flaws in C++ (complexity, safety) and Python (performance, distribution). People want to develop in Zig or Rust, for example, but are held back by the lack of bindings to a good cross-platform GUI library. With its C API, I suspect libui would be well positioned to fill that need, if only it didn't produce GTK apps.

Of course, the work required for a Qt backend is another question entirely. Verdigris (used by nimqt) looks like it would simplify the job.

Cross-reference: #327

[ssokolow]

I suspect I'm not the only one who is fed up, and now avoiding it.

I can second this.

As a user, I've been finding non-GTK replacements wherever possible and grumbling about how fragile and seemingly hostile to my preferences GTK has become when I'm trying to use ~/.config/gtk-3.0/gtk.css to remove the drop shadow from context menus in irreplaceable things like Inkscape so the runtime "toggle compositing" option doesn't produce giant black borders. (Something which shouldn't even be there, given that I'm running a KDE desktop with the Qt, GTK 3, and GTK+ 2 versions of the Breeze theme and only GTK 3.x even tries for drop shadows.)

As a developer who used to use PyGTK as his go-to "feels comfortably native no matter what DE you're using" UI binding, I now use QWidget bindings like PyQt and PySide... even if that means writing Rust GUI apps such that Rust is the backend and the frontend is a Python app interfaced through PyO3, similar to how Qt wants you to combine QML and C++ for Qt Quick (in my experience, something which is very much not ready for use outside mobile or embedded applications)... and MyPy+Flake8+PyLint can't hold a candle to Rust's type system.