code
code copied to clipboard
elementary
Use `org.freedesktop.portal.OpenURI` for Providing the AppChooser
supersedes #1029
Make use of the OpenURI portal for showing an AppChooser and for opening the file on the File Manager.
This one can be used on host too.
Added a new property on FolderManager.File to query write access, this should work with both read-write and read-only files and directories.
Is there a reason for the context menu for folder items to differ from that for file items (compared to master running natively)? The former has an ellipsis and launches straight into the AppChooser whereas the latter has a submenu offering an immediate option to open in the FileManager as well as an "Other applications" option (which offers the File Manager).
Since we don't have access to the AppInfo inside the sandbox, the submenu in FolderItem had only one option (AppChooser), so i removed it, while, FileItem ended with three (New Window, File Manager, AppChooser).
In master, the file manager entry is created manually by querying the default AppInfo for inode/directory, the portal has the OpenURI.open_directory() method to replace this case, so i used it. Also, i can't see the File Manager in the AppChooser for FileItem here.
Will changing to the OS7 platform require any changes?
You say the flatpak runtime? since we are using Gtk3 here, no changes should be needed. For Gtk4, we need to adapt the MainWindow.export() code to use Gdk.Surface instead of Gdk.Window.
I still do not really see why a fileitem and a folderitem should have a different "Open in..." submenu. Can we not offer a "Open in FIleManager" item for folder items as well as file items?
It could make sense to offer a "New Window" option for folders as well as files but that is outside the scope of this PR.
I still do not really see why a fileitem and a folderitem should have a different "Open in..." submenu. Can we not offer a "Open in FIleManager" item for folder items as well as file items?
we can, but it's less useful for folders, since the AppChooser will show the FileManager anyway. that not the case for files.
It could make sense to offer a "New Window" option for folders as well as files but that is outside the scope of this PR.
Well, projects folders aren't unique per-window, so any new window will already have all the folders anyway.
we can, but it's less useful for folders, since the AppChooser will show the FileManager anyway. that not the case for files.
I see. I guess it can be left to the UX team to decide whether the context menu needs redesign - it it is not blocking for this PR anyway.
Well, projects folders aren't unique per-window, so any new window will already have all the folders anyway.
Yes, we would have to implement different projects per window for that to be useful.
Sorry for taking so long for reviewing it, but it doesn't seems to be the solution we want here as the portal is already implemented elsewhere.
Implementing the OpenURI portal inside Code is not the way to go, a portal implementation has to be out of the container
The only way to trigger a portal for opening a file would be:
GLib.AppInfo.launch_default_for_uri (file.file.get_uri (), null);
@danrabbit We should make a blog post about how app developers should replace the in-app "Open In…" menus with something that works in containers
Sorry, but I think you misunderstood the PR, we aren't implementing the OpenURI portal here, but using it directly.
Neither Glib or GTK expose the OpenURI.open_file method with the ASK flag that is used do show the app chooser. They also don't expose the OpenURI.open_directory method that we are using here to open the file manager.
@tintou yeah the problem is there isn't a replacement portal yet :sweat_smile: https://github.com/elementary/portals/pull/38
@danrabbit So should this PR be blocked pending a wrapper for the OpenUri portal appearing in Gtk or Granite, which it can then use?
@jeremypw it seems like generally the OpenURI Portal probably isn't the appropriate portal to use here long-term anyways so this is more of a work around to preserve some functionality inside the sandbox. The proper long-term solution would be to create a sharing portal that's actually designed for this. Since we're not shipping Code in a Flatpak currently, I'm not sure this specific workaround is a huge priority? We could probably wait for a new portal?
Since we're not shipping Code in a Flatpak currently, I'm not sure this specific workaround is a huge priority? We could probably wait for a new portal?
In view of this I think this can be closed and the matter reviewed when we come to FlatPak Code (not soon afaik)