XWayland 21.1 Release Candidate Offers Split From The X.Org Server

[curfew]

Curfew is that straight forwards to make your own theme engine? No its not. Classic widgets with new versions of Qt things do change resulting in old Qt themes not working with new versions of Qt.

Well, I didn't mean that it would be easy nor quick, but the process in itself is very clear. There is no ambiguity and the APIs are very stable.

Having to code your own theming engine is not really useful if your objective is unified theming across the complete desktop. So you have to code a theme for Qt then for GTK then for Wxwidgets..... Then deal with the breakages caused by updates.

Now I think you're getting lost. All toolkits have their own, unique theme engines. It doesn't matter if you're writing yet another or not. If your target is to achieve uniform theming across toolkits, then you should definitely write theme engines that make it possible.

End up with the nightmares where you have new and old applications using different versions of the toolkit that need different versions of the theme file.

This doesn't happen on classic Linux desktops because the libraries are shared. Not sure about those pesky flatpaks and snapchats and whatevers, though.

I have done the horrible job of trying to get unified appearing on Linux desktop is really not fun.

So?

https://stopthemingmy.app/
This from gnome developers where really powerful theme systems result in applications being not able to be used by end users also applies to Qt theming.

That's some incoherent rambling, to be honest. Of course users must be allowed to theme their desktop and of course you're an idiot if you try to block that. The technical details on how theming is applied might be subject to discussion.

Personally I wouldn't mind being able to apply a custom stylesheet on a per-app basis, but still retaining the option of applying a global stylesheet as well. This is of course not a problem for the "GNOME community" nor end-users but actually something for the GTK devs to implement. So these pathetic people are barking at the wrong tree.

Blocking theming will of course also block attempts at unifying the look-and-feel of different toolkits, so I think you are trying to now make an argument both for and against the unification.

[ssokolow]

Now you're shifting goal posts from your own arguments, haha. Password dialogs have nothing to do with window borders, which was your original argument.

Stop being a re-tard, stop executing untrusted apps!

Not at all. The point is and always has been to have a part of the window which the application does not control, whether it's for trusted controls, trusted information/identification, or both.

As for "untrusted apps", there's no such thing as "trusted enough", there are just degrees of risk. That's why you stack laters of defense in depth. Otherwise, we'd still all be on MS-DOS, with no memory protection and no privilege isolation.

[ssokolow]

Having to code your own theming engine is not really useful if your objective is unified theming across the complete desktop. So you have to code a theme for Qt then for GTK then for Wxwidgets..... Then deal with the breakages caused by updates. End up with the nightmares where you have new and old applications using different versions of the toolkit that need different versions of the theme file.

Your ignorance is showing. wxWidgets is a thin wrapper around the platform-native toolkit with a few extra synthetic widgets to fill in the gaps on whatever platform you're on. That's why the APIs are so ugly.

(Source: I've coded for wxWidgets, GTK+ 2.x, GTK 3.x, Qt 4, and Qt 5... though mainly the Python bindings. I can, however, attest that the Python bindings to wxWidgets are about as faithful to the underlying C++ API as the Qt bindings are, and both wxWidgets and wxPython have an ugly Win32-esque quality to their APIs... mainly the need to pass around raw numeric IDs.)

On Linux, the backend in use is called wxGTK.

https://stopthemingmy.app/
This from gnome developers where really powerful theme systems result in applications being not able to be used by end users also applies to Qt theming.

Lot of ways we need some form of really simple theme solution that application and end users can use without risking ruining their day. This would also require some smarts on mandated contrast differences between different elements.

Horrible as it sounds there is such thing as over kill. Most toolkits on Linux the theming system is over kill. Most users will only want to adjust a few colours to suit their vision better and be wanting consistency in appearance.

I'll stop theming their apps when they stop designing them for idiotic amounts of padding and using icons that grate on the focus issues granted to me by the mix of ADD and Asperger's syndrome I was diagnosed with.

(Seriously. Back in the GTK+ 2.x days, my theme of choice was a hacked theme called "Clearlooks-Compact" and I did and still do run a customized icon theme which does stuff like overriding the panel icons for applications.)

IMHO, system-wide theming is one of the XDG desktop ecosystem's greatest strengths and, if an application is insufficiently themable, I look for a replacement. (Yes, I also do things like using Userstyles to re-theme web apps I'm forced to use.)

[Shiba]

I don't see why the hell that should be a problem.

Than I'm talking with a stupid. End of conversation, bye.

[oiaohm]

On Linux, the backend in use is called wxGTK.

That is not in fact 100 percent true all the time. https://aur.archlinux.org/packages/wxqt-dev/

Wxwindows on different Linux distributions may not always be wxGTK.
https://docs.wxwidgets.org/3.0/page_port.html

Would pay to read wxX11 particularly fun there are 4 possible different backend outcomes when you use wxwindows and installing applications on different Linux installs that could be there. 3 possible backend outcomes are themeable with different theme formats. Yes wxX11 is not theme-able by a system theme.

So you are making a wx application to run random Linux distributions welcome to having to test 3 times for theming caused issues due to 3 different back ends with 3 different theming solutions. With out the version breaks as well.

Proper universal theming solution could make life a lot better.

[oiaohm]

This doesn't happen on classic Linux desktops because the libraries are shared. Not sure about those pesky flatpaks and snapchats and whatevers, though.

Sorry to say it does happen on classic Linux desktops with those installing commercial programs going into /opt or /usr/local because those libraries were not 100 percent sure to match up.

Bundling of applications with libraries different to distribution host predate flatpak and snap stuff.

