This is mainly to reduce possible entry points (I’m talking about the fact that the file chooser would be completely independent of Nautilus). However, my comment is just a “reminder” as you are obviously the best person who knows Nautilus.
Not sure what you mean by “fact” here. The plan is exactly the opposite: to have nautilus provide the FileChooser implementation.
I really like this design, and the approach of Nautilus itself providing the portal implementation. I’m super excited to see it all in action! I can see the same approach serving as a template for different kinds of “stuff pickers” in the future. I think we’ll really benefit from this type of thing to get content from one sandboxed app to another sandboxed app in cases where these apps aren’t really communicating in terms of file hierarchies. (An example of such an app in GNOME would be Sound Recorder, and it’s a common pattern on Android and iOS).
So this work looks like exactly the place to start, and it would be neat to morph it into something more general once it’s working well 
There were mockup designs for such an any-app content picker, so maybe we get there at some point.
But that would require either changes to the portal interface or a new interface. Something like “reverse” intents maybe.
In any case, my work here doesn’t get us any closer to that idea. It’s simply changing who implements the file chooser dialog,
1 Like
This topic was automatically closed 45 days after the last reply. New replies are no longer allowed.