16 ms·

Libadwaita: Splitting GTK and Design Language

118 points by butz 2y ago

whalesalad 2y ago
adwaita is the quintessential example of how the hardest programming concepts are naming things and cache invalidation.
mseepgood 2y ago
So is it a new kind of libgnomeui? https://wiki.gnome.org/Attic/LibgnomeMustDie#libgnomeui https://wiki.gnome.org/Attic/LibgnomeMustDie#libgnomeui
- c0l0 2y ago
  Ouch, there's some bitter irony in all of this. See https://wiki.gnome.org/Attic/ProjectRidley https://wiki.gnome.org/Attic/ProjectRidley for an explanation of the goals of this project, which now seems to be what GTK is trying to get away from again.
  - cardanome 2y ago
    Not really? > As Owen said in a recent GTK+ meeting, when looking over the list of APIs that we are discussing here, there are basically three categories: > A) Cross-platform API - things that make sense on Windows / OS X > B) X / freedesktop.org-specific API > C) GNOME-specific API > APIs in category A. are clearly suitable for moving to GTK+, APIs in category B. may or may not be suitable, and things in category C. are better off in a GNOME-specific library. So even back then the official stance was that GNOME specific stuff belongs in external libs.
spookie 2y ago
Agreed, its a understandable that they're choosing this path. FOSS needs to stop having such quasi-religious positions like the ones mentioned at the start of the article, where very understandable decisions are taken as dabs against other projects.
LocutusOfBorges 2y ago
This seems to quite deliberately miss the point of why so many find the effect libadwaita has had on the desktop experience to be so frustrating. Really, it doesn’t matter whether the underlying motivations were supposedly to create a cleaner separation between projects at the abstract level - the consequences have been to introduce a situation where, for the first time in quite a long period, large swathes of significant, widely-used programs are no longer capable of fitting in on non-GNOME desktops. That decision was theirs to make, and they were entirely free to do so - but squirming around the point to avoid talking about responsibility for the actual consequences of the decision re further fracturing the Linux desktop ecosystem is absurd.
- NekkoDroid 2y ago
  > the consequences have been to introduce a situation where, for the first time in quite a long period, large swathes of significant, widely-used programs are no longer capable of fitting in on non-GNOME desktops. I still am looking for this magical theme that makes QT apps feel like it fits on a GNOME desktop. Like, not matter how much you theme, the UX is going to be different and that can't really be changed without rewriting the entire app in a different toolkit with the target UX in mind. GNOME and KDE UX are completely different. One gives you the bare necessaties of options mostly behind a hamburger menu and a nice amount of padding, while the other throws every option and the kitchen sink at you with a relativly high dencity of content. They target different people, which is fine as no size fits all.
  - simion314 2y ago
    >I still am looking for this magical theme that makes QT apps feel like it fits on a GNOME desktop. Qt does the work to integrate with Windows and OSX, by this I do not mean that it paints the exact shame of border colors on the buttons but more deeper integration, like integrating with the native System Tray, desktop APIs, the correct order of OK/Cancel buttons. For linux the Qt devs are aware that each distribution has it's own colors,, fonts and crap so it would be a waste to target only a distro say Red Hat. KDE did the work to make GTK apps integrate as much as possible but I think GNOME did zero work to integrate Qt or KDE apps and they tried sabotaging everyone else by removing the Tray or the server decoration. I am not that type of user that needs all apps to have the exact same buttons otherwise my brain segfaults, I use KDE apps, GTK apps, Java apps, Electron apps. What I want from this apps is to use same Open File Dialogs and not be like GTK where the native GTK file picker has a weird sorting option for files and folders that do not match any other popular and sane system. Also I remember GNOME guys claiming that you do not need thumbnails in the File Picker, that you are doing it wrong and the reality was that it was not easy to add the feature so they preferred to push that excuse that you are doing it wrong.
BoredPositron 2y ago
I hope cosmic puts an end to this neverending discussions about bad decisions from the gnome foundation. They can go under for all I care. Overall I truly believe they did a disservice to the whole Linux Desktop and the community over the last 15 years.
- pid-1 2y ago
  What's cosmic?
  - ianlevesque 2y ago
    Yet another desktop environment https://github.com/pop-os/cosmic https://github.com/pop-os/cosmic
  - thesuperbigfrog 2y ago
    A desktop environment that System 76 is making: https://blog.system76.com/post/cosmic-the-road-to-alpha https://blog.system76.com/post/cosmic-the-road-to-alpha
  - 9dev 2y ago
    Looks like yet another uncanny clone of MacOS UI
- erikpukinskis 2y ago
  What disservice?
- cl3misch 2y ago
  Isn't Cosmic based on Gnome? If yes, at least they did a service to enable the Cosmic DE.
  - davet91 2y ago
    The new Cosmic is written from scratch in Rust with the iced GUI library.
themerone 2y ago
Are we in a state where GTK4 is the GNOME toolkit and non GNOME apps will be permanently stuck on GTK3?
- bonzini 2y ago
  The opposite: "GTK had the unique case of bundling GNOME’s design language into GTK, which made it far from generic [...] Thanks to the removal of GNOME widgets from GTK 4, [...] developers of cross-platform GTK 3 apps that rely exclusively on general-purpose widgets can be more confident that GTK 4 won’t remove these widgets, and hopefully enjoy the benefits that GTK 4 offers".
- kelnos 2y ago
  Yes and no. The reality seems to be that GTK is a lot more desktop-agnostic, but in a way that means non-GNOME app developers (or non-GNOME desktop environment developers[0]) have to build a lot of functionality themselves that was removed from GTK4 (and/or has been deprecated and will be removed in GTK5). To make matters worse, GTK4 "tightens up" some interfaces, making it harder to extend. So, for example, you can no longer "wrap" a native window handle on X11 with a GdkWindow (an interface that also no longer exists, in favor of a Wayland-centric GdkSurface interface) in order to integrate something "foreign" into the toolkit. They've also removed things like GtkSocket & GtkPlug, so you can't do cross-process embedding anymore[1]. I think it's fair to say, though that GTK4+libadwaita is "the GNOME toolkit", and GTK4 alone is just a much less capable, less extensible, less "batteries included" toolkit than GTK3, and GTK5 will drive even further in that direction, if GTK4's deprecation list is any indication. [0] Full disclosure: I'm an Xfce developer, and have been disappointed with the direction GTK has been taking for some time. I don't begrudge them their prerogative to do what they need/want to achieve their own goals with the toolkit they've built and maintain. But it really is making life more difficult for me. [1] Part of the argument is that Wayland doesn't natively support things like cross-process embedding, so a cross-platform toolkit shouldn't have these types of widgets (the classic problem of only being able to support the lowest common denominator). But a) you can absolutely build something like that for Wayland (something I've been working on, though it requires tens of thousands of lines of code to do), and b) with other changes, it's incredibly difficult and possibly impossible to even implement the XEMBED protocol on GTK4, for people who do only care about X11.
