GNOME Bugzilla – Bug 138876
default download process suffers from lack of feedback
Last modified: 2009-07-19 19:21:55 UTC
[submitting this bug to "split" the bug I filled with 3 problems described] The download process suffers from lack of better feedback. The first time I right-clicked a file and asked it to 'download link' I was puzzled as, in the end, I didn't know where the file was! I do not usually use desktop icons and, even if I did, epiphany's window was covering them and I would only notice that a 'Downloads' folder appeared after some time. The download process should explicitely state that the file was downloaded there and have a button asking to 'open the folder where the file is' or 'open the file', like we used to have.
Edit->Preferences->General: Uncheck "Automatically open and download files".
That does not address the problem. The problem is not the download starting automatically, but rather the lack of feedback on any download process, be it automatically or explicitely started.
Use "Save Link As..." instead of "Download Link" if you want to specify where to save the file and what to call it. Any files downloaded with "Download Link" will download to the folder you have set in Edit -> Preferences -> Download Folder.
I guess what the reporter isnt liking is the fact that the user need to figure out where the downloaded files go, and in his opinion that's too hard atm.
Exactly, thanks Marco.
So: If you have automatic download files will go to your Downloads Folder of choice. If you don't and/or you select Save Link As, you'll get a filepicker so you can choose whatever folder you like. Then: How is it hard to know where are files going? What I'm missing?
The problem is really here: "If you have automatic download files will go to your Downloads Folder of choice." The problem is: think about, let's say, my mom. She wants to grab a pdf file from the internet. Then she goes to foobar.com and clicks the file. Ok, a nice dialog opens saying 'downloading' and then gpdf opens the file. My mom then thinks. "Alright, now, where's the file? Will I have to download it everytime I need it?". The problem is my mother did not choose a 'Downloads Folder' and nothing really helps her figure out that the file is in the Downloads folder that is in her Desktop.
Just a thought: perhaps the download notification icon could blink when a Downloads folder is first created? When clicked or hovered, a message would be shown that the downloaded file can be found in that folder.
>My mom then thinks. "Alright, now, where's the file? Will I have to download it >everytime I need it?". The problem is my mother did not choose a 'Downloads >Folder' and nothing really helps her figure out that the file is in the >Downloads folder that is in her Desktop. Downloading the file again ideally should not be necessary. We should detect if the downloaded file is the same and just use it. After first time I'm pretty sure it's not that hard for people to figure out the download dir position, it's very visible on the desktop. Additionally I think that directory should be a default, visible before epiphany starts. Though i18n issues make that sort of a pain.
Mass reassigning of Epiphany bugs to epiphany-maint@b.g.o
> The problem is not the download starting automatically, but rather the lack of > feedback on any download process, be it automatically or explicitely started. Another use case where the lack of feedback is a problem. If an administrator configures download folder via gconf the key /apps/epiphany/directories/download_folder and sets it to a folder to which a user does not have write access to, then when the user (non root)tries to download a file, nothing happens. The user does not even come to know that the download failed as user did not have write permissions in the directory he has selected. On a few occassions, when I tried a download epiphany crashed, but on others no error was displayed. I feel that if a failure occured an appropriate warning should be displayed, so that the user knows what happened.
from bug 155833: It occured to me that we could make the use of the Downloads folder a bit more obvious. Whenever we download a file without default actions associated, we silently place it in ~/Downloads. Why not open a Nautilus window of the Downloads folder after completing the download by default? This is what file-roller does after completing archive extraction. Seems to me this feature should be disabled/enabled via the 'automatically download and open files' pref which already is in the General preferences.
*** Bug 155833 has been marked as a duplicate of this bug. ***
file-roller uses: uri = g_strconcat ("file://", folder, NULL); if (! gnome_url_show (uri, &err)) { /* display error dialog */ } g_free (uri);
Created attachment 51844 [details] [review] epiphany-1.8.0-launch-download-folder.patch Patch as suggested. This uses ephy_file_launch_handler ("x-directory/normal", ...) to launch the parent directory (gnome_vfs_uri_get_parent) of the download URI. It'd be nice to have Nautilus scroll to (and possibly select) the downloaded file, but Nautilus doesn't have that functionality atm - see bug 158113.
Thanks for the patch! This only opens nautilus when you do "Download"; should "Save As" do the same? (Since Download from the content handler is a rather uncommon operation, only offered on things you cannot open directly.)
I think probably not - that would be inconsistent with other applications' "Save As" actions.
(In reply to comment #9) > Downloading the file again ideally should not be necessary. We should detect if > the downloaded file is the same and just use it. It doesn't currently happen, and I consider it extremely important. Refiled as bug 326312.
chpe, can we decide about this before feature/ui freeze?
I'm not sure I want the downloads folder to open every time I download something, but if you think this is what users want, I'm okay with it.
Created attachment 58609 [details] [review] 138876.bugzilla.gnome.org-launch-download-folder.patch updated to apply cleanly to 1.9.6
I've tried this patch and works fine with current CVS HEAD.
Created attachment 58656 [details] [review] Corrected patch offsets to apply cleanly agains CVS HEAD This patch is the same as the patch above, but with updated patch hunk offsets, so that it applies cleanly against HEAD.
Since this is a UI change which is contested by some, it will have to wait until past 1.10. There have been objections to opening the download folder in the foreground; instead it might be better to open it in the background and make it flash in the windowlist. Ed, what do you think of that?
I guess that would need to be communicated to the launcher/nautilus somehow... need an API addition?
My epiphany build has this patch for a week now and I really like how it works right now. If the nautilus window pops up in front of the browser window, this would really annoy me for all but the smallest downloads (a few seconds at most). Suggestion for non-intrusive window opening: - if the download window is on top, open the nautilus on top too - if the browser window is on top (or the download window is not open at all), open nautilus in the background - (maybe) open nautilus in front if the download takes less than, say, 5 seconds. Btw, the last patch applies cleanly against CVS HEAD.
With focus stealing prevention (whatever it's called... NET_WM_USER_TIME, anyway), nautilus will open in background if the user does anything (mouse click, keystroke) in the Epiphany window. This Just Works for me here, using metacity 2.13.55. Current behaviour: * if download is near-instant, nautilus opens on top * if user interacts with epiphany (could be as little as scrolling) nautilus opens behind. I don't see a problem with this behaviour; the only scenario I can see it might be unwelcome is if the user downloads a file linked from an article (say) and does not scroll down before the download completes. But this is indistinguishable from the computer's POV from the user downloading the file and staring at the download window till it completes, in which case opening in front would be desired.
Maybe if the user interacted with the download window, the user time stamp should be updated... would be a bit hard to implement, though. If we don't get nautilus download integration (looks like it), we probably should just apply this.
re comment 28: yes, it would be possible. Basic sketch: * embed/ephy-download.[ch]: add ephy_download_update_user_time (EphyDownload *download, guint32 user_time) to EphyDownload interface * embed/downloader-view.c: call ephy_download_update_user_time appropriately * embed/mozilla/mozilla-download.cpp: make impl_update_user_time call MozDownload::UpdateUserTime * embed/mozilla/MozDownload.cpp: write MozDownload::UpdateUserTime to unpack the mMIMEInfo->GetApplicationDescription; if it's gnome-default: or gnome-browse-to: then change the user_time field and repack it Note: * If we're updating user time on gnome-browse-to: downloads we should also update user time on gnome-default: downloads. * When is it appropriate to update user time? If the user interacts with the download window, should all downloads have user time updated, or only the selected download? * Perhaps this should have a separate bug?
Created attachment 66992 [details] [review] 138876.bugzilla.gnome.org-launch-download-folder.patch Updated to cleanly apply against 2.15.2.
Created attachment 67015 [details] [review] 138876.bugzilla.gnome.org-launch-download-folder.patch Corrected to actually compile (!)
Let's try this one. Ok to commit to HEAD only, thanks for the patch!
Ed, has this been committed yet?
No.
Ed, care to commit the patch from comment #31? If not, drop a note so that I can do it for you.
2006-10-15 Wouter Bolsterlee <wbolster@gnome.org> * embed/mozilla/ContentHandler.cpp: * embed/mozilla/MozDownload.cpp: * lib/ephy-file-helpers.c: (ephy_file_browse_to): * lib/ephy-file-helpers.h: * src/popup-commands.c: (save_property_url_completed_cb), (save_property_url): Automatically open a Nautilus window after downloading has finished. Fixes bug #138876, patch by Ed Catmur.
Nice feature but not for me, I use Desktop for downloaded files and have icons enabled on Desktop. This way I see all download I made. Is there any way how to disable it?
It could make sense to disable the behaviour in the special case that the download folder == desktop (taking the nautilus desktop_is_home_dir pref into account). Please file a separate bug for this.
(In reply to comment #38) > It could make sense to disable the behaviour in the special case that the > download folder == desktop (taking the nautilus desktop_is_home_dir pref into > account). Please file a separate bug for this. Done, see bug #383698
Please there should be a way to disable this feature. I have to download a bunch of files most of the time (9, 10 files) and it opens 10 folders. Please include a checkbox in the preferences to disable this feature, it's getting annoying.