Once in a while I check the installed packages for a possible dependency on GTK and when I find a program which has one, I look for an alternative to have one dependency less.
The last time I replaced simple-scan with skanlite and it is a much much better scanning program and with a more pleasant ui on top.
I am not using Mint and it is also in the Fedora repos, but there is no reason for it to not be on Flathub. Maybe when I find the time I try to package it.
The enshitification of Gnome continues until it be it’s own little isolated thing and previous gnome code will have to be forked to make progress that users actually want.
That will probably go for gnome apps eventually. The Mint guys might have to rewrite all the bloody apps to work with gnome 3…🤦
Didn’t that happen a long time ago which is how we got MATE?
I no longer follow developments in GTK based DEs much because nowadays KDE Plasma is so clearly the best choice for me, but it has long been my impression that GNOME just wants to be its own thing that doesn’t really care about anyone not using GNOME. This is probably because the main role of GNOME is to be the DE for installations commercially supported by Canonical, Red Hat, etc.
It’s not up to GNOME to do others work for them. If Mint wants a specific styling for their desktop, they should fork it (which they’re already doing) since everything is open source. It’s not like GNOME is gonna hunt them down for forking and creating a new product altogether lmfao. Cut the crap.
Gnome Foundation likes to think of themselves as the pioneer in DE’s and the default choice for Linux. Which was true for a long time. Cinnamon and Mate run Gnome, for example. I’m not sure about XFCE.
If you’re THE leading DE project at least try to accommodate those DE’s that depend on your code or meet with them to inform them well in advance and discuss the best options for those DE’s.
In other words, work together for the good of all users instead of doing your own little thing in the corner and leave the others to deal with the mess you made…
They are not pioneers, they are Microsoft funded group (at the beginning, at least) with task to slow down desktop Linux adoption. KDE, even then, was better than MS Windows. Before you downvote me, check the guy named Miguel De Icaza
They are not pioneers, they are Microsoft funded group (at the beginning, at least)
In the beginning in 1997 GNOME was a direct response to KDE using Qt toolkit with a license that GNU with RMS did not like at all. Not sure why you mention Microsoft and funded ? When I search for it I see that M$ gave 10K to GNOME in 2022, more than two decades later.
If you’re THE leading DE project at least try to accommodate those DE’s that depend on your code or meet with them to inform them well in advance and discuss the best options for those DE’s.
It’s always easy to say that other people should do more work to benefit others. Libawaita isn’t anything new. It was announced loads of times.
In other words, work together for the good of all users
That the current status isn’t what you want isn’t the same as not working together. Further, there’s usually a limited amount of time and attention.
Within Linux there’s loads and loads of opinions. Loads of different desktop environments. That complexity cost development time. Time that isn’t infinite. Again, it seems to easy to direct how others should spend their time and/or to argue that they aren’t doing enough for your liking.
I think the topic of LibAdwaita was discussed plenty when shit hit the fan 2-3 years ago. Downstream developers can’t act all innocent and misinformed now when there was a huge drama between Budgie and GNOME upon LibAdwaita’s announcement.
GNOME developers repeatedly asked downstream developers to stop theming their apps which was generating endless bug reports for issues not caused by upstream code and none of them bothered to listen to them or work with them on a fix. Their choice of developing their own widget kit is a wise one because they’d otherwise still be wasting valuable developer time on fixing issues they should not be responsible for.
When one doesn’t take “no” for an answer, you’d have to forcibly make them stop. Just my two cents 🤷🏻♂️
No. It’s deliberately breaking backwards compatibility to force other projects that use that code to either look bland like Gnome or stop making their DE’s.
No, it’s theming their own project to look however they want it to.
bland like Gnome
Gnome looks amazing. It’s objectively the most consistent and polished DE out there, and IMO the best looking one.
or stop making their DE’s.
Lmao is this what you think? There’s a secret cabal of Gnome developers who think that by making the Libadwaita theme and using it in their own Gnome apps, it will kill other DEs? Can you actually hear yourself?
That conspiracy theory doesn’t even make sense. Care to tell us your opinions on the moon landing? I imagine they’ll be quite funny.
Who said anything about a conspiracy? I’m just saying they may be acting selfishly and it couldn’t hurt to speak to other parties who they know use their code, to discuss how it will impact them.
It’s deliberately breaking backwards compatibility to force other projects that use that code to either look bland like Gnome or stop making their DE’s.
You’re asserting that the Gnome team is secretly working together (i.e. conspiring) with the explicit aim of enforcing DEs to look like Gnome (idk how they could force that but whatever), or to stop making their DEs altogether (similarly, I can’t see the logic there. Unless you believe that only Gnome devs are skilled enough to make Linux programs and other DEs just have to take what Gnome makes. But that’s an absurd suggestion).
It’s not a conspiracy. All I was saying is that by breaking backwards compatibility downstream either has to comply or find another way.
As another commentor has mentioned, gnome did actually inform downstream a good while back but downstream did not engage, so gnome obviously proceeded with their own project how they saw fit. Which is the right way of course.
Downstream should have tried to engage and perhaps found a good work around but sadly didn’t.
How about when the theming is baked in and impossible to change?
Enshittification doesn’t have to be monetary. It’s about doing things that go against the interests of the user.
Unfortunately Gnome has taken to heart St. Exupery’s law (“perfection is not when there’s nothing left to add, but when there’s nothing left to take away”) but have forgotten that it was coined in an era of mechanical devices and there’s more than one aspect to software. Applying it to functionality is very different from applying it to features and customization. The latter ends up making software feel bland and oppressive.
How about when the theming is baked in and impossible to change?
It’s not impossible to change, people alter it all the time. E.g. with Gradience. Either way, it still wouldn’t make it enshitification.
Enshitification != when an app from an open source project has a theme that’s harder to change.
Unfortunately Gnome has taken to heart St. Exupery’s law
Yawn. The usual “hur dur what’s Gnome removed this time???” line that doesn’t even make any sense. Go look at changelogs for Gnome updates and you’ll see that meme is bullshit. Stuff was removed in the Gnome 3 migration, what 13 or 14 years ago? It’s time to move on.
And again, still nothing to do with enshitification even if Gnome were trimming features out all the time, which they aren’t.
You people really need to learn what enshitification means instead of just latching onto the newest buzzword and applying it to everything. It’s like when companies call everything AI now lol
How about when the theming is baked in and impossible to change?
It can still be changed, it’s just a harder to do so.
It’s about doing things that go against the interests of the user.
This conveniently ignores that app developers are also users of ui frameworks, and they would like a well defined platform to test for, rather than an endless stream of distros each with its own theme that could break their app.
I don’t see libadadwaita as progress. Last week, simple-scan got an update and is stuck to a dark theme since then. To change it, i would have to install gnome-settings and klick a button there. Can’t do that via my usual keyboard-combo.
edit: edited Gnome’s ‘don’t theme our apps’ away since it’s beside the point.
If you actually read through that they say theme away to your heart’s content, just please don’t report issues to the app developer, report it to the theme developer.
They say that lots of time they could spend developing is managing and investigating bugs that end up being due to the user installing some random poorly-made theme, wasting precious dev time that they are donating for free.
It’s a perfectly reasonable request, and has no bearing on whether an app is proprietary or not.
E: the guy above has drastically changed their comment so now mine probably doesn’t make sense.
If a theme is able to break core functionality then your theming system/guidelines needs to be fixed. And it to be more accessible to theme designers so these problems don’t occur in the first place.
That’s bs. No matter how good your theming system is, it can’t fix a bunch of things. Even something as basic as text being shown against a background with not enough contrast.
Theming has been known to cause issues on literally every DE. You can’t stop people from theming poorly, or ban bugs, they’re both just part of the landscape of downloading random themes and applying it to all your apps.
And random dev shouldn’t be on the hook for third party themes that cause issues. Nor should they be expected to drop everything and investigate bugs in somebody else’s theme project. That stuff should be reported to the theme developer.
Most Linux app devs are volunteers and their time shouldn’t be wasted investigating theming-related issues. Report it to the theme developer.
I admit i stopped reading after i got alienated by the bullet points. And Gnomes points after are nice and all, but only caring about their own vision is not the solution either, especially if you create one of the two main GUI frameworks. A tool is not an art piece but something that has to adapt to the user.
So you tried to shit on developers by posting a link to a completely reasonable request (“theming is fine but please be mindful of wasting our limited time by bombarding us with bug reports related to janky themes”) that you hadn’t even read. Got it.
People need to understand that none of this development is free. These people donate their time to make these projects for us to have, completely free of charge. Investigating a bug can take hours, or days, sometimes longer. Imagine doing that and it turns out there wasn’t a bug with your program at all, it was with a theme that the user installed. I’d also be pissed off about the time I’m donating for the good of the community being wasted.
You absolutely did lol. You complained about them and it reeked of entitlement. You don’t have a God-given right for the developer of every app to investigate issues with somebody else’s themes.
I see you’ve edited away much of it though. Sneaky.
The gsettings command can change things on the fly in the dconf, assuming that's where the setting actually resides. It's a pain to do, but that means it's possible to write a script that makes the necessary change(s) and that can then be assigned to a keyboard combo.
For example, I have one that toggles a Cinnamon panel between the top and the bottom of its screen (I won't get into why) and currently have it bound to Ctrl-Alt-Space.
It's currently a hack that uses a couple of hardcoded values that I pulled from the dconf by observing what it was set to with the panel in each location. If it finds the first value it changes it to the second, and vice versa.
(In the unlikely event I come to change the layout to something it doesn't recognise, it bails out, doing nothing.)
Anyway, you could probably do something similar to toggle the dark/light mode.
gsettings didn’t work in my case. Which is why i guess it’s libadwaita. Btw, i’m on XFCE.
edit: though, toggling light/dark via gsettings might work.
editedit: it didn’t. But GTK_THEME=<theme> did. Which is kinda troublesome still, since you can’t switch session variable content for the current session. Needs a wrapper script now.
Hello fellow citizen, I almost agree but libadwaita is inherently gnome’s thing, and libadwaita apps are usually closely built into the gnome desktop, so using it outside of gnome seems weird. Kinda like using Dolphin outside of KDE (tho that’s just because of qt). They want to be able to integrate their forks visually.
How are they going to stop using zenity? it is a dependency of steam. And right now the gtk4 version needs a bunch of hacks to follow the system theme as well.
Can’t they theme gtk4/libadwaita without editing libadwaita? Like gradience do
I’ve made a bunch of libadwaita apps, because I like its UI/UX not because I want to break other Desktop Environment. That would mean even more fragmentation.
If they did you’d have one theme that works with Gnome and one that works with Mint. Both of which would be irrelevant to someone using GTK apps on, say, XFCE on Arch.
Libadwaita is only compatible with gnome and only works with gnome. Other DE’s can try to make it work in their DE, but the experience for them is hostile.
To put it mildly, gnome devs are being dicks about it as much as they can be, because they consider themselves the only “real” desktop environment to Linux.
If you want your apps to be cross platform, you can just use gtk3/gtk4 instead, or any other ui library. Even QT.
I use gnome ATM because I think paperwm is the best desktop experience on any OS, but the gnome DE devs are just assholes and they break my heart.
Libadwaita is only compatible with gnome and only works with gnome. Other DE’s can try to make it work in their DE, but the experience for them is hostile.
Not sure what you mean with “compatible”, as libadwaita apps are supposed to work on other DEs as well. It might not fit visually with them, but that’s not being incompatible.
Gnome can’t use the argument that “theming our apps is incompatible” and then at the same time not allow other DEs to manage window controls and the like to be compatible. Shit attitude and shit arguments.
GNOME devs never said that theming is incompatible (just “not supported”), and you’re still not explaining whay you mean with “incompatible” either. Managing window controls also doesn’t seem a requirement to be “compatible”, as the app still runs fine even with client side decorations (again, it just won’t fit visually with the rest of the system).
And by the way, the problem is not theming per-se, but the fact that apps get themed by default, they inevitably break by default, and app developers are left to deal with that. Nobody ever tried to improve the situation so the solution they came up with is to have their apps always look the same.
I use Gnome too and I don’t like their attitude against other DEs. Their attitude is becoming a real threat to Linux interoperability.
At least we got flatpaks.
TL;DR They want to push even more other desktop environments and distros to use XApps, because a lot of gnome’s ex-gtk3 apps now are half-broken and looks alien inside Mint and other distros like Xubuntu.
If an application doesn’t support Cinnamon we can’t ship with it in our Cinnamon edition. The same goes for MATE and Xfce.
[…]
We could do like Ubuntu 24.04. They provide a finished product with a high level of integration. The way they do that is by modifying libAdwaita to support their theme: Yaru. We could do the same with Mint-Y. It would make all GNOME applications look nice in Linux Mint, but we’d have to remove theme selection, since it would only work with Mint-Y. In the long term it wouldn’t solve the main issue either: These applications are designed for a desktop which is more and more different to ours by the day. It’s not just a question of themes or look. Today these apps are losing menubars, themes, tomorrow they might come with no minimize button or anything GNOME doesn’t use.
Add comment