There was a recent discussion about the matcha theme on QT apps on XFCE, which inspires me to ask, have you fixed the GTK4 dark theming, now that pamac has a gtk4 version since months?
Maybe make a new adv-gtk4 package or similar that is fixed and it dependency of pamac, exactly as adv-gtk3 now works? Should be 1 css file somewhere in the root after all.
That is what i mean
Apparently it’s still broken… 
Yes i tested, renamed the .config and pamac became white again.
Most Xfce users resolved theme issue by replacing pamac-gtk with pamac-gtk3
Maybe make a new adv-gtk4 package or similar that is fixed and it dependency of pamac, exactly as adv-gtk3 now works? Should be 1 css file somewhere in the root after all.
Package adw-gtk-theme in extra repository depends on adw-gtk3 and libadwaita for Gtk3 & Gtk4 theme
pamac list -f adw-gtk3 | grep 4.0
/usr/share/themes/adw-gtk3-dark/gtk-4.0/gtk-dark.css
/usr/share/themes/adw-gtk3-dark/gtk-4.0/gtk.css
/usr/share/themes/adw-gtk3/gtk-4.0/gtk-dark.css
/usr/share/themes/adw-gtk3/gtk-4.0/gtk.css
Yes, it is supposed to do both, but as we all know the gtk4 part from it is broken. At least the dark theme.
Hi, @Teo
About pamac GTK 4, have you tried adding GTK_THEME=what ever dark theme you use in /etc/environment file ??
Yesterday I believe, I had an update on my new laptop where I use Arco linux and they pushed pamac gtk 4 and all I had to do is the above and reboot to have pamac with dark theme.
Can you give it a try and post if it works for XFCE ?
Cheers…
I guess that also works, i have not set the global env, but just tried
GTK_THEME=Adwaita:dark baobab
in terminal and it works.
Still, no such manual interventions should be needed for something that is part of the default installation like pamac(gtk4)
Reading here
https://wiki.archlinux.org/title/GTK
Note: For libadwaita-based GTK 4 applications, the chosen GTK theme needs special support and you are required to force a GTK theme with the
GTK_THEMEenvironment variable, or use a patched version of libadwaita: libadwaita-without-adwaita-gitAUR.
seems like there if fixed package that did not find its way to manjaro, yet.
No, it’s not. The adw-gtk-theme package is a script that uses the adw-gtk3 theme to apply the Libadwaita style to Gtk 3 applications. Technically it’s not necessary anymore as the adw-gtk3 developer now includes upstream Libadwaita changes in the theme. However, it’s still useful when we have a libawaita update before upstream has a chance to adapt to anything that may have changed.
That is an unsupported debugging option, that should never be used as a environment variable.
Ideally and in principle, I agree from a UI / UX perspective. Shipping such regressions into production / stable isn’t a great look from a user-centric point of view. With Arch-based distros being rolling-release, and Manjaro with its’ staged rollout from unstable → testing → stable branches would, in an ideal world, have lots of QA testing & iterative development feedback loop cycles between the staged promotion of packages. However, that would require enough people with systems on unstable and testing branches who also have the technical competence and enough proficiency to find & access the appropriate upstream & packaging repos to catch bugs and problems before they flow into stable.
I’m sure we’re all aware that, unfortunately, we don’t live in an ideal world. There are probably many barriers to entry for people to meet those criteria and to reach that level in the community, and the number of new users likely will always outnumber the highly skilled & proficient developers and package maintainers.
As such, the best we can do is try to set expectations with users appropriately. Developer & maintainer time is probably not going to be enough to do proper QA testing for everything. So, disclaimers are given about Manjaro being a community of volunteers. Warnings about using the AUR are given on the Manjaro side of things, etc…
A slight bit off-topic, but it may help understand the situation for developers & maintainers a bit to look at the following quick “case study” comparison:
Let’s look at Debian → Ubuntu for example. It’s a similar inter-distro relationship, but rather than rolling-release, they both have regular release cycles with an end product that has an officially named release. Canonical is able to provide resources to fund development, but the packaging flow is much slower than any rolling-release distro. This buys them a lot more time to address critical bugs & regressions before they reach an LTS release. Additionally, for community member volunteers there are a few major barriers to entry, outlined below.
Barriers to entry:
debian/rules file, the debian/control, debian/watch, debian/patches/* files, and others)quilt, debuild, dpkg, apt, apt-get, dch, gbp, pbuilder-dist, lintian, gpg, etc…)
those meetings happened over IRC, but given the 2020-2021 Freenode mass-exodus, it’s unclear where meetings are held now (wiki pages outdated)Meanwhile comparing this to ArchLinux → Manjaro:
PKGBUILD file & syntax, which is mostly a shell-script anyway.make, cmake, meson), and how to use makepkg + gpg (optionally for signing)repo-add away from easy local package testing.So for Arch-based distros, the barriers to entry are lower. However, that means more people of all skillsets & skill-levels are able to volunteer and impact the state of packages on the AUR. This means that things will be in a possibly more chaotic state given the nature of the AUR vs. official repos. (Not saying this applies to this particular gtk4 + pamac issue… but just in general painting a full picture) The official packages (e.g. pamac) are still maintained by those working officially for ArchLinux & Manjaro. This is somewhat similar to the official packaging channels for Ubuntu being maintained by Canonical, versus the multiverse / universe repos maintained by MOTU community members.
Number of employees:
Number of users (approximated based on survey data extrapolation with 32.8 million Linux users):
Staff to User ratios (approximate staff : 1 user):
0.000004287:1
0.000007031:10.00014:1
0.00017:1Disclaimer: I’m not sure how accurate these LinkedIn employee counts are, and not sure how to gauge the approximate community sizes given the distributed & decentralized nature of *nix distros.
For all distros, the upstream development and upgrade of dependencies (e.g. gtk3 → gtk4) can produce instability when changes are made to the dependency tree, which can sometimes get quite complex and produce unintended results when components are built and put together. The combinations and permunations of packaging dependencies + their versions can make for an astronomical number of things to test. Think of a QA testing / traceability matrix table which blows up in multiple dimensions to some kind of hyper-dimensional matrix in non-euclidean n-dimensional space (a hyper-hyper-cube? 
). The problem-space grows exponentially when dependency & versioning complexity increases. For an entire Linux distro, it gets to astronomical levels of complexity. The time required to test all possible combinatorial configurations will always exceed the time and number of developers available to find & fix bugs.
Yet again, there is a similarity between the smaller number of people working at Debian & Canonical to maintain the official packages for Debian + Ubuntu, similarly to how the ArchLinux & Manjaro support staff is likely outnumbered by AUR maintainers & users combined.
Meanwhile, the timing and flow of Debian stable → Ubuntu’s interrim + LTS release cycle is a bit slower overall than ArchLinux → Manjaro’s rolling-release + staged branch cycle. Again, the longer and slower rollout of packages on the Debian-based distros results in buying more time to get bugs fixed before they end up in an LTS release. However, even with that slower cycle things still find their way into an LTS release. With ArchLinux & Manjaro, the picture is similar, yet with less time to prevent bugs & issues from rolling out. This results in a slightly less stable upgrade process in the short term… but with periods of relative stability once bugs and issues are found & the bugfixes roll out the next cycle.
EDIT: Added approximate staff to user counts for case-study distros
EDIT++: Fixed staff: 1 user ratio results, and clarified how approximate users were calculated (using 32.8 million Linux users total).
While i agree with the metaphore “a garage startup vs. a big corporation”, the only way for a garage startup to grow and become the next big corporation is to provide more features and better quality in the long run. The alpha-kickstarter-early-adopters that gladly put up with bugs and peculiarities of the product of the garage startup are a limited number.
Always saying “if you don’t like it the way it is, then you are not worthy enough to use it” was never a winning strategy for anything in the long term. And what do you think a brand new user coming from windows deciding to try linux for the first time thinks, after he sees the build in add/remove programs does not work at all or does not look at all like the rest of the system.
manjaro grew in popularity unproportional to the available (human and financial) resources, as you quoted the numbers. In the long run, it will either find some way to monetize better and hire more developers, or start to decline at some point. We have seen it before.
Pamac GTK4 is designed to only work on GNOME desktop, users of other desktops should keep using Pamac GTK3 or look for another alternative or simply use pacman.
According to whom? It certainly was pushed as an automatic update on my XFCE.
Yeah, that’s a fair observation that it’s not usually a winning strategy. Note that in the above post, I was merely trying to draw attention to the big picture and to hopefully set expectations. The quote:
“if you don’t like it the way it is, then you are not worthy enough to use it”
… is not what I was saying. 
Anyone is free and worthy to use whatever they choose. 
… yeah… as I was saying, “it’s not a good look” when UI/UX issues like that make their way into “stable” branch. Neither from user’s perspective, nor developer & maintainer’s perspective. The best we can all do is try to be aware of the big picture of how things ended up this way, and to set & manage expectations while trying to avoid bugs & regressions in the future.
EDIT: For this particular case of pamac-gtk3 vs pacmac (GTK4)… as others have noted it’s all due to decisions made by upstream GNOME + GTK4 developers that lead to the libadwaita theming behavior. While you and I may disagree with upstream on the inflexibility aspect of libadwaita, there are both pros and cons of having a standardized look & feel. For GNOME, it’s meant to force the GNOME desktop apps to look & feel the same. For other non-GNOME but GTK-compatible desktops, it gives us yet another set of apps that bring opinionated theming with them when we choose to use them, whether we like it or not. The beauty of Linux is the freedom of choice and hackability of everything… I’m sure it won’t be too long before someone with time is motivated and finds a way to shoehorn themeing support into some libadwaita-like shim library or some other means.
Manjaro cannot prevent all issues getting to stable branch
Sometimes the best that can be done is to have information posted in Known issue and solutions section of update announcements so users can resolve problems when they occur
Gtk4 support for pamac GUI was first announced in unstable branch 21 Jun 2023
Known Issue and solution was first posted in [Testing Update] 2023-06-24
pamac-gtk11.0.1 uses Gtk 4 that is not supported by Xfce
user can replace pamac-gtk with pamac-gtk3pamac install pamac-gtk3
Solution was reposted to [Stable Update] 2023-07-10
as others have noted it’s all due to decisions made by upstream GNOME + GTK4 developers that lead to the
libadwaitatheming behavior.
Pure GTK4 apps are correctly themed under non GNOME desktops, only apps created by using that cursed LibAdwaita library suffer from that inconsistent look.
The real problem is the choice made by Pamac devs to use it instead of using pure GTK4 widgets, while knowing that Manjaro officially supports other desktops like Plasma and XFCE.
So, it turns out that it’s actually simple to get a theme to override libadwaita. There are 2 methods:
~/.config/gtk-4.0/
This can be done manually:
theme=Matcha-dark-sea ; for f in "gtk-4.0/gtk.css" "gtk-4.0/gtk-dark.css" "gtk-4.0/assets" "assets" ; do [ -e "/usr/share/themes/$theme/$f" ] && ln -s "/usr/share/themes/$theme/$f" ~/.config/gtk-4.0/"$f"; done;
Or, with this helper python script: libadwaita-theme-changer
python3odziom91/libadwaita-theme-changer/usr/share/themes & /usr/local/share/themeslibadwaita-without-adwaita-git package
libadwaita with this patchNote: Neither of these methods are officially supported, given the current stance of GNOME and rationale behind libadwaita. Yet, as always, the *nix community will find a way to customize. Such is the way of OSS.
We know the workarounds. But it will be nice to work out of the box, you know. You download the iso from the manjaro site, install, and it just works good and looks good. The user should not be forced to start tinkering with a brand new installation because something does not quite work. The whole and the only point of this distro is to be “curated/more stable” and “easier/user friendlier” than arch.