Planning FileChooser portal implementation with nautilus

Desktop
, ,
1

Background

There has been a rough consensus for a while between nautilus developers, designers, and other members of the community that nautilus should provide a org.freedesktop.impl.portal.FileChooser backend. Unlike the GTK file chooser implementation, nautilus can provide visual and behavioral consistency with a single codebase, use GNOME platform features (e.g. libadwaita), nautilus features (e.g. starred files) and generally move along with the platform.

However, this has been vaporware up until now. And for good reasons: nautilus first needed to be ported to GTK4 and, even after, the main view components needed refactoring and cleanup. We had enough technical debt, so the “file chooser mode” should not come at the cost of even more technical debt.

Current Status

During the 46 development cycle, the view components underwent a major refactoring meant to, among other things, prepare for the file chooser mode. And the new Network view is being worked on. This means we are at the point in time where the codebase is finally getting ready to introduce a file chooser mode.

The GNOME Foundation is sponsoring me to make it happen during the 47 development cycle, as part of the Sovereign Tech Fund.

Portal Implementation

So, I’m opening this thread to allow technical input from the community.

Currently, xdg-desktop-portal-gnome uses GtkFileChooserDialog as the centerpiece of its implementation, enhancing it with portal D-Bus methods handling and external window parenting.

For nautilus to provide a drop-in replacement, it would need to expose something like a NautilusFileChooserDialog widget class as part of a library. For obvious reasons, maintaining a library API is something I would like to avoid.

Instead, my working hypothesis is we don’t need to have the portal implementation in xdg-desktop-portal-gnome and can do the whole portal implementation (executable, D-bus method handling, parenting) in the nautilus codebase. I assume installing a nautilus.portal file and changing gnome-portals.conf to prefer the nautilus implementation would be enough to make it work.

xdg-desktop-portal-gnome could probably drop its FileChooser implementation, if we assume nautilus is available in GNOME, as xdg-desktop-portal-gtk is already acting as fallback.

21 Likes
2

:+1:

I’d rather much prefer this solution, as it avoids exposing a weird, semi-private, unstable API.

Yes; once Nautilus acts as the file selection portal we can drop the FileChooser portal implementation inside the GNOME portal. The GTK portal already acts as the “portal of last resort”, so non-GNOME environments can always fall back to a file selection implementation. Additionally, users can configure xdg-desktop-portal through the portals.conf file, and add their own preferred backend for the file selection portal, if they don’t want to use Nautilus.

1 Like
3

Thanks for the validation.

One possible downside of doing everything on nautilus codebase is that maybe I need to copy and paste the parenting code which handles both x11 and wayland and combination of both.

Also, nautilus would need to depend on xdg-desktop-portal. I wonder if I can make it a hard dependency or must make it optional (i.e. building without portal implementation).

4

Yes, though it’s not a huge deal, since it’s mainly glue code around GTK’s window handle export API; don’t expect the implementation to change.

Not sure about this. The only things you would depend on are:

  1. the org.freedesktop.portal.impl.FileChooser.xml D-Bus interface file, for generating the interface skeleton
  2. the location of the nautilus.portal file, which is @datadir@/xdg-desktop-portal/portals

You can copy the XML file in tree, if you don’t want to read it from the system, though you’d have to ensure that you keep it up to date in case the implementation changes; but even if you decide to depend on xdg-desktop-portal, it would be a build-time dependency only.

1 Like
5

Design feedback

I think the design mockups look great in isolation!

However, knowing how the Gnome user interface generally looks and feels, I had expected the design to adopt the Action Dialogue pattern. The HIG even explicitly states save dialogues as a “classic example” for the Action dialogue.

Maybe we could try to place the additional UI elements more in a way that resembles this pattern? Or maybe we should change the HIG in this regard?

6

Hi jano.

I was asking for technical implementation feedback only.

For the dialog UX design, it’s best to open a new discussion and talk to designers.

7

This is known, and the pattern used here is a new, experimental one that might be used in more places in the future.

4 Likes
9

It hurts to see such behavior from GNOME community, any comment that criticize them is removed.

10

@medin Hello.

I must assume you misunderstand what we are talking about here.

And that’s fine. The feedback I’m asking for here requires a deeply technical knowledge.

But your message comes off as full of negative energy. There is no need for that here. Let’s keep things positive and be nice.

1 Like
11

Being negative about something, without even understand what that something is, is not a critique. It’s just being negative for the sake of it.

If you are worried about the impact of something, you can ask for clarification without being negative about it. After getting a better understanding of it, you may come to realize there is nothing to worry about.

3 Likes
13

Thanks for confirming you are indeed misunderstanding. (Edit: this was a reply to a now-removed message making false claims about freedesktop.org portals.)

1 Like
14

I would absolutely love if the nautilus file chooser portal would be easy to setup on other desktop environments unlike the gnome portal, which seems to be impossible to use anywhere except for in a graphical gnome session.

15

That’s because the GNOME portal relies on GNOME interfaces, and those interfaces don’t exist outside of a GNOME session.

It’s like saying you want to use the KDE portal without running KDE.

16

I hoped GNOMES file chooser portal would still be usable without running GNOME. I didn’t look into how it’s implemented, but it seemed reasonable to assume that this could work.

17

Yes it can work but not by default. There is a configuration file for which portals to use under which environment. I’m not sure if this is supposed to be user configuration or just for distributions, but technically it can be configured to work like that. Whether it is a good idea is a whole different question.

18

If you mean not being independent (as a program) from Nautilus, then look on the security side to decide on independence (note: just to say it): influence of plugins? tracker? …

Another consideration is the future addition of features that would not be particularly wanted in Nautilus, e.g. support for tags (presented as folders that we can browse like in Hyperplane).

19

Can you elaborate on the security concerns? I’m don’t know what you mean.

Hyperplane doesn’t affect any of this. In theory Hyperplane could offer an alternative portal implementation though.

20

Anything that can possibly affect Nautilus if Nautilus is the portal.

That’s about features to possibly support, not limited to my example (note this is not about Hyperplane itself, that’s about if users have tags and want to browse them like folders). Regarding browsing tags like folders (vs. searching them), this is more about having a portal supported by what users can see as belonging to the system or desktop environment. In such context, if a file manager not belonging to the system has an implementation, then this one should be added as belonging to the system (by a vendor or by a DE). That’s just for consideration in your choices if it happen to have features that are independent from Nautilus itself. (I hope that’s a bit clearer)

21

I still don’t follow your train if thought. Any software may possibly have security bugs. And whether it’s the same nautilus process or two separate nautilus processes wouldn’t make a difference.

22

I’m sorry but I’m still completely at loss.