How much LibAdwaita has removed

I just installed the Orchis theme and added a blank ".libadwaita" text file into the gtk-4.0 folder, and it was able to style the GNOME Software app in Zorin OS 17. The result is a complete re-theming which looks a lot like the screenshot at the bottom of this page: Third-Party Themes - Zorin Help
I was also able to do this with the old Ubuntu Human Gtk4 theme from here: The old Ubuntu Human theme - Gnome-look.org

That means theme developers could simply add a ".libadwaita" file into their gtk-4.0 folder before packaging their theme and it should style libadwaita apps in Zorin OS. If that small change is implemented by theme developers, end users could just install custom themes like before and they should automatically work in libadwaita apps.

The patch that allows custom libadwaita theming in Zorin OS looks like it's maintained by the Zorin devs and is in their Patches PPA, so it's pinned and shouldn't get overwritten by any other upstream developers in Zorin OS. Because of this, that's something that shouldn't be a problem for Zorin users.
If you look at how many debian packages are made, distro developers (like Ubuntu or Zorin for example) often include & maintain their own patches for upstream system components (not just GNOME), so this isn't anything out of the ordinary.

Gtk4 is a major new version of Gtk, so I don't think it's reasonable to expect that all elements are entirely the same with the same names and APIs. However, they didn't entirely remove them all without providing replacements.

For example, you mentioned that GtkMenuBar and GtkToolbar were removed. However, Gtk4 still provides menu bar and toolbar widgets, which you can see in my annotated screenshot of AWF:

I also know that the newer versions of Transmission (the torrent client) are made with Gtk4 and still use a menu bar and toolbar, so these widgets definitely haven't been removed.

That's an example of what I mean. You'll probably need to re-write a Gtk3 theme to make it work in Gtk4 (just like you had to when going from Gtk2 > Gtk3, but less drastic). On the other hand, you should still be able to achieve the same level of customization in how you style its elements in CSS. Just not with the exact same code copied and pasted.

In Zorin OS. It usually will work. Not gtk-wide. In Zorin OS, only Zorin OS, only in 17 and in future, only in 18.
For a distributing styler, this is not acceptable.
What worked - no longer works.

Let me be very blunt. I have been working with this for years.

You only learned about AWF from a quick google, then jumped on the forum in order to say "it looks alright to me."
You do not know the code. You do not know the details; you do not know about the documentation or the removals.

This statement is false.

If Gnome releases an update that overrides what the ZorinGroup has done with LibAdapta, then ZorinGroup must re-write their patch. The ZorinGroups patch will not override the Gnome update.
That is not how this works, at all.

First you said there were no removals based on your glance at AWF.

Now, you backtrack admitting that there are removals, but suggest that e should accept that as normal.

They 100% definitely have been removed.
Please. Read. The. Documentation:

What you see in that screenshot is gtkBox., Not menubar, not toolbar.
It is also gtk-popovermenu assigned under the class gtkheaderbar.

So these can look like or mimic toolbar or menubar to some extent, but they are not the same widgets and have reduced functionality.

While this looks purely cosmetic, it is not. The removal is a hard break in the toolkit’s API.

This is significant because while it works well on Gnome, it stays exclusive to Gnome. GTK as a toolkit is relied upon by other Desktop Environments and by restricting these API's into one class witha generic box, they break their functionality entirely on other desktops, making Gnome Dominant.

Sure, you can load a flat generic theme that has been modified anbd adapted to fit GTK4 and LibAdwaita and claim that all is well. But you cannot do it with desktops that restore the functionality of the tools and menus that Gnome does not use.

2 Likes

Gnome has shifted to: Soft Restrictions Without Leaving the GPL: “FOSS by Design but Upstream-Controlled”

Gnome has not technically violated the GPL nor abandoned it. On technical grounds, they can (and do) claim that it is FOSS.

However, through deliberate design choices, it has created an ecosystem in which forking and maintaining packages outside upstream control is effectively impossible.

Tools like GTK Inspector allow examination of widget trees and nodes in GTK applications. LibAdwaita nodes are intentionally hidden upstream. Gnome developers have structured these components so they cannot be inspected or manipulated, creating an invisible layer in the UI that is dependent on upstream code.
Accessibility and User Freedom define the necessity to do so. Modern Gnome applications governed by Gnomes HIG break accessibility needs.
LibAdwaita overrides replace existing accessibility functionality with Gnome-specific abstractions. These are hidden from inspection tools and difficult to modify, further limiting user control and independent adaptation.

This is design-by-omission; where Gnome applications omit functions in order for those to be provided by LibAdwaita. LibAdwaita does not provide the accessibility means, in deference to Gnomes HIG.
With this coupled with LibAdwaita dependency, a fork cannot maintain against upstream breakage for Gnome and for GTK Applications. This is exactly how Microsoft operates and how FOSS dies. Non-Gnome applications that use GTK are beholden to Gnome Control.

Even if developers attempt to patch or bypass LibAdwaita, upstream Gnome updates can easily break these efforts. This creates a dynamic where contributions outside the Gnome stack are routinely nullified and fully still under Gnome Control. That is ecosystem lock-in.
And non-Gnome GTK built applications are dragged along with it.

Anything using GTK must assume the upstream stack. This reinforces a single development path, effectively binding the ecosystem to Gnome’s control. This is why all GTK utilizing desktop environments, like XFCE, are forced into submission. Not because they agree that Gnomes HIG and LibAdwaita is a better path. But because it is not possible to take a better path.

It is Free Open Source on paper only. Hidden internals. Breakage of accessibility. To me; it seems that any developers that enable this are party to the "Microsofting" of GnuLinux.
Why should users Migrate to GnuLinux only to end up back under the thumb of a controlling entity again? Zorin OS is founded on helping users migrate away from Microsoft... I guess a freshly migrated Windows User is used to feeling controlled. Told they cannot. Told they are not allowed to modify.

That it is so obvious... So Clear and easy to see... Yet, we sit back idly watching freedom be taken away - it utterly blows my mind.

1 Like