Also miss match of theme to installed libraries. Remember people would get like a theme from what was Gnome-look and so on and add it to there system. So theme user puts in their home directory may not be compatible with installed libraries. Now this problem could get as systemd-homed gets used more. Put home directory on USB key and move it between multi different distributions with multi different libraries..... Theme compatibility issues are going to come bigger problem.

[ssokolow]

That is not in fact 100 percent true all the time. https://aur.archlinux.org/packages/wxqt-dev/

Wxwindows on different Linux distributions may not always be wxGTK.
https://docs.wxwidgets.org/3.0/page_port.html

Would pay to read wxX11 particularly fun there are 4 possible different backend outcomes when you use wxwindows and installing applications on different Linux installs that could be there. 3 possible backend outcomes are themeable with different theme formats. Yes wxX11 is not theme-able by a system theme.

Huh. Last I heard, wxQt was still the one that nobody packaged because it was about as usable as the Qt backend for XULRunner, and wxX11 and wxMotif were the bogeymen used to scare wxWidgets-using developers into staying on Linux and BSD where they could trust wxGTK would satisfy the dependency instead.

Either way, there's still no such thing as a "wxWidgets theme" in the sense you used it. In real-world scenarios, it'll either pick up your GTK theme, pick up your Qt theme, or run on a backend which can't be themed and shouldn't be something you bother officially supporting unless you've got a paid support contract.

(Now, if you'd said Ttk, on the other hand, I'd agree. It's annoying how nothing Qt or GTK-based quite matches git-gui, and the Clearlooks theme for Ttk that you can swipe from PySolFC doesn't manage to theme every single widget in it.)

[oiaohm]

Huh. Last I heard, wxQt was still the one that nobody packaged because it was about as usable as the Qt backend for XULRunner, and wxX11 and wxMotif were the bogeymen used to scare wxWidgets-using developers into staying on Linux and BSD where they could trust wxGTK would satisfy the dependency instead.

The reality is that is not true. All 4(wxGTK,wxQT,wxMotif,wxX11) are packaged for arch and gentoo based Linux distributions. If you have only tested with wxGTK on Linux you really should be using the wxWidget option to force particular back-end so a possible future change on your target distribution cannot get you. There are a handful of applications that are arch packaged that do in fact need wxQT or wxMotif and will not function correctly with wxGTK.

wxWidgets multi backend options brings it own forms of theming headaches and its own particular nasty trap. Yes you would have missed including code so the program errors out if the right wxWidget backend is not present.

(Now, if you'd said Ttk, on the other hand, I'd agree. It's annoying how nothing Qt or GTK-based quite matches git-gui, and the Clearlooks theme for Ttk that you can swipe from PySolFC doesn't manage to theme every single widget in it.)

What you said with tik here applies to wxMofit and wxQt backends as well where at times they drop back to the generic widget rendering that is not themed. From what you have said you were not aware that the multi back ends of wxWidgets was a problem you could run into in the real world so not knowing about wxMotif and wxQt limitations is kind of to be expected.

Old Qt/GTK theme on a newer version can also result in particular widgets not being properly themed as well. Remember we have systemd-homed now where users are going to be moving their home directory between systems more often and these incompatibility are going to come bigger problems.

Complex theming alterations that depend on particular library versions to work right really need be on the system not in the user home directory. But user still needs to be able to personal theme from their home directory in a more generic way that not going to ruin there day when old meets new or new meets old.

[curfew]

Your ignorance is showing. wxWidgets is a thin wrapper around the platform-native toolkit with a few extra synthetic widgets to fill in the gaps on whatever platform you're on. [---] On Linux, the backend in use is called wxGTK.

Your ignorance is showing as well. GTK isn't native-to-Linux. It's merely native to Gnome and to some extent XFCE.

Qt can also natively adapt to OS X and Windows so there is no need for an ugly API that proxies to another toolkit.

[ssokolow]

Your ignorance is showing as well. GTK isn't native-to-Linux. It's merely native to Gnome and to some extent XFCE.

No, but, especially given RedHat's efforts, it's the closest thing Linux has to "the platform's native toolkit" and, in the GTK+ 2.x days, QGtkStyle did a pretty damn good job at making everything look right with a single GTK+ 2.x theme.

(I say this as someone who wandered through all major desktops back on MandrakeLinux 10.0 (as well as building my own desktops using various WMs like Openbox, Blackbox, FVWM, Fluxbox, and E16, then settled on KDE 3, migrated from KDE 3.5.x to LXDE when KDE 4.0 was adopted too readily, finally came back late in the KDE 4.x cycle when "Now it's responsive and stable" stopped being an aspirational lie, and am still on a mix of KDE and LXDE components which I'll switch to a mix of KDE and LXQt components when I upgrade soon... I never felt Konqueror 4.x or Dolphin were suitable replacements for Konqueror 3.5.x (too many papercut bugs) so I switched to PCManFM. Likewise with KDE "lightweight" text editors being needlessly cluttered with UI elements when Leafpad was all I wanted... I'm probably going to have to fork MComix when I upgrade to get it pared back down to the Comix UI.)

Qt can also natively adapt to OS X and Windows so there is no need for an ugly API that proxies to another toolkit.

Agreed. That's why I migrated from wxPython to PyGTK when I switched from Windows XP to Linux in the early 2000s, then from PyGTK to PyQt5 when GTK 3.x ruined the "write to the one API every Linux user is likely to have already installed for something and get an app that looks sufficiently native on my KDE desktop" value proposition.

(These days, I mainly use PyGObject for my QuickTile window-tiling helper, which doesn't draw any on-screen widgets but needs easy access to libwnck.)