Submission checklist
Feature type
Integration support
Feature summary
Noctalia's built-in gtk3/gtk4 templates only write to $XDG_CONFIG_HOME/gtk-3.0/... and gtk-4.0/.... A Flatpak-installed GTK app's sandbox has its own isolated $XDG_CONFIG_HOME and never sees that path, so the app stays unthemed even though the template renders correctly. Noctalia already knows the resolved palette and already writes the GTK CSS at theme-apply time. It could also detect which GTK-relevant Flatpak apps are installed and write the same rendered content directly into each one's own ~/.var/app/<app-id>/config/gtk-3.0/ and gtk-4.0/, no flatpak override required.
Motivation / use case
Confirmed directly on a real machine: writing the rendered GTK CSS straight into a Flatpak app's own ~/.var/app/<id>/config/gtk-3.0/gtk.css (the app's real, writable, non-sandboxed-from-the-host-side directory) reliably themes it, verified on two apps with dedicated custom-theme hooks (zathura, heroiclauncher, see community-templates PR #55 and #56). The same direct-write approach was also tried against a GTK4/libadwaita app (Lutris, org.gnome.Platform/49 runtime) and did not work, not even with a maximally blunt !important test rule, confirming that GTK4 apps under Flatpak don't reliably auto-load user CSS at all in this context (this matches a long-standing, closed-NOT_PLANNED Flatpak issue, flatpak/flatpak#3901, with five years of inconsistent reports even using the "standard" override-based fix). So this feature would genuinely help GTK3 Flatpak apps, and is not a promised fix for GTK4/libadwaita ones. Worth building for the apps it actually helps rather than skipped because it does not solve every case.
Right now, a user enabling the gtk3/gtk4 built-in templates has no way to know their Flatpak-installed GTK3 apps are silently not receiving the theme, and no documented path to fix it without hand-editing per-app config themselves.
Proposed solution
At theme-apply time, alongside the existing $XDG_CONFIG_HOME/gtk-3.0 and gtk-4.0 writes, enumerate installed Flatpak apps (Noctalia already does Flatpak detection elsewhere) and write the same rendered gtk.css/noctalia.css pair into each one's ~/.var/app/<app-id>/config/gtk-3.0/ and gtk-4.0/, skipping any app whose directory does not exist yet. Same idea as the existing vencord-flatpak precedent in TemplateRegistry.qml (noctalia/noctalia#2020), generalized across every installed Flatpak app instead of one hardcoded app id, since GTK theming is not tied to a single known app.
Alternatives considered
Per-app flatpak override --filesystem=xdg-config/gtk-3.0 is the community's usual manual workaround, but it requires the user to know it exists, run it per app, and (per the upstream thread) also requires the GTK config files to be real files rather than symlinks, which conflicts with how most dotfiles-managed setups deploy them. Writing directly into each app's own sandbox directory sidesteps both problems and needs no manual step from the user at all.
References / related projects
#2020
flatpak/flatpak#3901
noctalia-dev/community-templates#55
noctalia-dev/community-templates#56
Additional context
Checked for an existing issue covering this before writing it up; found #3257/#2516 (Flatpak/snap/appimage source differentiation, a different concern about detecting how an app was installed for other purposes) but nothing about propagating GTK theme output into Flatpak sandboxes specifically.
Submission checklist
Feature type
Integration support
Feature summary
Noctalia's built-in
gtk3/gtk4templates only write to$XDG_CONFIG_HOME/gtk-3.0/...andgtk-4.0/.... A Flatpak-installed GTK app's sandbox has its own isolated$XDG_CONFIG_HOMEand never sees that path, so the app stays unthemed even though the template renders correctly. Noctalia already knows the resolved palette and already writes the GTK CSS at theme-apply time. It could also detect which GTK-relevant Flatpak apps are installed and write the same rendered content directly into each one's own~/.var/app/<app-id>/config/gtk-3.0/andgtk-4.0/, noflatpak overriderequired.Motivation / use case
Confirmed directly on a real machine: writing the rendered GTK CSS straight into a Flatpak app's own
~/.var/app/<id>/config/gtk-3.0/gtk.css(the app's real, writable, non-sandboxed-from-the-host-side directory) reliably themes it, verified on two apps with dedicated custom-theme hooks (zathura,heroiclauncher, see community-templates PR #55 and #56). The same direct-write approach was also tried against a GTK4/libadwaita app (Lutris,org.gnome.Platform/49runtime) and did not work, not even with a maximally blunt!importanttest rule, confirming that GTK4 apps under Flatpak don't reliably auto-load user CSS at all in this context (this matches a long-standing, closed-NOT_PLANNEDFlatpak issue, flatpak/flatpak#3901, with five years of inconsistent reports even using the "standard" override-based fix). So this feature would genuinely help GTK3 Flatpak apps, and is not a promised fix for GTK4/libadwaita ones. Worth building for the apps it actually helps rather than skipped because it does not solve every case.Right now, a user enabling the
gtk3/gtk4built-in templates has no way to know their Flatpak-installed GTK3 apps are silently not receiving the theme, and no documented path to fix it without hand-editing per-app config themselves.Proposed solution
At theme-apply time, alongside the existing
$XDG_CONFIG_HOME/gtk-3.0andgtk-4.0writes, enumerate installed Flatpak apps (Noctalia already does Flatpak detection elsewhere) and write the same renderedgtk.css/noctalia.csspair into each one's~/.var/app/<app-id>/config/gtk-3.0/andgtk-4.0/, skipping any app whose directory does not exist yet. Same idea as the existingvencord-flatpakprecedent inTemplateRegistry.qml(noctalia/noctalia#2020), generalized across every installed Flatpak app instead of one hardcoded app id, since GTK theming is not tied to a single known app.Alternatives considered
Per-app
flatpak override --filesystem=xdg-config/gtk-3.0is the community's usual manual workaround, but it requires the user to know it exists, run it per app, and (per the upstream thread) also requires the GTK config files to be real files rather than symlinks, which conflicts with how most dotfiles-managed setups deploy them. Writing directly into each app's own sandbox directory sidesteps both problems and needs no manual step from the user at all.References / related projects
#2020
flatpak/flatpak#3901
noctalia-dev/community-templates#55
noctalia-dev/community-templates#56
Additional context
Checked for an existing issue covering this before writing it up; found #3257/#2516 (Flatpak/snap/appimage source differentiation, a different concern about detecting how an app was installed for other purposes) but nothing about propagating GTK theme output into Flatpak sandboxes specifically.