GNOME Bugzilla – Bug 742468
Allow opening files from other apps
Last modified: 2021-07-05 11:31:44 UTC
This would be a fairly big change, so I'm putting the proposal out for discussion to begin with. Documents, Music and Photos work on the principle of being containers for collections of content. As such, they haven't been in the business of displaying or playing content that is passed to them from elsewhere. The main issue with this is that separate "viewer" applications are required for opening content items from Files - GNOME has a Document Viewer, an Image Viewer, Documents and Photos, for example. It also means that there is no good way to play an audio file from Files. One way we can tackle this issue is by elaborating the preview functionality that is provided by Files. Having quick and easy way to view a content item directly from the File browser is a good thing to have. At the same time, sometimes you want to have a document (or documents) open for a period of time. Files preview doesn't seem like a great fit for this. As a result, I'm tentatively suggesting that we make it possible to open files with the content applications. How it would work: * Documents, Music and Photos would be able to open content items from Files. * When a content item is opened, the app displays/plays it, and offers the option to import it (such as with a "Add to Documents" button in the header bar). * If the content item is imported, the file is copied into the corresponding directory (for example: ~/Documents).
Completely agree with that, you shouldn't need 2 applications that do the same thing to be installed to be able to read a document, or having to copy it locally.
(In reply to comment #0) > * When a content item is opened, the app displays/plays it, and offers the > option to import it (such as with a "Add to Documents" button in the header > bar). > * If the content item is imported, the file is copied into the corresponding > directory (for example: ~/Documents). Quick question. Stuff that is already somewhere inside ~/Documents would not have the "Add to Documents" UI, right?
(In reply to comment #2) ... > Quick question. Stuff that is already somewhere inside ~/Documents would not > have the "Add to Documents" UI, right? Right.
(In reply to comment #0) > As a result, I'm tentatively suggesting that we make it possible to open files > with the content applications. How it would work: > > * Documents, Music and Photos would be able to open content items from Files. > * When a content item is opened, the app displays/plays it, and offers the > option to import it (such as with a "Add to Documents" button in the header > bar). > * If the content item is imported, the file is copied into the corresponding > directory (for example: ~/Documents). I thought about this for a bit, and while I completely agree with the rationale behind this proposal, I am not sure the implementation would be the best way to address the issue. Some considerations: - I completely agree with the necessity to preview one or multiple documents for a long period of time, and that it's a separate use case from the preview functionality integrated in a file manager. To me, the file manager preview serves more the purpose of efficiently identify a file inside a directory, while a "viewer" allows me to keep a version of the file around and read it while possibly also looking for other things and reading them. - as a consequence of above, I think a viewer only makes sense when it supports multiple windows, and possibly different kind of files at the same time. - the concept of Documents' is different. There's an overview with all the documents identified in the standard locations, plus from all the sources I connected to the application; it's heavily optimized towards searching, and the starting point is never a file or a folder. When a document is open, the interface is optimized towards being immersive. If you wanted to have this functionality in Documents, having multiple windows in the application becomes a must, and with multiple windows, the concept of the overview becomes a little murkier. Also the next thing we will add if we go that way is a file chooser to import, which I think goes against the principle of the application. I think ultimately it's three different use cases that are best served by three different interfaces: the quick preview from the file manager, a viewer and a manager application. The flow could go quick preview -> view -> add to manager. Note that while this works fine for Documents and Photos, I'm not completely sure about Music/Videos.
(In reply to comment #4) > If you wanted to have this functionality in Documents, having multiple windows > in the application becomes a must, and with multiple windows, the concept of > the overview becomes a little murkier. Also the next thing we will add if we go > that way is a file chooser to import, which I think goes against the principle > of the application. For interop with Files, the "import to documents" UI doesn't necessarily need to have a file chooser based UI. It will probably be a button (either in Files or the viewer) that copies stuff into XDG_DOCUMENTS_DIR. I mean, we have spoken about the need to import from a web browser or a removable device, but I have never seen an import UI that involves a file chooser.
(In reply to comment #5) > (In reply to comment #4) > > If you wanted to have this functionality in Documents, having multiple windows > > in the application becomes a must, and with multiple windows, the concept of > > the overview becomes a little murkier. Also the next thing we will add if we go > > that way is a file chooser to import, which I think goes against the principle > > of the application. > > For interop with Files, the "import to documents" UI doesn't necessarily need > to have a file chooser based UI. It will probably be a button (either in Files > or the viewer) that copies stuff into XDG_DOCUMENTS_DIR. Agreed there. We have a "Make available offline" menu item in totem for that.
(In reply to comment #5) > For interop with Files, the "import to documents" UI doesn't necessarily need > to have a file chooser based UI. It will probably be a button (either in Files > or the viewer) that copies stuff into XDG_DOCUMENTS_DIR. > > I mean, we have spoken about the need to import from a web browser or a > removable device, but I have never seen an import UI that involves a file > chooser. Web Browser or removable devices are slightly different use cases, since for the former you never deal with a file on the filesystem in the first place, and for the latter, the import was within the application overview itself. Allan was talking about really opening a file with Documents in the more traditional sense, and having a button to add it in the overview. I get your point though, we wouldn't *need* to do it; it just feels like if you can open an arbitrary file with the application through the file manager, the next thing you want is to open it from within the application itself.
Being able to open documents from Files brings the same functionality that you would need to support opening OpenOffice or EPub files from the web browser, or the mail client. It's the same functionality that would be required to pass documents through Portals. That doesn't mean your interface needs to have an "Open..." menu item, and go down that slippery slope.
(In reply to comment #4) I agree with the vast majority of this. ... > If you wanted to have this functionality in Documents, having multiple windows > in the application becomes a must, and with multiple windows, the concept of > the overview becomes a little murkier. Multiple windows might well be necessary anyway - wanting to be able to have several documents open isn't that unusual, after all. We have introduced multiple windows for some of the other content applications, for this reason - Notes is an example. You're right that it is tricky to reconcile multiple windows with content overviews. The way we have attempted to do that elsewhere is by only showing the overview in one of the windows - so you are effectively splitting out the content item into its own window, rather than launching another instance of the app. What happens when you try to open multiple files with Documents is definitely an important detail to get right. > Also the next thing we will add if we go > that way is a file chooser to import, which I think goes against the principle > of the application. I'd be interested to hear a bit more about why you think that. ... > The flow could go quick preview -> view -> add to manager. Which is fairly close to what we have now. And it has to be said that, while the redundancy we have right now (Document Viewer alongside Documents) isn't particularly elegant, it isn't the most terrible thing in the world either. The bigger issues I can see: 1. As you've hinted - what to do for audio and video? 2. I think that keeping Documents separated from Files turns it into a bit of a ghetto. People end up using Files and the Document Viewer for local content and their browser for any documents in the cloud.
I'm quite pleased with my latest attempt to come up with a design for this bug: https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/content-apps/open-files-with-content-apps.png The main thing that's missing is detail on moving files to the XDG folders: how to provide progress feedback, what to do in case of conflicts, would it be possible to view/edit during the transfer, and so on.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-documents/-/issues/ Thank you for your understanding and your help.