ginko 2y ago
Just give me back normal window headers already. And put Okay/Cancel to the bottom right like any other UI toolkit in existence
- red_admiral 2y ago
  I would personally like the title bar of the active window, and only the active window, to be my preferred accent color. Not a 1px colored border, an actual title bar.
  - phkahler 2y ago
    And please keep widgets out of the title bar. Those make it very hard to drag windows around because you can't really be certain what can be clicked and dragged to move the window. BTW MS windows does this even worse IMHO - I can't tell what app I'm using (think opening a document say .pdf or even an email in outlook), can't tell which is the active title bar, and not sure what I can drag it by.
    - bityard 2y ago
      I just started using a Mac for work and this is pretty prevalent on Mac as well, possibly that is where it originated. Applications on Mac are a random assortment of regular apps with proper titlebars and apps which effectively have no titlebar. Mac OS keyboard/mouse focus is also intensely weird and inconsistent. The rules for when a click brings a window into mouse and/or keyboard focus are basically unpredictable, as far as I can tell. When you click a window to focus it, some applications use that click to put the keyboard/mouse focus on the widget you clicked on. Others "eat" the click before bringing the window to the foreground. So if you want to activate a specific text field or whatever for keyboard focus, you have to click _twice_ every time you switch focus back to a particular app. But if you do that, you have to _space your clicks apart_ to prevent them from being interpreted as a double-click! Which might maximize the window if you clicked on the area that would otherwise have been the app's title bar! It also throws me off at least once an hour that you use can the mouse scroll wheel and all mouse buttons except 1 and 2 in a window _without_ bringing it into focus. After my work day is done, I am always so much happier to go back to Plasma for my personal stuff and hobbies.
fngjdflmdflg 2y ago
>As a result, GTK and GNOME’s design language clashed together. Instead of being as general-purpose as possible, GTK as a cross-platform toolkit contained an entire design language intended to be used only by a specific desktop, thus defeating the purpose of a cross-platform toolkit. This is one of the things I like about Flutter. It supports both Material and iOS UI guidelines. There is also an ongoing effort called Blank Canvas[0] to provide easier support for creating arbitrary UI themes (although you can already do this albeit more difficultly). Being that Material looks awful to me (as an Android user, even) I'm glad that they support different UI Designs/guides. [0] design doc: https://docs.google.com/document/d/1rS_RO2DQ_d4_roc3taAB6vXFjv7-9hJP7pyZ9NhPOdA/edit?resourcekey=0-VBzTPoqLwsruo0j9dokuOg#heading=h.34a91yqebirw https://docs.google.com/document/d/1rS_RO2DQ_d4_roc3taAB6vXF...
- fl0ki 2y ago
  The only thing worse than modern Material is when there was a multi-year (?) period where Google didn't think buttons needed any affordance indicating they were buttons, not in shape, contrast, color, etc. and with touch UIs you don't even get hover feedback like you would on the web. Reading between the lines, I can see that Google was inspired by the post-skeumorphic minimalism of iOS, but took the wrong lessons away from it. Some of that has been walked back, but far from enough.
  - fngjdflmdflg 2y ago
    To me Material looks like Google looked at iOS and compared it to their then rectangle-box based UI and said "Our UI is too bland compared to Apple. We must need tons of border radius and padding. And big splash animations when you touch a button!" Some people used to look down on Apple's UI as "fisher price" but Google has long taken that crown in my book. When I make flutter apps for side projects I just use the Apple based widgets (called Cupertino [0]). [0] https://docs.flutter.dev/ui/widgets/cupertino https://docs.flutter.dev/ui/widgets/cupertino
  - pentagrama 2y ago
    I remember being annoyed by those text buttons, looking at the latest iteration of Material, it looks like they keep the "text" button style but as a secondary option https://m3.material.io/components/all-buttons https://m3.material.io/components/all-buttons Looking at the examples I think that it works in some contexts, but is a personal feel that I have.
jl6 2y ago
I’ve been a happy XFCE user for years, and although it uses GTK I’ve never run into whatever drama is going on here.
- gapan 2y ago
  Then I guess you missed the huge pile of mess that CSD made when they were first introduced to Xfce.
  - jl6 2y ago
    I guess I did. I didn’t know what CSD was until just now. Is this something that using Xubuntu has shielded me from? I’ve been using it since around 2016, maybe a bit earlier, (using the default theme) and it’s never seemed to be a problem.
    - gapan 2y ago
      I don't use xubuntu, but I don't think so. I don't see how xubuntu wouldn't be affected since this is a GTK+ issue. Starting any CSD application in Xfce will behave and look out of place and unfortunately, even some Xfce applications and tools used CSD (perhaps some still do).
- multani 2y ago
  Xfce has libxfceui4, which should be equivalent to libadwaita (I never directly used it, but that was at least my understanding of it)
jrm4 2y ago
Bahahaha. In which GNOME finally realizes that they are not, and never will be, a Steve Jobs.
- fl0ki 2y ago
  It's even worse than that. Choosing to copy another OS should have made the rest easy because it eliminates many design decisions and lets you focus on implementation. Somehow they still blew it, copying limitations rather than advantages. It doesn't help that they think extensions are an excuse not to finish features in the DE itself, while leaving the extension experience so poorly conceived and implemented that you have more confidence installing a Skyrim mod than a GNOME extension.
  - crashdancer 2y ago
    If you have any better ideas and you'd like to step up to write and maintain a different extension API, then you should do that. If not, then welcome to the club with all the other open source maintainers where everyone is underpaid and overworked and no one has any time to work on all the things they want to do.
    - deleted 2y ago
      [deleted]
