gedit adds comboboxes to the GtkFileChooserDialog to choose the character encoding and line ending type. It's convenient to have those in the file chooser, at least for file saving.

Created attachment 330338 [details] [review]
first patch

Created attachment 330339 [details] [review]
second patch

(In reply to Sébastien Wilmet from comment #1)
> gedit adds comboboxes to the GtkFileChooserDialog to choose the character
> encoding and line ending type. It's convenient to have those in the file
> chooser, at least for file saving.

Yeah, those will be lost with native file choosers.

The thing is: if you can't see any files because your sandboxed app has no direct access to the filesystem, those comboboxes don't really help.

The two patches are identical. The second one was maybe supposed to be for file saving?

Created attachment 330364 [details] [review]
second patch

sorry about that

I'm not a gedit maintainer, but it seems to me that removing important features of a text editor is not really an improvement.

The features that the above patch removes:
- choosing the character encoding;
- choosing the line ending type;
- support gzip compression.

If those are not possible to integrate with a native file chooser, it must be integrated in gedit in another way. But when saving a file seems like a good time to ask the user about those options.

Also, to support gedit in a Flatpak sandbox without host filesystem access, there is also the integrated file browser plugin to adapt. And I think it's more difficult to come up with something still convenient to use, and useful. So host filesystem access is anyway needed for the integrated file browser.

From a selfish point of view I really don't care much about the character encoding and gzip compression, but choosing the line ending type is a must for me...

I understand that these are features that somewhat set gedit apart from the rest. Personally, I've always considered them a bit odd and out of place in the file chooser.

But clearly, we should have some way to handle the equivalent in a sandboxed scenario. One would be to just try loading the file with default settings and ask the user if that fails.

Regarding the file browser plugin: thats a feature that simply will not work in a sandbox. At the end of the day, there's tradeoffs required.

My long term plan was to extend the native file chooser API to let you specify a list of checkboxes and combobox dropdowns you could show in the dialog, and report the values of these when the user OKs. This could be implemented in both the win32 implementation and the portal one. Would that be enough for gedit?

Of course, other parts of gedit like the sidebar wouldn't be very useful in a sandboxed environment, but maybe at least it would do *something* and then you could grant it more access if you want to use it more heavily.

I've written some code for this today (only implemented for the portal case).

https://git.gnome.org/browse/gtk+/log/?h=portal

https://github.com/flatpak/xdg-desktop-portal-gtk/pull/12

I think the basic portal stuff is ok, but there are some wider issues:

a) You implemented the gtk filechooser support for choices in the portal, but it should really be in the gtk implementation of GtkFileChooserNative, so that it can easily be reused in the portal *and* by apps not using a portal (but using the GtkFileChooserNative interface).

b) such new feature additions to the native filechooser interface needs work in the other native file chooser implementations so that they fall back on the gtk implementation instead of e.g. the win32 dialog until such a time as we add proper choice support to those implementations.

(In reply to Alexander Larsson from comment #12)
> I think the basic portal stuff is ok, but there are some wider issues:
> 
> a) You implemented the gtk filechooser support for choices in the portal,
> but it should really be in the gtk implementation of GtkFileChooserNative,
> so that it can easily be reused in the portal *and* by apps not using a
> portal (but using the GtkFileChooserNative interface).

Good point, I can look at that.

> b) such new feature additions to the native filechooser interface needs work
> in the other native file chooser implementations so that they fall back on
> the gtk implementation instead of e.g. the win32 dialog until such a time as
> we add proper choice support to those implementations.

I'll look at fixing up the fallback implementation; I don't think I can do win32.

So ftr, the plan is to move the new api to GtkFileChooser, and then implement it for the various native dialogs.

I've pushed branches for the new approach:

https://git.gnome.org/browse/gtk+/log/?h=portal
https://github.com/matthiasclasen/xdg-desktop-portal-gtk/commits/filechooser-choice

(In reply to Alexander Larsson from comment #10)
> My long term plan was to extend the native file chooser API to let you
> specify a list of checkboxes and combobox dropdowns you could show in the
> dialog, and report the values of these when the user OKs. This could be
> implemented in both the win32 implementation and the portal one. Would that
> be enough for gedit?

As is, it would not be enough for choosing the encoding in gedit, because when we click on "Add or Remove…" in the combobox, another dialog is opened. Although it should be possible to find a better UI for that.

Yes, I'm not going to add portal api for that sort of interactive back-and-forth between the application and the portal process. We will have to find another place in the application ui to configure encodings to show.

I've added a working print portal too now. It comes for free if you are using GtkPrintOperation - does gedit do that ?

Paolo is the one who made it but if I recall correct we have some text editor widget as well.

Yes, we use printoperation but we use the feature adds a custom tab to the dialog, not sure if that is a problem for portals.

Thanks a lot for all your work on this and I am sorry that I did not provide timely feedback

(In reply to Paolo Borelli from comment #20)
> Yes, we use printoperation but we use the feature adds a custom tab to the
> dialog, not sure if that is a problem for portals.

It is not currently supported :-( I can look at doing something similar to the filechooser, just needs some time.

*** Bug 784584 has been marked as a duplicate of this bug. ***

As a consequence of this bug, it's not possible for Text Editor flatpak build to use SMB shares for opening or saving documents.

*** Bug 793695 has been marked as a duplicate of this bug. ***

This is fixed in gedit 3.30.0.