Interesting article but I want to clear up some very questionable statements that I see here.<p>>Linux users have long enjoyed the degree to which they are able to personalize their desktop apps and environments through theming [...] Reasonable expectations like these are being completely turned on their head by GNOME.<p>This is not new, GNOME 3 has never really supported themes. What these other desktops was doing was always unsupported, I'm confused as to how they could be developing a desktop based on GNOME and not deeply understand this.<p>>If you want to support and adopt the GNOME HIG via libadwaita but still offer third-parties the flexibility to make the app integrate well in their ecosystem, you cannot<p>>Through their enforcement of the Adwaita theme in their “platform library” libadwaita [...] they are eliminating both developer and user choice in the process<p>>If you are building a desktop Linux application at this point and you want to provide flexibility for your users or allow operating systems to ship your app, with users being happy with how well it integrates with the rest of their Linux experience, using GTK4 and beyond is going to be shooting yourself in the foot.<p>>Instead of debating more on technical merits, these developers are instead trying to devalue and discredit the contributions<p>These statements are all false. There are still plenty of ways for third parties to integrate apps, the only things you cannot do anymore with libadwaita are inject arbitrary CSS with environment variables or XSettings. The patch was rejected on technical grounds based on comments from other app maintainers that were not going to use the API, the comments on the developer's conduct were separate. I don't really want to comment any more on the rest of the article's related statements on the Twitter conversation as they all seem to be rooted in this initial misconception.<p>>some GNOME developers dismissing concerns by just claiming that nobody from System76 ever engaged with GNOME on the matter, which is materially false<p>This statement is false and based on a misinterpretation of an older conversation. The conversation from 2019 was related but was not about this specific issue. Some of the changes from that 2019 conversation are actually making it in to Adwaita. Other changes were not implemented and are looking for an implementer, which the Solus developers could have stepped up to do in 2019, but it seems they declined to.<p>>Instead, you need your own class that sub-classes GObject + GObjectClass, hold a pointer to a GtkHeaderBar or GtkListBox, and make changes to the widgets referenced by the pointer [which is] unnecessarily cumbersome<p>This is false, it's necessary as subclassing those widgets can break the CSS classes.<p>>Instead of having simple GTK functions to set the positioning, now everyone has to write their own APIs that interface directly with X11 APIs (risky if the developer is not familiar with them)<p>This statement as well as the entire section on X11 APIs is very baffling. If the developer is not familiar with various X11 APIs and quirks, they will have a hard time developing a desktop for X11 at all. And X11 as a whole is basically deprecated, new desktops should not be using that, the current focus is on Wayland.<p>After reading such a low quality blog post from the lead developer that has apparently led to major decisions, I currently would not suggest use of Solus or Budgie to anyone. But I wish them luck with their EFL migration in any case. EFL has pretty mature Wayland support by the way.