- anthk 2y ago
  Gnome 1.4 borrowed a lot from OS8/9. Then, Gnome 2 got a bit of inspiration of Copland and Mac OS9/halfway to 10. Gnome 3 tries to badly copy OSX (and MacOS tries to do the same with some stuff from both iOS and Gnome). Still, MacOS can dream about having something like QT and not-walled software repositories.
Aerbil313 2y ago
GTK & GNOME are very successful projects in making me thankful to God that QT & KDE exist every time I have to use them.
- postmodest 2y ago
  If Qt had just made peace with the GPL back in the 90's, we wouldn't have this problem. C.f. Motif/BSD.
sed3 2y ago
[flagged]
- abrouwers 2y ago
  That's not true at all, they even publish weekly reports of how donations are used to support the Gnome ecosystem: https://thisweek.gnome.org/ https://thisweek.gnome.org/
  - sed3 2y ago
    [flagged]
cookiengineer 2y ago
It's kinda ironic that they realized (and admitted) this more than 15 years later. Meanwhile, there's Cinammon, MATE, pantheon, moblin, clutter, mutter, unity, and several others that went into being hardforks at this point because they didn't agree with GNOME's Human Interface Guidelines. It's also ironic that the only thing using GTK2 components on every system at this point is GIMP. The problem with upstream GTK's workflow is that they have so many breaking releases and their own versioning scheme that is completely different from any other project, making it impossible to rely upon. A UI component framework should be reliable, stable in its API and scene graph, and not break with any second release every couple months.
- kelnos 2y ago
  > The problem with upstream GTK's workflow is that they have so many breaking releases and their own versioning scheme that is completely different from any other project Not sure what you mean. GTK uses semver; any 2.x or 3.x or 4.x release will work with software built around a previous release with the same major version. You can argue that GTK breaks API/ABI and increments their major version too often (I'm not sure I'd agree with that, but you can certainly argue it), but, outside of bugs, I don't recall instances where apps had to be modified to continue to work with new releases in the same major version of GTK. I do think it's notable that GIMP is still on GTK2, and the GTK3 porting effort has gone on for many years now. But I think it's also notable that GIMP is the exception, not the rule. On my system, for example, only GIMP requires GTK2, and I have over 100 binaries in /usr/bin/ that link to GTK3
  - IAmLiterallyAB 2y ago
    I remember GTK themes used to break every couple releases. Is that not an API break?
  - cookiengineer 2y ago
    GTK doesn't use semantic versioning. Every uneven minor version is a development cycle, every even minor version is a stable cycle. And as it happened so often, every dev cycle things broke down, because of intertwined dependencies of GTK, gjs and glibc (and gobject introspection bindings). See also: https://blog.gtk.org/2016/09/01/versioning-and-long-term-stability-promise-in-gtk/ https://blog.gtk.org/2016/09/01/versioning-and-long-term-sta... I also think you're kind of proving my point. If the project that is supposed to be _the demo use case_ of the _GIMP Tool Kit_ and needs more than a decade to update its scenes, views, and widgets...then maybe this is not the right toolkit for anyone, because pretty much every CEO will go rogue when they see the development time needed to port anything to GTK. And it doesn't have to be like that. It's an architecture design decision they made, where they also chose vala as their own NIH programming language to integrate things over other more established options. Same goes for glibc and gjs which meanwhile has so many bugs I can probably exploit it with a heap spraying exploit from 10 years ago, as it conceptually is yet another hard forked project inside the GNOME ecosystem which can never be updated with its upstream project dependencies/origins. My point is that the GNOME project introduced maintenance burden upon themselves, and that's what's killing the GTK ecosystem. And they themselves could have avoided that. (Apart from the outdated documentation whose example demos don't even compile, whereas the getting started effect with QML is a matter of minutes, not days) I don't wanna derail this discussion too much. It's great that GTK is evolving and adapting. I just wish they would focus on ease of use rather than inventing their own tech stack wherever possible.
phkahler 2y ago
Which things are in libadwaita and not GTK? I thought the article said Dialog boxes, which would be incredibly bad for cross-platform apps if they need to be handled separately on a different OS.
- bonzini 2y ago
  It's not dialog boxes per se that are in libadwaita, it's things such as where to place buttons and in what order, and also what are the standard labels for the buttons (e.g. should the dialog have Yes/No/Cancel or Don't Save/Cancel/Save buttons? That's the difference between the Windows design language and the Apple design language).
  - phkahler 2y ago
    OK, but does that mean I don't get cross platform dialogs with GTK?
    - bonzini 2y ago
      You never did. There was never a widget that knew that "No" was in the middle on Windows and on the far left (but spelled differently) on macOS. I have no idea if/how Qt does it. If you need to ask a question, GTK does provide both GtkMessageDialog (deprecated) and GtkAlertDialog (new). But they will look "off" on some platforms due to not respecting the native design language. If you need a more complex dialog box, you don't need GtkDialog which was just a convenience over other APIs but, with over 25 years of hindsight, wasn't as good as it seemed to be.
jandrese 2y ago
Wait, GtkDialog is considered a GNOME thing and is now depricated? They article claims "These aforementioned widgets only benefited GNOME apps, as they were strictly designed to provide widgets that conformed to the GNOME HIG.", but GtkDialog is the primary way to provide a modal dialog in GTK. That seems like a fairly general problem.
- the_biot 2y ago
  It's entirely logical for the Gnome folks to do this. They've been removing features and widgets from all kinds of programs for literally decades; Gnome is fundamentally a destructive project. Outright sabotaging GTK (which predates and inspired Gnome) is just the logical way forward on this multi-decade orgy of destruction.
  - crashdancer 2y ago
    It's odd you say those things because I've been enjoying GNOME for years and I find they make great additions all the time. For me GTK4 has been a massive improvement over GTK3. There aren't actually any GNOME developers who enjoy removing things just to annoy users -- human beings have limited time and sometimes tough decisions have to be made about what's going to make it in and what isn't.
    - rleigh 2y ago
      Yeah. It really does take more effort to leave perfectly working functionality in place than to do the work to remove it. Come on. Many of the decisions made by the GTK+ developers are utterly unjustifiable. Take the removal of GtkHBox and GtkVBox in place of GtkBox. A couple of shims for backward compatibility would have taken just a few lines of code and would have avoided a hard compatibility break. Did that happen? No. So a huge burden to update every GTK+ application (incompatibly!) was imposed upon every developer on the planet. Was that a productive use of resources? No. It was an utterly illogical change which had zero real-world benefit to anyone. And that's just one of many, many bad decisions. There are very valid complaints to be made about GTK+, and you can't handwave them all away with some PR comments.
fnalelal 2y ago
Good. What Linux needs is libwidgets, i.e. GTK, to have widgets for desktop applications. And, separately, libwankery, where the GNOME geniuses can implement whatever nonsensical "design language" they want for their 0.003% of the market user base.
kelnos 2y ago
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.
- HumanOstrich 2y ago
  I was with you until you suggested rewriting everything in Rust.
  - deleted 2y ago
tristan957 2y ago
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.
Raxelgrande 2y ago
I have been using GNOME as my primary desktop environment since version 38. To be honest, it got bad when Libadwaita/GTK4 released. I did a forum post on the EndeavourOS Linux forum talking about this, back in late 2023 and i reposted it on GNOME's forums, without any success. From what i know they didn't work on the feedback i gave. https://forum.endeavouros.com/t/constructive-gnome-a-bit-of-gtk-criticism/48330 https://forum.endeavouros.com/t/constructive-gnome-a-bit-of-... GNOME on GTK3 was a lot more stable and quite faster, specially for the desktop effects and the design of the overview was a lot easier on mouse users (now you have to scroll all around the screen to just do things). The focus of this is GTK but i want to quickly mention that GNOME is hostile to developers making extensions. Recently they updated something in the Javascript they use for developing extensions, breaking all of them, and providing a porting guide very close to the deadline of the next GNOME release, barely giving developers working on their free time, time to port things, or they would get a storm of users complaining to port the program (don't believe me? browse GNOME's extension store for 5 minutes). The first and most damaging thing i faced as a user was a very nasty bug in GTK4 that made scrolling impossible (the bug is still alive today when using touchpads) https://gitlab.gnome.org/GNOME/gtk/-/issues/2971 https://gitlab.gnome.org/GNOME/gtk/-/issues/2971 . The most crazy thing is that this critical bug for UX was detected in mid 2020, yet 4 years later it's still present on GTK. GNOME decided to break people's computers by shipping this critical bug. To me this is enough reason to not use it as a UI library. Imagine not having working scrolling... Oh wait, it's still going! But the bugs don't stop there! GTK4 has had trouble with drag and drop support, since Nautilus' (the file manager) port to GTK4, it completely broke DnD support of File Roller (the archive manager). Now that File Roller got updated to GTK4 the problem surely got fixed, right? NO! In fact, now File Roller broke DnD for every program! You really have to be bad to ship very broken features to an increasingly bigger user base. Even KDE's recent port to QT6 had less bugs! Another thing that annoys me is the lack of customization. Back in GTK3 days all you needed was a GTK theme, even GNOME's Libhandy could get themed without problems. It got to a point where developers did a nothingburger note on customization https://stopthemingmy.app/ https://stopthemingmy.app/ . That didn't stop anyone. Now you need to know what themes support GTK4 and what theming hack to run on it, and don't get me started on theming Flatpak... GTK4 never got proper support for theming, making the unreliable hacking methods the only way to theme it, without modifying the program's source. Now it ships in production with Ubuntu 24.04 (they did the right call to avoid GTK4 in 22.04 by rolling back some programs). The closest thing to an "official" theming is the Gradience program https://gradienceteam.github.io/ https://gradienceteam.github.io/ It's specially bad and annoying, with barely any good themes that support Libadwaita, it got to the point i developed a small program to simplify theming of Linux, called Iris https://github.com/Raxelgrande/Iris https://github.com/Raxelgrande/Iris . The other and probably most important roadblock for GTK is that it still lacks support for mobile devices, making the big strength of adaptable design it has go to waste. Nobody is going to buy a Linux phone. Overall, GTK and GNOME are very lackluster and im pretty sure that i will avoid that toolkit like the plague. All that Libadwaita does is to lock people into GNOME's design, even if you don't like it. Good luck running programs as good as Bottles and having it look integrated in your desktop. All because they just can't be bothered to at least add a theming API so everyone stops using hacky, problem ridden approaches.
paradox460 2y ago
I will forever find it the pinnacle of missed opportunities that Linux wound up with it's own ux system, rather than using the systems that came out of NeXT via OpenSTEP/GNUstep
- linguae 2y ago
  I feel the exact same way. I wish FOSS desktop advocates in the 1990s either rallied behind the development of GNUstep, or I wish that during the time when Qt had a non-FOSS license, the Harmony project (https://en.wikipedia.org/wiki/Harmony_(toolkit) https://en.wikipedia.org/wiki/Harmony_(toolkit)) had gotten greater attention as a workaround against Qt's licensing issues. Even standardizing on Win32/Wine might have been a better outcome. Unfortunately we ended up with the Qt/GTK split and everything that resulted from that. Don't get me wrong. KDE, GNOME, and other leading FOSS desktops aren't bad, and it's quite remarkable what they achieved over the past 25+ years. However, I feel we could've ended up with something better, something that would amaze even Mac users. I could imagine a few alternative timelines where the FOSS desktop community rallied behind GNUstep, or perhaps some of the more research-minded people in the community would've gone all the way and came up with some sort of radical GUI inspired by the Smalltalk and Lisp machines of old, as well as some of Apple's 1990s experiments. (Given RMS's affinity for Lisp and his Lisp machine roots, this wouldn't have been too crazy.) I have many thoughts (http://mmcthrow-musings.blogspot.com/2020/04/a-proposal-for-flexible-composable.html http://mmcthrow-musings.blogspot.com/2020/04/a-proposal-for-...) about what my ideal desktop environment would be like, but I haven't had the time to work on them. Maybe if I win the lottery....
  - anthk 2y ago
    Gnome 1.4 had Sawfish, a window manager expandable with Lisp.
- LeFantome 2y ago
  I am with you. The NeXT APIs were so good for the time. The real missed opportunity was that macOS essentially uses those same APIs to this day. We could have had an open source apps platform that was source code compatible with macOS!

118 points by butz 2y ago

adwaita is the quintessential example of how the hardest programming concepts are naming things and cache invalidation.

So is it a new kind of libgnomeui? https://wiki.gnome.org/Attic/LibgnomeMustDie#libgnomeui https://wiki.gnome.org/Attic/LibgnomeMustDie#libgnomeui

c0l0 2y ago
Ouch, there's some bitter irony in all of this. See https://wiki.gnome.org/Attic/ProjectRidley https://wiki.gnome.org/Attic/ProjectRidley for an explanation of the goals of this project, which now seems to be what GTK is trying to get away from again.
- cardanome 2y ago
  Not really? > As Owen said in a recent GTK+ meeting, when looking over the list of APIs that we are discussing here, there are basically three categories: > A) Cross-platform API - things that make sense on Windows / OS X > B) X / freedesktop.org-specific API > C) GNOME-specific API > APIs in category A. are clearly suitable for moving to GTK+, APIs in category B. may or may not be suitable, and things in category C. are better off in a GNOME-specific library. So even back then the official stance was that GNOME specific stuff belongs in external libs.

