You really misunderstood my points. I’ll reply point-by-point.
When have I ever said I was anti-Qt bindings? I’ve been saying all along that a lack of bindings to the QWidget API are the main reason my desktop apps are written using Python and PyQt rather than Rust.
The closest viewpoint to being “anti-Qt bindings” that I’ve expressed is that bindings should focus on the QWidget API because the QML+QtQuick APIs (which aren’t the same thing) already have qmlrs but, despite that, the needs QWidget APIs serve aren’t being met.
I mentioned GNOME 3 because it (and things derived from it) are the only exception to the rule that X11 desktop environments use server-side decorations. KDE, Xfce, LXDE, LXQt, and every standalone window manager all use server-side decorations.
For Wayland, the general consensus is “Trust us. We’ll figure out a way to ensure client-side decorations are consistent and reliable across all applications” but KDE wasn’t convinced, so, to ensure that consistency, they’re implementing server-side window decorations under Wayland. Because LXQt (the successor to LXDE) will use KWin, LXQt will also get server-side decorations.
(Bear in mind that, aside from being one of the big desktop environments with a significant slice of the Linux desktop user base, KDE is the oldest of the desktop environments still in use. GNOME was implemented as a “We’ll make our own desktop environment, with beer and hookers” response to Qt not having a favorable license in the beginning… and it shows. Under the hood, GNOME and GTK+ have always been a sloppy, creaky knock off of the functionality KDE and Qt offered. For example, GnomeVFS took forever to catch up to KIOSlaves’s stability and, GTK+ MVC architecture is more primitive than Qt’s. I say this as someone who’s used and done a fair bit of programming for both.)
…and nobody is shipping Wayland as a production-ready option yet (Fedora 25 will be the first), so I’d argue that X11 users are the more important demographic to judge norms by.
Also, KDE and LXQt, the two Qt-based desktop environments, use QWidget for their desktop applications, not QML. (That’s a matter of policy that you’ll see on the KDE Community Wiki where they say that QML is for Plasma and KDE Mobile widgets and QWidget it for desktop apps.)
AwesomeWM and QTile are window managers, not desktop environments. As they do not provide widget toolkits, their only theming concern is titlebars and window borders, if applicable… and, if you set AwesomeWM to display window borders (I have used Awesome and written an
rc.lua for it), it will still enforce that they’re consistent across all applications you apply them to.
As for Enlightenment, I’ve yet to see any evidence that it’s got any significant market share outside of non-desktop UIs like Tizen IVI.
First, every desktop I’ve used has been patched to indirect things which reference it through
x-terminal-emulator on Debian-family distros, which means that none of my family has seen XTerm, receiving, instead, whatever terminal emulator the desktop provides.
That aside, how many non-Debian/Ubuntu/Mint/etc. users even remember that XTerm even has widgets aside from the obvious “terminal widget in a WM-provided frame”? Sure, the font doesn’t follow the Qt or GTK theme’s font settings, but a terminal with an odd font doesn’t look that out of place on the rare occasions it shows up.
I think that, if the one who designed it is that tied to such a specific rendering, they should develop for something like the Nintendo 3DS where they can control the hardware… or at the very least, they should stop trying to hide their leanings and piss off their users with honesty by overriding things like custom fonts for the visually impaired.
There’s a reason that, even when not presenting to a client, we UI/UX designers develop our wireframes with sketch-like widgets that distance us from the themed end result. It’s so the data and workflow take front and center stage, rather than letting minor stylistic choices distract from that.
The flaws in a library or API are always relevant when you’re deciding what to build your application against. QWidget and QML have different strengths and weaknesses. (You wouldn’t start a new mobile app using QWidget and you wouldn’t try to build a new desktop application for inclusion into KDE using QML.)
It doesn’t matter how elegantly you solve problem X if the people who were clamoring for a solution ignore what you wrote because they were asking for a solution to problem Y.
As I said, we already have qmlrs for QML-based UIs and I have yet to hear of any reasons it’s so deeply flawed that an effort to build a whole new binding should prioritize QML rather than QWidget, which currently has no usable binding.