The funny thing about all this is it's just history repeating itself. Back in the days of GTK2, there were a handful or two of "libgnome"-prefixed libraries that GNOME apps tended to use, but non-GNOME apps (that used GTK) tried to stay away from, in order to avoid depending on large bits of the GNOME desktop. The problem with that, of course, was that people in that position either got by with reduced functionality, or had to write their own code to do things that many people considered should be a part of the toolkit.
The GTK developers did recognize that a lot of this stuff was integral to a UI toolkit, and so most of the functionality in the various libgnome libraries was moved into GTK for GTK3.
And now apparently we're going backward again. No, I get, it's not the same situation. They are focusing more on "design language" than functionality: for example, the printing functionality that was moved from libgnomeprint (or whatever it was called) into GTK3 is staying (which makes sense), but menu bars (which have been in GTK since the beginning) are going away because GNOME doesn't use them anymore.
But that's a part of the problem; it seems like their rubric is "if GNOME doesn't need it, then it should be deleted"[0], coupled with the idea that many new design language elements should be GNOME-only and live in libadwaita, even if a more general audience would benefit from those elements.
As a developer of GTK-based applications for a good 20 years now, I honestly can't recommend GTK for new projects outside the GNOME umbrella. The problem is I'm not really sure what to use instead. Qt is really the only other major cross-platform toolkit, and does seem like a more stable base, but I don't want to do C++, and bindings for other languages aren't very ergonomic. (And toolkits like wxWidgets are just abstractions on top of other platform libraries.)
What I really want is a Rust-native UI toolkit library that does its own drawing, but can consume GTK3 themes. To me, the big issue is that of "native look", and I don't want Yet Another UI Toolkit that allows people to build apps that don't fit into my desktop at all.
[0] Note that quite a few things, like GtkDialog as a notable example, didn't get removed for GTK4, but have been deprecated and will be removed in GTK5.
Are they really deleting menu bars? Wow. Maybe in ten years time they'll figure out that two hamburgers is better than one; and that they'll need names like "File" and "Edit".
I wish the GP would clarify this particular confusion in their comment! The way it stands, the comment makes these projects sound outright whimsical, which is clearly not true.
Why does everyone have to make it so hard? All I want is literally the widgets Windows had 20 years ago in all platforms. That's all.
I don't even need the ribbon.
And now GTK has sliding tabs with animation effects I have to install tweaks to turn off. To begin with, why is tweaks even a thing? This should all be in the normal control panel! I can't believe I used to hear criticisms about the windows registry when in linux I need to install 2 different regedits to make the GUI look bearable.
It is in the normal control panel, see "Reduce Animation" in the accessibility page.
>All I want is literally the widgets Windows had 20 years ago in all platforms.
This seems to me a very bizarre request. I mean, you can literally do that already: write Windows apps using the old user32 APIs and run them in Wine. But then they will look and behave really out-of-place on non-Windows platforms when all your other apps are using the native toolkit.
>write Windows apps using the old user32 APIs and run them in Wine
Honestly, to me this is the actual choice. I've tried using graphics gale (a win32 app) and fire alpaca (a qt app) on linux. Fire alpaca didn't work. Neither the app image nor the windows version on Wine. But graphics gale worked flawlessly.
The future of crossplatform is just everyone writing Win32 API apps, just like every language communicates by a C api.
I can't agree with that, Wine has been around for a long time and it never really took off for that use. IMO the future of cross-platform is still the web, because "cross-platform" also includes smartphones now.
>Neither the app image nor the windows version on Wine.
That is more the developer's fault. AppImage is a very broken distribution method and IMO it should never be used.
I'm doing exactly this. To me, most native apps look out-of-place and I avoid if possible. I just wish running apps in wine wasn't so slow compared to windows.
>To me, most native apps look out-of-place and I avoid if possible
That doesn't make sense, "out-of-place" here means with respect to the rest of the system and the shell. Doing things that way is guaranteed to result in an inconsistent desktop, so maybe you can understand why that won't really be a supported thing.
For a while I actually used to do something similar to what you're doing. In the early 2000s when OS X was the new thing, I had gotten used to the Mac. So for a while I would only use Qt apps with a Mac-style theme and I would get really upset if something didn't work with it. But I stopped eventually because I realized I was being unreasonable and frustrating my own computer usage for no benefit. IMO it's helpful to recognize when you're in a harmful thought process and break out of it.
> for example, the printing functionality that was moved from libgnomeprint (or whatever it was called) into GTK3 is staying (which makes sense), but menu bars (which have been in GTK since the beginning) are going away because GNOME doesn't use them anymore.
You make it sound like menu bars are removed from GTK4. But I read the article multiple times to find where it says so. From what I understood, menu bars will stay in GTK4 but will not be represented in libadwaita because GNOME doesn't need them.
GtkDialog was deprecated because other changes made it now trivial for any app to re-implement dialogs with just a few CSS classes, and it's more flexible that way too.
>a Rust-native UI toolkit library that does its own drawing, but can consume GTK3 themes
This is never going to happen unless you re-implement nearly all of GTK3 in Rust with the exact same widget hierarchies and all the quirks of its (outdated) rendering model. Why would you want this anyway? GTK themes aren't particularly special, it's just CSS.
You don't need a full CSS stylesheet just to change some colors. And no, you can't take CSS from a GTK app and use it with a web app or vice versa, the layout system and the elements/classes aren't compatible.
The trouble is that I don't want to hardcode the colors in the app, but to learn which theme the user is using and adapt the application to use the colors of that theme (and other features if possible)
If the toolkit supported this automatically, it would be easier to achieve this
That isn't possible in any scalable way in any toolkit. There's a good reason all the major commercial operating systems basically only support light/dark mode and maybe a couple other theme variants/options and that's it. I think you are underestimating just how complex the style is for a non-trivial framework/toolkit/application and how it's full of interdependencies and platform quirks.
I have no idea what you're referring to. Nothing changed, because it didn't actually work in the GTK2 days either. Actually it was worse then. Themes would break apps constantly. I remember always having to edit gtkrc when something broke, and sometimes that wouldn't even work or the app would just crash entirely. It was even more "fun" if a theme crashed the window manager or the panel and then you had to switch out to a VT to fix it.
You say you have no idea what I'm referring to, and then proceed to talk exactly about the feature I was refering to.
This together with your other inconsistent comments here make me doubt your sincerity. You seem to be either tracking Gtk/Gnome Dev closely or are a Dev, but then pretend to speak for users of Gnome and ask others not to speak for users of Gnome. You seem to be in some sort of damage control.
Gnome 2 came with themes, that worked really well, and rarely broke. Denying it only makes you look silly.
The themes didn't work well for me and I've talked to lots of other users who had the same experience. It was a broken feature and it was correct to remove it. If you're denying my experiences and telling me they're not real then you are the one who is pretending to speak for other users of GNOME. So please cut that out.
I don't follow development closer than anyone else, I just periodically read the dev blogs and changelogs like any user should. The difference is I don't assume that developers are hostile entities that are apparently spending all their spare time being passionate about their open source project just to annoy some users? Come now, think about it, isn't that a ridiculous notion? I mean really, I'm complaining about a broken feature and you're saying that's damage control. Wouldn't it be more "damage control" to insist that GNOME 2 somehow fixed all its theming bugs by doing something mysterious and unexplainable that no one can figure out 20 years later?
When I comment I try to counter the negativity and focus on making constructive comments, I strongly urge you to do the same. It's not like the developers are aliens that can't be understood by mortal humans, if you really need something explained you can just go in the Matrix channel and (respectfully) ask them questions.
This thread is full of people trying to share experiences that you seem to not allow, Gnome 2 themes working well (for them) being one of them. Sharing the observation of a downward trend _is_ constructive. Trying to invalidate such observations is not.
Considering Mate and Cinnamon still exist and are healthy projects would indicate there's many developers who share this sentiment. Nobody maintains older versions of KDE, apart from a single distro using Trinity (KDE3). That's quite a contrast as well.
I wasn't, and very few are, treating developers hostilely, we are just sharing whatever experience we have. That this isn't altogether positive, is not our fault or responsibility. That's the 'risk' you run creating products for end users who just use it. Nobody forces anyone to code for them.
Please stop putting words in my mouth, nowhere did I write that Gnome2 was bug free.
I suggest you take your constructive criticism to hand yourself.
> Gnome 2 themes working well (for them) being one of them
For some definition of working well. What I remember was debugging a case where the KDE theme for GTK (that is, to make GTK look like KDE) wanted to fork() and exec(), and that caused bugs if you initialized GTK at a slightly different place in main() than what most programs did. I had to add a special case to QEMU just for that...
Even if something "works well" for some people, it does not mean it is not (in retrospect - no offense intended to the original authors) a steaming pile of crap.
>This thread is full of people trying to share experiences that you seem to not allow, Gnome 2 themes working well (for them) being one of them.
The mistake you are making here is that someone not experiencing a bug does not invalidate the existence of that bug. You can be using a feature and it can be working okay for you but if it causes bad problems for lots of other people or causes maintenance issues then it will get the axe. This is not to disallow your experiences, but to say there are reasons the developers may not consider your experiences to be representative of a typical experience, or ones that are even worth acknowledging. Because ultimately the developers are the ones who have to listen to all the complaints from everybody and decide which ones are valid -- users can't and don't do that, if they did then they would be developers.
>Considering Mate and Cinnamon still exist and are healthy projects would indicate there's many developers who share this sentiment.
That doesn't indicate it though, Mate and Cinnamon don't use GTK2.
>Nobody maintains older versions of KDE, apart from a single distro using Trinity (KDE3).
But you just disproved your own assertion with an example! If there's one even example then that means a certain percentage of users aren't happy.
>I wasn't, and very few are, treating developers hostilely,
I can't agree with this, I have read several hostile comments in this thread accusing GNOME developers of "sabotage" and things like that. I apologize if you aren't doing that.
>is not our fault or responsibility.
I can't agree with this either, if you aren't even using GNOME but you continue to complain about it then that is completely your responsibility. At some point you have to accept responsibility for your own choices. If that means you have to pick up GTK2 and fork it then that's what you have to do. You can't fault GNOME for not doing that just to please MATE users or whatever it is, when those users would probably still be unhappy with modern GNOME anyway.
>nowhere did I write that Gnome2 was bug free.
But that seems to be exactly what you were suggesting in regards to themes? What am I missing here?
That's why I asked you some questions. If you don't answer my questions or clarify anything then there isn't any other way I can understand your point of view, sorry. You are the only one who can explain yourself.
The GTK developers did recognize that a lot of this stuff was integral to a UI toolkit, and so most of the functionality in the various libgnome libraries was moved into GTK for GTK3.
And now apparently we're going backward again. No, I get, it's not the same situation. They are focusing more on "design language" than functionality: for example, the printing functionality that was moved from libgnomeprint (or whatever it was called) into GTK3 is staying (which makes sense), but menu bars (which have been in GTK since the beginning) are going away because GNOME doesn't use them anymore.
But that's a part of the problem; it seems like their rubric is "if GNOME doesn't need it, then it should be deleted"[0], coupled with the idea that many new design language elements should be GNOME-only and live in libadwaita, even if a more general audience would benefit from those elements.
As a developer of GTK-based applications for a good 20 years now, I honestly can't recommend GTK for new projects outside the GNOME umbrella. The problem is I'm not really sure what to use instead. Qt is really the only other major cross-platform toolkit, and does seem like a more stable base, but I don't want to do C++, and bindings for other languages aren't very ergonomic. (And toolkits like wxWidgets are just abstractions on top of other platform libraries.)
What I really want is a Rust-native UI toolkit library that does its own drawing, but can consume GTK3 themes. To me, the big issue is that of "native look", and I don't want Yet Another UI Toolkit that allows people to build apps that don't fit into my desktop at all.
[0] Note that quite a few things, like GtkDialog as a notable example, didn't get removed for GTK4, but have been deprecated and will be removed in GTK5.