spookie 2y ago

Agreed, its a understandable that they're choosing this path. FOSS needs to stop having such quasi-religious positions like the ones mentioned at the start of the article, where very understandable decisions are taken as dabs against other projects.

LocutusOfBorges 2y ago

This seems to quite deliberately miss the point of why so many find the effect libadwaita has had on the desktop experience to be so frustrating. Really, it doesn’t matter whether the underlying motivations were supposedly to create a cleaner separation between projects at the abstract level - the consequences have been to introduce a situation where, for the first time in quite a long period, large swathes of significant, widely-used programs are no longer capable of fitting in on non-GNOME desktops. That decision was theirs to make, and they were entirely free to do so - but squirming around the point to avoid talking about responsibility for the actual consequences of the decision re further fracturing the Linux desktop ecosystem is absurd.

NekkoDroid 2y ago
> the consequences have been to introduce a situation where, for the first time in quite a long period, large swathes of significant, widely-used programs are no longer capable of fitting in on non-GNOME desktops. I still am looking for this magical theme that makes QT apps feel like it fits on a GNOME desktop. Like, not matter how much you theme, the UX is going to be different and that can't really be changed without rewriting the entire app in a different toolkit with the target UX in mind. GNOME and KDE UX are completely different. One gives you the bare necessaties of options mostly behind a hamburger menu and a nice amount of padding, while the other throws every option and the kitchen sink at you with a relativly high dencity of content. They target different people, which is fine as no size fits all.
- simion314 2y ago
  >I still am looking for this magical theme that makes QT apps feel like it fits on a GNOME desktop. Qt does the work to integrate with Windows and OSX, by this I do not mean that it paints the exact shame of border colors on the buttons but more deeper integration, like integrating with the native System Tray, desktop APIs, the correct order of OK/Cancel buttons. For linux the Qt devs are aware that each distribution has it's own colors,, fonts and crap so it would be a waste to target only a distro say Red Hat. KDE did the work to make GTK apps integrate as much as possible but I think GNOME did zero work to integrate Qt or KDE apps and they tried sabotaging everyone else by removing the Tray or the server decoration. I am not that type of user that needs all apps to have the exact same buttons otherwise my brain segfaults, I use KDE apps, GTK apps, Java apps, Electron apps. What I want from this apps is to use same Open File Dialogs and not be like GTK where the native GTK file picker has a weird sorting option for files and folders that do not match any other popular and sane system. Also I remember GNOME guys claiming that you do not need thumbnails in the File Picker, that you are doing it wrong and the reality was that it was not easy to add the feature so they preferred to push that excuse that you are doing it wrong.

