FlatPak PrusaSlicer doesn't get styled

[dzervas]

I'm not sure if this is a problem with flatpak or PrusaSlicer specifically but it doesn't get styled:

(My theme is snazzy, a dark one)

I'm using sway with GTK enabled (Qt theming is broken)

[danth]

Is this a GTK application? If not, we will need to write a specific module to theme it. If it is, it may be overriding the system theme with its own theme. Also, as far as I know, Flatpak isolates apps from the rest of the system, which may prevent it from accessing config provided by Stylix.

[dzervas]

PrusaSlicer uses GTK but my question was more towards flatpak in general - is there the ability to "export" the gtk and qt themes to flatpak?

[danth]

I'm not familiar with the details of Flatpak, but if you can somehow make ~/.config/gtk-3.0 and ~/.config/gtk-4.0 visible to the app then it should pick up the theme.

[sonjiku]

I'm not familiar with the details of Flatpak, but if you can somehow make ~/.config/gtk-3.0 and ~/.config/gtk-4.0 visible to the app then it should pick up the theme.

I don't think it's possible for these files to be read by most flatpak apps. Could there possibly be a way to create a new theme instead of creating an "override" (if that's the correct term) through these files?

[sonjiku]

Perhaps patching the theme with an overlay for the adw-gtk3 package that replaces the relevant strings in the theme's gtk.css? I think it might be ugly codewise, depending on how it is implemented, but I believe it will be a better solution.

Btw, through this solution, the "issue" about not being able to switch "polarity" without rebuilding could be "fixed".

[brckd]

I just implemented your suggested solution and can confirm that it works! No other solution I've tried worked and it seems that Flatpak apps aren't reading ~/.config/gtk-3.0 or ~/.config/gtk-4.0 even though they were granted direct access.

https://github.com/brckd/nixdots/blob/1035c47d29851941ef56a7ccc9e9645817831b59/modules/home/stylix/targets/flatpak/default.nix

Here are some Flatpak apps with a Catppuccin GTK theme

Here's also that app you were referencing with a Catppuccin GTK theme ':D

My current implementation isn't perfect though. It only applies GTK themes and it depends on nix-flatpak for the filesystem config. I also didn't test it with other themes but I assume they should behave the same.

[trueNAHO]

I just implemented your suggested solution and can confirm that it works! No other solution I've tried worked and it seems that Flatpak apps aren't reading ~/.config/gtk-3.0 or ~/.config/gtk-4.0 even though they were granted direct access.

https://github.com/brckd/nixdots/blob/1035c47d29851941ef56a7ccc9e9645817831b59/modules/home/stylix/targets/flatpak/default.nix

[...]

My current implementation isn't perfect though. It only applies GTK themes and it depends on nix-flatpak for the filesystem config. I also didn't test it with other themes but I assume they should behave the same.

Thanks for sharing your flatpak support PoC!

Do you mind clarifying the following concerns to potentially patch flatpak support into Stylix:

• Do you think it is possible for us to transparently support flatpak applications?

• Is an additional dependency, like nix-flatpak, really required?

• Would nix-flatpak cause nasty downstream edge cases:

  Infinite recursion in home-manager imports

  Users have reported an infinite recursion stacktrace when importing an home-manager module outside of where home-manager itself was imported.

  To work around this issue, you should avoid nesting home-manager modules. This means that when you are structuring your configuration, make sure that you do not have home-manager modules imported within each other in a way that could lead to circular imports.

  You can follow the discussions and updates on issue #25 to stay informed about any resolutions or workarounds.

  -- nix-flatpak, README.md

[brckd]

Thanks for sharing your flatpak support PoC!

Do you mind clarifying the following concerns to potentially patch flatpak support into Stylix:

• Do you think it is possible for us to transparently support flatpak applications?

I'm not sure what you mean by transparency here. Flatpak is often an important secondary source for smaller apps, especially GTK ones, that haven't made it to nixpkgs yet. While Flatpak apps themselves cannot be installed declaratively without using third party solutions like nix-flatpak, their options can be configured declaratively without that and should therefore be in scope for stylix.

• Is an additional dependency, like nix-flatpak, really required?

As hinted above, it's not. Instead of writing to its services.flatpak.overrides.global option, we can directly write the configuration as TOML to xdg.dataFile."flatpak/overrides/global" for HM or /var/lib/flatpak/overrides/global for NixOS. But this might conflict with nix-flatpak when attempting to write options there as well. Using the Flatpak CLI like flatpak override --filesystem $HOME/.themes/$GTK_THEME for this might also be an option then.

• Would nix-flatpak cause nasty downstream edge cases:

  Infinite recursion in home-manager imports

  Users have reported an infinite recursion stacktrace when importing an home-manager module outside of where home-manager itself was imported. To work around this issue, you should avoid nesting home-manager modules. This means that when you are structuring your configuration, make sure that you do not have home-manager modules imported within each other in a way that could lead to circular imports. You can follow the discussions and updates on issue #25 to stay informed about any resolutions or workarounds. -- nix-flatpak, README.md

You're right, as far as I understood it might cause such problems because both stylix and nix-flatpak import home-manager, so this would result in a nested HM dependency. Whether it actually poses any problems will only show once someone implements the module in stylix though.

[brckd]

Tell me if this is a desirable feature and I will open a PR in no time!

[trueNAHO]

While Flatpak apps themselves cannot be installed declaratively without using third party solutions like nix-flatpak, their options can be configured declaratively without that and should therefore be in scope for stylix.

Agreed.

• Is an additional dependency, like nix-flatpak, really required?

As hinted above, it's not. Instead of writing to its services.flatpak.overrides.global option, we can directly write the configuration as TOML to xdg.dataFile."flatpak/overrides/global" for HM or /var/lib/flatpak/overrides/global for NixOS. But this might conflict with nix-flatpak when attempting to write options there as well. Using the Flatpak CLI like flatpak override --filesystem $HOME/.themes/$GTK_THEME for this might also be an option then.

Would it be possible to conveniently avoid conflicts with nix-flatpak by disabling its user declarations, if available, and integrating them into our Stylix logic?

• Would nix-flatpak cause nasty downstream edge cases:

[...]

Whether it actually poses any problems will only show once someone implements the module in stylix though.

Agreed.

Tell me if this is a desirable feature and I will open a PR in no time!

I am not a flatpak user, but I can imagine this being a neat addition to Stylix. Feel free to work on this.

[brckd]

Would it be possible to conveniently avoid conflicts with nix-flatpak by disabling its user declarations, if available, and integrating them into our Stylix logic?

The Flatpak overrides file allows to configure more options than just styling. I therefore think that integrating it into Stylix is out of scope. I'll first try to use the nix-flatpak module to avoid possible conflicts with it. I will then observe whether this creates issues like the recursion one or creates a considerable overhead for the Stylix flake. If it does, I will instead try ask the nix-flake maintainers to add their option to home-manager directly.

I'll now try to implement a prototype in a new PR. See you there!