search

flathub-infra / flatpak-builder-lint

A linter for flatpak-builder manifests
MIT License
48 stars 125 forks source link

Add exception for dev.edfloreshz.Tasks #430

Closed edfloreshz closed 1 month ago

edfloreshz commented 1 month ago

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?

bbhtt commented 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?

bbhtt commented 1 month ago

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?

mmstick commented 1 month ago

The configs used by libcosmic applications are currently stored in

bbhtt commented 1 month ago

And why does it not use portals?

barthalion commented 1 month ago

This is going to stay on the back burner until we introduce more granular xdg-* exceptions.

mmstick commented 1 month ago

For the same reason GTK does not use them.

Portals don't provide access to theme and GUI toolkit configuration files.

bbhtt commented 1 month ago

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.

mmstick commented 1 month ago

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.

bbhtt commented 1 month ago

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.

bbhtt commented 1 month ago

@edfloreshz can you please rebase on master and squash the commit? Can't merge without the rebase.

edfloreshz commented 1 month ago

Sure, just give me a moment to get to my computer, I'm on my phone atm.

edfloreshz commented 1 month ago

That should do it @bbhtt

bbhtt commented 1 month ago

Didn't work. I'll do it.

edfloreshz commented 1 month ago

Sorry, missing coma, done

bbhtt commented 1 month ago

Nope you created a merge commit instead of rebasing.

image

edfloreshz commented 1 month ago

Rebase completed 👍🏼

TingPing commented 1 month ago

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.