BoredPositron 2y ago

I hope cosmic puts an end to this neverending discussions about bad decisions from the gnome foundation. They can go under for all I care. Overall I truly believe they did a disservice to the whole Linux Desktop and the community over the last 15 years.

pid-1 2y ago
What's cosmic?
- ianlevesque 2y ago
  Yet another desktop environment https://github.com/pop-os/cosmic https://github.com/pop-os/cosmic
- thesuperbigfrog 2y ago
  A desktop environment that System 76 is making: https://blog.system76.com/post/cosmic-the-road-to-alpha https://blog.system76.com/post/cosmic-the-road-to-alpha
- 9dev 2y ago
  Looks like yet another uncanny clone of MacOS UI
erikpukinskis 2y ago
What disservice?
cl3misch 2y ago
Isn't Cosmic based on Gnome? If yes, at least they did a service to enable the Cosmic DE.
- davet91 2y ago
  The new Cosmic is written from scratch in Rust with the iced GUI library.

themerone 2y ago

Are we in a state where GTK4 is the GNOME toolkit and non GNOME apps will be permanently stuck on GTK3?

bonzini 2y ago
The opposite: "GTK had the unique case of bundling GNOME’s design language into GTK, which made it far from generic [...] Thanks to the removal of GNOME widgets from GTK 4, [...] developers of cross-platform GTK 3 apps that rely exclusively on general-purpose widgets can be more confident that GTK 4 won’t remove these widgets, and hopefully enjoy the benefits that GTK 4 offers".
kelnos 2y ago
Yes and no. The reality seems to be that GTK is a lot more desktop-agnostic, but in a way that means non-GNOME app developers (or non-GNOME desktop environment developers[0]) have to build a lot of functionality themselves that was removed from GTK4 (and/or has been deprecated and will be removed in GTK5). To make matters worse, GTK4 "tightens up" some interfaces, making it harder to extend. So, for example, you can no longer "wrap" a native window handle on X11 with a GdkWindow (an interface that also no longer exists, in favor of a Wayland-centric GdkSurface interface) in order to integrate something "foreign" into the toolkit. They've also removed things like GtkSocket & GtkPlug, so you can't do cross-process embedding anymore[1]. I think it's fair to say, though that GTK4+libadwaita is "the GNOME toolkit", and GTK4 alone is just a much less capable, less extensible, less "batteries included" toolkit than GTK3, and GTK5 will drive even further in that direction, if GTK4's deprecation list is any indication. [0] Full disclosure: I'm an Xfce developer, and have been disappointed with the direction GTK has been taking for some time. I don't begrudge them their prerogative to do what they need/want to achieve their own goals with the toolkit they've built and maintain. But it really is making life more difficult for me. [1] Part of the argument is that Wayland doesn't natively support things like cross-process embedding, so a cross-platform toolkit shouldn't have these types of widgets (the classic problem of only being able to support the lowest common denominator). But a) you can absolutely build something like that for Wayland (something I've been working on, though it requires tens of thousands of lines of code to do), and b) with other changes, it's incredibly difficult and possibly impossible to even implement the XEMBED protocol on GTK4, for people who do only care about X11.

