Closed edfloreshz closed 1 month ago
Really? there's no portal for this? This is supposed to be handled by the xdg-portal-cosmic with the settings portal.
It seems to support appearance and accent colours https://github.com/pop-os/xdg-desktop-portal-cosmic/commit/de59bb3151a0bbc87f5352f42e6420413eede4c5 so what "system theme" are you talking about?
Also please point to an issue/existing discussion upstream about this. If not please open one.
Where do they advertise the current theme? Only in ~/.config/cosmic
?
The configs used by libcosmic applications are currently stored in
~/.config/cosmic/com.system76.CosmicTheme.Mode/
~/.config/cosmic/com.system76.CosmicTheme.Dark/
~/.config/cosmic/com.system76.CosmicTheme.Light/
~/.config/cosmic/com.system76.CosmicTk/
And why does it not use portals?
This is going to stay on the back burner until we introduce more granular xdg-* exceptions.
For the same reason GTK does not use them.
~/.themes
~/.config/gtk-3.0
~/.config/gtk-4.0
Portals don't provide access to theme and GUI toolkit configuration files.
The theme from host is communicated via the settings portal backend on wayland and xsettings daemon on X11.
Exposing config directories from host is never needed.
There are two parts of exposing themes here.
First the theme needs to be packaged via Flatpak extensions with a proper extension point in the runtimes. So that Flatpak can automatically detect and install it during flatpak install or update. For Gtk theme Flatpak does this by checking the gtk-theme
dconf key.
The other part is that the portal exposes the selected theme from host to the sandbox. The toolkit/application in most cases automatically loads that theme by reading the value from the settings portal provided the theme has been installed by Flatpak.
If both of these conditions are satisfied everything works automatically for Flatpak applications.
cc @TingPing in case I missed anything. The docs are light but trying to fix them.
If any part is lacking it's fine to allow temporary exceptions to this but this should be fixed upstream so that no sandbox holes are needed.
That only conveys the theme name, which requires installing a flatpak containing the configuration files. COSMIC theming does not work the same way. There are no predefined themes. Themes are configured dynamically by the user in COSMIC Settings, which saves the configurations in the appropriate cosmic-config config files. The cosmic-settings-daemon then issues a signal over dbus to notify libcosmic applications that the watched configs have changed, which is then read by the application.
This should be made sandbox friendly. It is unfortunate if every cosmic application have to open sandbox holes to read theme files from host.
Nowadays static permissions for themes isn't required unless it is using some legacy API or is on a platform that lacks proper portal support or Xsettings support. For example SteamOS lacks them.
@edfloreshz can you please rebase on master and squash the commit? Can't merge without the rebase.
Sure, just give me a moment to get to my computer, I'm on my phone atm.
That should do it @bbhtt
Didn't work. I'll do it.
Sorry, missing coma, done
Nope you created a merge commit instead of rebasing.
Rebase completed 👍🏼
Themes are configured dynamically by the user in COSMIC Settings, which saves the configurations in the appropriate cosmic-config config files. The cosmic-settings-daemon then issues a signal over dbus to notify libcosmic applications that the watched configs have changed, which is then read by the application.
The settings portal is entirely controlled by the implementer of it, so xdg-desktop-portal-cosmic
can simply expose any data it wants and notify when it changes. Settings are namespaced so you can use it as you wish and multiple settings backends can be combined.
COSMIC applications require read-only access to the host in order to watch for changes in the system theme and sync with it.
Can we add an exception?