Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

nixos/xdg: disable portals (again, again) #65449

Merged
merged 5 commits into from Jul 30, 2019
Merged

nixos/xdg: disable portals (again, again) #65449

merged 5 commits into from Jul 30, 2019

Conversation

worldofpeace
Copy link
Contributor

Motivation for this change

See the commits and hopefully you'll get the gist of the story 馃ぃ

I'm not sure if the assertion in flatpak is the best way to go, but I'd like
these things to play nice together, and most certainly not default enable GTK_USE_PORTAL
because that will affect non-flatpak applications.

Additionally, having an option like gtkUsePortal which just sets

environment.variables.GTK_USE_PORTAL = "1";

is slightly overkill in my opinion. A usecase that would better belong in the NixOS wiki.

However, many other distros are getting support requests to have this for the native filechoosers, so this would be an easy way to have an opt-in within NixOS.

(taking advantage of the interface we are able to provide).
Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Determined the impact on package closure size (by running nix path-info -S before and after)
  • Ensured that relevant documentation is up to date
  • Fits CONTRIBUTING.md.

samueldr
samueldr reviewed Jul 27, 2019
View reviewed changes
Copy link
Member

@samueldr samueldr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor change for the assert, otherwise looks good.

nixos/modules/config/xdg/portal.nix Outdated Show resolved Hide resolved
@worldofpeace
Copy link
Contributor Author

cc @michaelpj (might be interested in reviewing)

@michaelpj
Copy link
Contributor

Could we have GTK_USE_PORTAL just be conditional on xdg.extraPortals being non-empty? That way we avoid another option.

Also, what's the rationale for having this off by default? All the other XDG things are on by default. Arguably they shouldn't be, but I'd prefer consistency if possible.

@samueldr
Copy link
Member

samueldr commented Jul 28, 2019 •
edited

One of the reason for being off by default is that it increases the base closure size quite a bit. I think it was 300MiB?

It, at least, made the sd_image too big to generate on hydra, blocking channels.

The reason is that it brings some gnomey bits into the non-graphical images from having the option turned on by default.

@michaelpj
Copy link
Contributor

Hmm, that seems strange but I have no idea what's in this portal package. I don't suppose we can just configure it to pull in less by default?

@worldofpeace
Copy link
Contributor Author

xdg-desktop-portal was only factored outside of flatpak because of the usecase in 4cb9a1f.

Since it's directly related to flatpak it's pulling in all those dependencies, it doesn't belong default.
The name xdg doesn't really have relation to the other xdg modules which are just for freedesktop specs.
And I think the closure was 604MiB.

Could we have GTK_USE_PORTAL just be conditional on xdg.extraPortals being non-empty? That way we avoid another option.

See description 4cb9a1f. Really shouldn't be set default like that.

@michaelpj
Copy link
Contributor

Okay, makes sense to me.

Should the desktop environments set the GKT option?

@michaelpj
Copy link
Contributor

Oh also, could we maybe put a little more of this reasoning into comments in the file, it can be a little hard to discover these things later otherwise!

@worldofpeace
Copy link
Contributor Author

worldofpeace commented Jul 29, 2019 •
edited

Okay, makes sense to me.

Should the desktop environments set the GKT option?

At the moment only GNOME should do that since it was designed for that environment.
And I think that's something that should be left up to the user, unless it's documented in that DE that it wants this.

Oh also, could we maybe put a little more of this reasoning into comments in the file, it can be a little hard to discover these things later otherwise!

Which in particular, I feel like the options descriptions and assertions suffice?

@michaelpj
Copy link
Contributor

Personally, I'd add a comment above the enable option explaining why it's disabled by default. I'd maybe add something to the option description for the GTK option saying what you just said (i.e. DE modules should enable this if it's advised by upstream).

@worldofpeace
Copy link
Contributor Author

Personally, I'd add a comment above the enable option explaining why it's disabled by default.

Perhaps I could do that because it implicates flatpak and a graphical environment heavily.

add something to the option description for the GTK option saying what you just said (i.e. DE modules should enable this if it's advised by upstream).

Huh, somehow in the previous comment I thought you meant add xdg-desktop-portal-gtk to extraPortals 馃槃.

The actual description of gtkUsePortal has

Defaults to <literal>false</literal> to respect its opt-in nature.

Only thing I can think of would be the pointer for Firefox as an example.

@michaelpj
Copy link
Contributor

Well, at the moment it's still pretty unclear to me when to enable gtkUsePortal. Perhaps that's fine and it's one of those "you'll know when you need it" options. But it would be nice to have a little bit more.

@worldofpeace
nixos/xdg: add gtkUsePortal option to portals
1b21c9d 
Prior to this change GTK_USE_PORTAL was unconditionally
set to "1". For this to not break things you have to have some
sort of portal implementation in extraPortals.

Setting GTK_USE_PORTAL in this manner is actually only useful
when using portals for applications outside flatpak. For example
people using non-flatpak Firefox who want native filechoosers.
It's also WIP for electron applications to support this.
@worldofpeace worldofpeace merged commit 7f2f31a into NixOS:master Jul 30, 2019
@worldofpeace worldofpeace deleted the disable-portals branch July 30, 2019 01:47
This was referenced Jul 31, 2019
Merged
Closed
@abbradar
Copy link
Member

I use GNOME 3 on some machines and they too had issues with Firefox open file dialog. Also GNOME was very slow to start a session, as if something timeouted. Given that maybe we should disable it for GNOME by default?

@worldofpeace
Copy link
Contributor Author

worldofpeace commented Aug 1, 2019 •
edited

I use GNOME 3 on some machines and they too had issues with Firefox open file dialog.

That is no longer a issue

Also GNOME was very slow to start a session, as if something timeouted. Given that maybe we should disable it for GNOME by default?

I think I've noticed this in #65291 so perhaps there was an issue before this. At any rate portals should be enabled for GNOME, so that is just an issue we should be able to fix in #65291. That also makes me assume that you have flatpak enabled in addition to this?

@worldofpeace worldofpeace mentioned this pull request Aug 26, 2019
Closed
@bobby285271 bobby285271 mentioned this pull request Feb 14, 2023
Draft
13 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@samueldr samueldr samueldr approved these changes

Assignees
No one assigned
Labels
10.rebuild-darwin: 0 10.rebuild-linux: 0
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
4 participants
@worldofpeace @michaelpj @samueldr @abbradar