ginko 2y ago

Just give me back normal window headers already. And put Okay/Cancel to the bottom right like any other UI toolkit in existence

red_admiral 2y ago
I would personally like the title bar of the active window, and only the active window, to be my preferred accent color. Not a 1px colored border, an actual title bar.
- phkahler 2y ago
  And please keep widgets out of the title bar. Those make it very hard to drag windows around because you can't really be certain what can be clicked and dragged to move the window. BTW MS windows does this even worse IMHO - I can't tell what app I'm using (think opening a document say .pdf or even an email in outlook), can't tell which is the active title bar, and not sure what I can drag it by.
  - bityard 2y ago
    I just started using a Mac for work and this is pretty prevalent on Mac as well, possibly that is where it originated. Applications on Mac are a random assortment of regular apps with proper titlebars and apps which effectively have no titlebar. Mac OS keyboard/mouse focus is also intensely weird and inconsistent. The rules for when a click brings a window into mouse and/or keyboard focus are basically unpredictable, as far as I can tell. When you click a window to focus it, some applications use that click to put the keyboard/mouse focus on the widget you clicked on. Others "eat" the click before bringing the window to the foreground. So if you want to activate a specific text field or whatever for keyboard focus, you have to click _twice_ every time you switch focus back to a particular app. But if you do that, you have to _space your clicks apart_ to prevent them from being interpreted as a double-click! Which might maximize the window if you clicked on the area that would otherwise have been the app's title bar! It also throws me off at least once an hour that you use can the mouse scroll wheel and all mouse buttons except 1 and 2 in a window _without_ bringing it into focus. After my work day is done, I am always so much happier to go back to Plasma for my personal stuff and hobbies.

fngjdflmdflg 2y ago

>As a result, GTK and GNOME’s design language clashed together. Instead of being as general-purpose as possible, GTK as a cross-platform toolkit contained an entire design language intended to be used only by a specific desktop, thus defeating the purpose of a cross-platform toolkit. This is one of the things I like about Flutter. It supports both Material and iOS UI guidelines. There is also an ongoing effort called Blank Canvas[0] to provide easier support for creating arbitrary UI themes (although you can already do this albeit more difficultly). Being that Material looks awful to me (as an Android user, even) I'm glad that they support different UI Designs/guides. [0] design doc: https://docs.google.com/document/d/1rS_RO2DQ_d4_roc3taAB6vXFjv7-9hJP7pyZ9NhPOdA/edit?resourcekey=0-VBzTPoqLwsruo0j9dokuOg#heading=h.34a91yqebirw https://docs.google.com/document/d/1rS_RO2DQ_d4_roc3taAB6vXF...

fl0ki 2y ago
The only thing worse than modern Material is when there was a multi-year (?) period where Google didn't think buttons needed any affordance indicating they were buttons, not in shape, contrast, color, etc. and with touch UIs you don't even get hover feedback like you would on the web. Reading between the lines, I can see that Google was inspired by the post-skeumorphic minimalism of iOS, but took the wrong lessons away from it. Some of that has been walked back, but far from enough.
- fngjdflmdflg 2y ago
  To me Material looks like Google looked at iOS and compared it to their then rectangle-box based UI and said "Our UI is too bland compared to Apple. We must need tons of border radius and padding. And big splash animations when you touch a button!" Some people used to look down on Apple's UI as "fisher price" but Google has long taken that crown in my book. When I make flutter apps for side projects I just use the Apple based widgets (called Cupertino [0]). [0] https://docs.flutter.dev/ui/widgets/cupertino https://docs.flutter.dev/ui/widgets/cupertino
- pentagrama 2y ago
  I remember being annoyed by those text buttons, looking at the latest iteration of Material, it looks like they keep the "text" button style but as a secondary option https://m3.material.io/components/all-buttons https://m3.material.io/components/all-buttons Looking at the examples I think that it works in some contexts, but is a personal feel that I have.

jl6 2y ago

I’ve been a happy XFCE user for years, and although it uses GTK I’ve never run into whatever drama is going on here.

gapan 2y ago
Then I guess you missed the huge pile of mess that CSD made when they were first introduced to Xfce.
- jl6 2y ago
  I guess I did. I didn’t know what CSD was until just now. Is this something that using Xubuntu has shielded me from? I’ve been using it since around 2016, maybe a bit earlier, (using the default theme) and it’s never seemed to be a problem.
  - gapan 2y ago
    I don't use xubuntu, but I don't think so. I don't see how xubuntu wouldn't be affected since this is a GTK+ issue. Starting any CSD application in Xfce will behave and look out of place and unfortunately, even some Xfce applications and tools used CSD (perhaps some still do).
multani 2y ago
Xfce has libxfceui4, which should be equivalent to libadwaita (I never directly used it, but that was at least my understanding of it)

jrm4 2y ago

Bahahaha. In which GNOME finally realizes that they are not, and never will be, a Steve Jobs.

fl0ki 2y ago
It's even worse than that. Choosing to copy another OS should have made the rest easy because it eliminates many design decisions and lets you focus on implementation. Somehow they still blew it, copying limitations rather than advantages. It doesn't help that they think extensions are an excuse not to finish features in the DE itself, while leaving the extension experience so poorly conceived and implemented that you have more confidence installing a Skyrim mod than a GNOME extension.
- crashdancer 2y ago
  If you have any better ideas and you'd like to step up to write and maintain a different extension API, then you should do that. If not, then welcome to the club with all the other open source maintainers where everyone is underpaid and overworked and no one has any time to work on all the things they want to do.
  - deleted 2y ago
    [deleted]
