3 ms·

I find the lack of relevant discussion on the article pretty disturbing. Everyone is focused on things that the article never even brought up. Many comments can

I find the lack of relevant discussion on the article pretty disturbing. Everyone is focused on things that the article never even brought up. Many comments can simply be summarized as "I hate GNOME," which is not at all useful to the discussion. Because the design language got split up from GTK, that enables desktops like Cinnamon, MATE, and XFCE to work together on a libxapp which implements the design language common to those desktops. Unfortunately no work has started on that yet, but I hope to see it soon, similar to xdg-desktop-portal-xapp. How people don't see this as a complete win is very strange to me. GTK can't be a dumping ground for every widget pattern that has ever existed. It would be unmaintainable. The people that work on libadwaita is almost entirely, if not entirely, separate from those that work on GTK. This enables GTK developers to focus on the core widgets and toolkit, while implementing the various design languages can be left to others.

zozbot234 2y ago
libadwaita used to be purely about supporting "responsive" applications that would seamlessly switch to a more compact layout when displayed in a smaller window/screen size. There's nothing about this that is 'GNOME design language' specific, so why should other desktop environments work on a different 'design language' library? That's just a pointless duplication of effort. If the GNOME folks want to better support separate design languages, they should start out by reintroducing proper theming support to libadwaita. Right now you can only switch to a different theme by manually overwriting the "adwaita" theme configuration, which is a huge regression compared to what GTK+3 supported.
- tristan957 2y ago
  You are thinking of libhandy, which had similar goals but not the same, hence why libadwaita is not named libhandy.
- crashdancer 2y ago
  >why should other desktop environments work on a different 'design language' library? The responsive widgets are only a small part of libadwaita. Part of the reason those widgets are still there is because they're still being iterated on -- once a widget gets into GTK it has to be maintained for a long time and GTK developers got burned before by adding a lot of random widgets without iterating first. So the bar is understandably a lot higher for adding new GTK widgets than it is for adding widgets into one of these "design language" libraries. I could see some responsive widgets getting merged into GTK but only if they become stable enough and everybody (not just GNOME) likes the API wants them in GTK. >reintroducing proper theming support to libadwaita It does have proper theming support if you're using it as an app developer. If you mean allowing users to add arbitrary themes to arbitrary applications, that isn't going to happen. It can't be done without breaking applications, and arbitrary theming ruins the whole purpose of it anyway which is to enable all GNOME apps to have a consistent UX and theme.
jsnell 2y ago
What's being described does look like a strict improvement over the current state. But Gnome has been burning user and developer trust for more than a decade (both with Gnome 3 and the mismanagement of GTK), so maybe people don't actually trust the description? "It must actually be some attempt to fuck over the the ecosystem again, I just don't see how yet". If things have changed, then that's great! Trust will start to get rebuilt. But it doesn't happen instantly after one announcement.
- crashdancer 2y ago
  >But Gnome has been burning user and developer trust for more than a decade People complained in the exact same way when GTK2 and GNOME 2 were released. There really isn't anything different this time around as to how they approach changes and incremental improvements. It's the same minority of loud complainers blaming GNOME for everything when they could just use something else. It's not like there's a lack of forks and alternatives. And hey, a certain percentage of KDE users complain and fork stuff whenever a new version of KDE comes out too. That's just what happens. As with anything open source, you get what you put in: if you don't contribute anything upstream, and you're not willing to maintain a fork, and you don't want to compromise, and you expect someone else to always "manage" everything to your liking all the time, then you're setting yourself up for disappointment.

zozbot234 2y ago

libadwaita used to be purely about supporting "responsive" applications that would seamlessly switch to a more compact layout when displayed in a smaller window/screen size. There's nothing about this that is 'GNOME design language' specific, so why should other desktop environments work on a different 'design language' library? That's just a pointless duplication of effort. If the GNOME folks want to better support separate design languages, they should start out by reintroducing proper theming support to libadwaita. Right now you can only switch to a different theme by manually overwriting the "adwaita" theme configuration, which is a huge regression compared to what GTK+3 supported.

tristan957 2y ago
You are thinking of libhandy, which had similar goals but not the same, hence why libadwaita is not named libhandy.
crashdancer 2y ago
>why should other desktop environments work on a different 'design language' library? The responsive widgets are only a small part of libadwaita. Part of the reason those widgets are still there is because they're still being iterated on -- once a widget gets into GTK it has to be maintained for a long time and GTK developers got burned before by adding a lot of random widgets without iterating first. So the bar is understandably a lot higher for adding new GTK widgets than it is for adding widgets into one of these "design language" libraries. I could see some responsive widgets getting merged into GTK but only if they become stable enough and everybody (not just GNOME) likes the API wants them in GTK. >reintroducing proper theming support to libadwaita It does have proper theming support if you're using it as an app developer. If you mean allowing users to add arbitrary themes to arbitrary applications, that isn't going to happen. It can't be done without breaking applications, and arbitrary theming ruins the whole purpose of it anyway which is to enable all GNOME apps to have a consistent UX and theme.

jsnell 2y ago

What's being described does look like a strict improvement over the current state. But Gnome has been burning user and developer trust for more than a decade (both with Gnome 3 and the mismanagement of GTK), so maybe people don't actually trust the description? "It must actually be some attempt to fuck over the the ecosystem again, I just don't see how yet". If things have changed, then that's great! Trust will start to get rebuilt. But it doesn't happen instantly after one announcement.

crashdancer 2y ago
>But Gnome has been burning user and developer trust for more than a decade People complained in the exact same way when GTK2 and GNOME 2 were released. There really isn't anything different this time around as to how they approach changes and incremental improvements. It's the same minority of loud complainers blaming GNOME for everything when they could just use something else. It's not like there's a lack of forks and alternatives. And hey, a certain percentage of KDE users complain and fork stuff whenever a new version of KDE comes out too. That's just what happens. As with anything open source, you get what you put in: if you don't contribute anything upstream, and you're not willing to maintain a fork, and you don't want to compromise, and you expect someone else to always "manage" everything to your liking all the time, then you're setting yourself up for disappointment.