anthk 2y ago
Gnome 1.4 borrowed a lot from OS8/9. Then, Gnome 2 got a bit of inspiration of Copland and Mac OS9/halfway to 10. Gnome 3 tries to badly copy OSX (and MacOS tries to do the same with some stuff from both iOS and Gnome). Still, MacOS can dream about having something like QT and not-walled software repositories.

Aerbil313 2y ago

GTK & GNOME are very successful projects in making me thankful to God that QT & KDE exist every time I have to use them.

postmodest 2y ago
If Qt had just made peace with the GPL back in the 90's, we wouldn't have this problem. C.f. Motif/BSD.

sed3 2y ago

[flagged]

abrouwers 2y ago
That's not true at all, they even publish weekly reports of how donations are used to support the Gnome ecosystem: https://thisweek.gnome.org/ https://thisweek.gnome.org/
- sed3 2y ago
  [flagged]

cookiengineer 2y ago

It's kinda ironic that they realized (and admitted) this more than 15 years later. Meanwhile, there's Cinammon, MATE, pantheon, moblin, clutter, mutter, unity, and several others that went into being hardforks at this point because they didn't agree with GNOME's Human Interface Guidelines. It's also ironic that the only thing using GTK2 components on every system at this point is GIMP. The problem with upstream GTK's workflow is that they have so many breaking releases and their own versioning scheme that is completely different from any other project, making it impossible to rely upon. A UI component framework should be reliable, stable in its API and scene graph, and not break with any second release every couple months.

kelnos 2y ago
> The problem with upstream GTK's workflow is that they have so many breaking releases and their own versioning scheme that is completely different from any other project Not sure what you mean. GTK uses semver; any 2.x or 3.x or 4.x release will work with software built around a previous release with the same major version. You can argue that GTK breaks API/ABI and increments their major version too often (I'm not sure I'd agree with that, but you can certainly argue it), but, outside of bugs, I don't recall instances where apps had to be modified to continue to work with new releases in the same major version of GTK. I do think it's notable that GIMP is still on GTK2, and the GTK3 porting effort has gone on for many years now. But I think it's also notable that GIMP is the exception, not the rule. On my system, for example, only GIMP requires GTK2, and I have over 100 binaries in /usr/bin/ that link to GTK3
- IAmLiterallyAB 2y ago
  I remember GTK themes used to break every couple releases. Is that not an API break?
- cookiengineer 2y ago
  GTK doesn't use semantic versioning. Every uneven minor version is a development cycle, every even minor version is a stable cycle. And as it happened so often, every dev cycle things broke down, because of intertwined dependencies of GTK, gjs and glibc (and gobject introspection bindings). See also: https://blog.gtk.org/2016/09/01/versioning-and-long-term-stability-promise-in-gtk/ https://blog.gtk.org/2016/09/01/versioning-and-long-term-sta... I also think you're kind of proving my point. If the project that is supposed to be _the demo use case_ of the _GIMP Tool Kit_ and needs more than a decade to update its scenes, views, and widgets...then maybe this is not the right toolkit for anyone, because pretty much every CEO will go rogue when they see the development time needed to port anything to GTK. And it doesn't have to be like that. It's an architecture design decision they made, where they also chose vala as their own NIH programming language to integrate things over other more established options. Same goes for glibc and gjs which meanwhile has so many bugs I can probably exploit it with a heap spraying exploit from 10 years ago, as it conceptually is yet another hard forked project inside the GNOME ecosystem which can never be updated with its upstream project dependencies/origins. My point is that the GNOME project introduced maintenance burden upon themselves, and that's what's killing the GTK ecosystem. And they themselves could have avoided that. (Apart from the outdated documentation whose example demos don't even compile, whereas the getting started effect with QML is a matter of minutes, not days) I don't wanna derail this discussion too much. It's great that GTK is evolving and adapting. I just wish they would focus on ease of use rather than inventing their own tech stack wherever possible.

phkahler 2y ago

Which things are in libadwaita and not GTK? I thought the article said Dialog boxes, which would be incredibly bad for cross-platform apps if they need to be handled separately on a different OS.

bonzini 2y ago
It's not dialog boxes per se that are in libadwaita, it's things such as where to place buttons and in what order, and also what are the standard labels for the buttons (e.g. should the dialog have Yes/No/Cancel or Don't Save/Cancel/Save buttons? That's the difference between the Windows design language and the Apple design language).
- phkahler 2y ago
  OK, but does that mean I don't get cross platform dialogs with GTK?
  - bonzini 2y ago
    You never did. There was never a widget that knew that "No" was in the middle on Windows and on the far left (but spelled differently) on macOS. I have no idea if/how Qt does it. If you need to ask a question, GTK does provide both GtkMessageDialog (deprecated) and GtkAlertDialog (new). But they will look "off" on some platforms due to not respecting the native design language. If you need a more complex dialog box, you don't need GtkDialog which was just a convenience over other APIs but, with over 25 years of hindsight, wasn't as good as it seemed to be.

jandrese 2y ago

Wait, GtkDialog is considered a GNOME thing and is now depricated? They article claims "These aforementioned widgets only benefited GNOME apps, as they were strictly designed to provide widgets that conformed to the GNOME HIG.", but GtkDialog is the primary way to provide a modal dialog in GTK. That seems like a fairly general problem.

the_biot 2y ago
It's entirely logical for the Gnome folks to do this. They've been removing features and widgets from all kinds of programs for literally decades; Gnome is fundamentally a destructive project. Outright sabotaging GTK (which predates and inspired Gnome) is just the logical way forward on this multi-decade orgy of destruction.
- crashdancer 2y ago
  It's odd you say those things because I've been enjoying GNOME for years and I find they make great additions all the time. For me GTK4 has been a massive improvement over GTK3. There aren't actually any GNOME developers who enjoy removing things just to annoy users -- human beings have limited time and sometimes tough decisions have to be made about what's going to make it in and what isn't.
  - rleigh 2y ago
    Yeah. It really does take more effort to leave perfectly working functionality in place than to do the work to remove it. Come on. Many of the decisions made by the GTK+ developers are utterly unjustifiable. Take the removal of GtkHBox and GtkVBox in place of GtkBox. A couple of shims for backward compatibility would have taken just a few lines of code and would have avoided a hard compatibility break. Did that happen? No. So a huge burden to update every GTK+ application (incompatibly!) was imposed upon every developer on the planet. Was that a productive use of resources? No. It was an utterly illogical change which had zero real-world benefit to anyone. And that's just one of many, many bad decisions. There are very valid complaints to be made about GTK+, and you can't handwave them all away with some PR comments.

fnalelal 2y ago

Good. What Linux needs is libwidgets, i.e. GTK, to have widgets for desktop applications. And, separately, libwankery, where the GNOME geniuses can implement whatever nonsensical "design language" they want for their 0.003% of the market user base.

kelnos 2y ago

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.

HumanOstrich 2y ago
I was with you until you suggested rewriting everything in Rust.
- deleted 2y ago

tristan957 2y ago

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.

Raxelgrande 2y ago

I have been using GNOME as my primary desktop environment since version 38. To be honest, it got bad when Libadwaita/GTK4 released. I did a forum post on the EndeavourOS Linux forum talking about this, back in late 2023 and i reposted it on GNOME's forums, without any success. From what i know they didn't work on the feedback i gave. https://forum.endeavouros.com/t/constructive-gnome-a-bit-of-gtk-criticism/48330 https://forum.endeavouros.com/t/constructive-gnome-a-bit-of-... GNOME on GTK3 was a lot more stable and quite faster, specially for the desktop effects and the design of the overview was a lot easier on mouse users (now you have to scroll all around the screen to just do things). The focus of this is GTK but i want to quickly mention that GNOME is hostile to developers making extensions. Recently they updated something in the Javascript they use for developing extensions, breaking all of them, and providing a porting guide very close to the deadline of the next GNOME release, barely giving developers working on their free time, time to port things, or they would get a storm of users complaining to port the program (don't believe me? browse GNOME's extension store for 5 minutes). The first and most damaging thing i faced as a user was a very nasty bug in GTK4 that made scrolling impossible (the bug is still alive today when using touchpads) https://gitlab.gnome.org/GNOME/gtk/-/issues/2971 https://gitlab.gnome.org/GNOME/gtk/-/issues/2971 . The most crazy thing is that this critical bug for UX was detected in mid 2020, yet 4 years later it's still present on GTK. GNOME decided to break people's computers by shipping this critical bug. To me this is enough reason to not use it as a UI library. Imagine not having working scrolling... Oh wait, it's still going! But the bugs don't stop there! GTK4 has had trouble with drag and drop support, since Nautilus' (the file manager) port to GTK4, it completely broke DnD support of File Roller (the archive manager). Now that File Roller got updated to GTK4 the problem surely got fixed, right? NO! In fact, now File Roller broke DnD for every program! You really have to be bad to ship very broken features to an increasingly bigger user base. Even KDE's recent port to QT6 had less bugs! Another thing that annoys me is the lack of customization. Back in GTK3 days all you needed was a GTK theme, even GNOME's Libhandy could get themed without problems. It got to a point where developers did a nothingburger note on customization https://stopthemingmy.app/ https://stopthemingmy.app/ . That didn't stop anyone. Now you need to know what themes support GTK4 and what theming hack to run on it, and don't get me started on theming Flatpak... GTK4 never got proper support for theming, making the unreliable hacking methods the only way to theme it, without modifying the program's source. Now it ships in production with Ubuntu 24.04 (they did the right call to avoid GTK4 in 22.04 by rolling back some programs). The closest thing to an "official" theming is the Gradience program https://gradienceteam.github.io/ https://gradienceteam.github.io/ It's specially bad and annoying, with barely any good themes that support Libadwaita, it got to the point i developed a small program to simplify theming of Linux, called Iris https://github.com/Raxelgrande/Iris https://github.com/Raxelgrande/Iris . The other and probably most important roadblock for GTK is that it still lacks support for mobile devices, making the big strength of adaptable design it has go to waste. Nobody is going to buy a Linux phone. Overall, GTK and GNOME are very lackluster and im pretty sure that i will avoid that toolkit like the plague. All that Libadwaita does is to lock people into GNOME's design, even if you don't like it. Good luck running programs as good as Bottles and having it look integrated in your desktop. All because they just can't be bothered to at least add a theming API so everyone stops using hacky, problem ridden approaches.

paradox460 2y ago

I will forever find it the pinnacle of missed opportunities that Linux wound up with it's own ux system, rather than using the systems that came out of NeXT via OpenSTEP/GNUstep

linguae 2y ago
I feel the exact same way. I wish FOSS desktop advocates in the 1990s either rallied behind the development of GNUstep, or I wish that during the time when Qt had a non-FOSS license, the Harmony project (https://en.wikipedia.org/wiki/Harmony_(toolkit) https://en.wikipedia.org/wiki/Harmony_(toolkit)) had gotten greater attention as a workaround against Qt's licensing issues. Even standardizing on Win32/Wine might have been a better outcome. Unfortunately we ended up with the Qt/GTK split and everything that resulted from that. Don't get me wrong. KDE, GNOME, and other leading FOSS desktops aren't bad, and it's quite remarkable what they achieved over the past 25+ years. However, I feel we could've ended up with something better, something that would amaze even Mac users. I could imagine a few alternative timelines where the FOSS desktop community rallied behind GNUstep, or perhaps some of the more research-minded people in the community would've gone all the way and came up with some sort of radical GUI inspired by the Smalltalk and Lisp machines of old, as well as some of Apple's 1990s experiments. (Given RMS's affinity for Lisp and his Lisp machine roots, this wouldn't have been too crazy.) I have many thoughts (http://mmcthrow-musings.blogspot.com/2020/04/a-proposal-for-flexible-composable.html http://mmcthrow-musings.blogspot.com/2020/04/a-proposal-for-...) about what my ideal desktop environment would be like, but I haven't had the time to work on them. Maybe if I win the lottery....
- anthk 2y ago
  Gnome 1.4 had Sawfish, a window manager expandable with Lisp.
LeFantome 2y ago
I am with you. The NeXT APIs were so good for the time. The real missed opportunity was that macOS essentially uses those same APIs to this day. We could have had an open source apps platform that was source code compatible with macOS!