RE: About the new download behaviour

[mpeseng tin it]

>Hi!
>
>Just realized that the current download behaviour in HEAD is the planned
>one. Ie. the fileselector dialog is gone forever? If this is the case I
>just want to say, *please no*! If the reason it's currently just
>downloading without asking because the filechooser is not finished,
>please ignore my mail :)

No, that's intentional. Though it's supposed to experimental.

>The reasoning why I think this is a bad idea is:
>
>* Most people working with computers have some kind of structure in
>  there filesystem. The current solution puts everything in one
>  directory (or even worth, on the desktop). In order to keep the
>  structure you'll have to find the file you just downloaded immediately
>  and move it. This makes it harder to download a file and place it
>  where you want since you have to open a nautilus navigation windows
>  aswell.

There are pro and cons I think.

Pro of a download directory:

- Less clicks to download a file
- File management functionalities delegated to file manager as they should.
- More consistent behavior of click -> Open file
- Ability to have a notification only downloads window that can be closed
automatically

Cons of a download directory

- Maybe more clicks to organize files, especially in a hierachy like Downloads/Music.
In the base case the clicks seem more or less the same though (Show Desktop,
Drag to Music folder on the desktop, Show browser again).
- If there are no other dialogs showed you end up with problems like you
are describing below. Some of them can be solve I believe, though I'm not
sure they can be solved completely.

This is possibly something worth a pref. Alternatively we could change Download
link in context menu to Save Link As... and have both behaviors available.
Though what I'm really concerned is to find out if click -> Open behavior
is a good default, that's what most users would  use anyway.

>* If for example the download link says "Download" you will not know
>  what the filename will be so you would have to _search_ for the file,

>  possibily without knowing what you search for. If it's a large file
>  you'll have time to write down the name of the files (from the
>  download dialog). If the filename is named something like
>  sd2fasdf32.zip, even that will be hard and impossible to remember. If

>  it's a small file you're out of luck because then you won't have a
>  chance to even see the download dialog.

Small files are certainly an issue. The idea was to delay closing for a
few seconds, so that it would be possible to read the filename.
Also the file is autoopened when download finish, so you can see the name
of the file in the application that opened it.

>* If you for example browse around and downloads a couple of documents

>  that you want to read from various servers (probably with different
>  naming schemes for there files) about different topics you'll end up
>  with a bunch of files (probably on the desktop since according to
>  usability folks most people don't look in there preferences) that you
>  actually have to open in order to name/move them into something that
>  makes you remember what the file actually was.

Yeah renaming is probably the worst con of a download directory, it's certainly
a lot less convenient to do ... I guess files content preview helps here
...
In general current design seem to make easier to look at documents immediately
while introducing problem to download a lot of them and organize them for
later.
IHMO the two cases should be handled one by click and the other by context
menu (which would act exactly like a Save As), but Dave doesnt listen to
me ;)

>* You risk to end up with a lot of small files on your desktop/download

>  directory. Simple because you click links and some of them might start
>  a download without you having a chance to stop it. With a file
>  selector you get a notice that you are going to download a file to
>  your disk and have the possibility to stop it. Imagine when people
>  start clicking on scripts that happens to lay around on there desktop
>  that they have no idea what they are.

For scripts we plan to add a dialog with a warning also about the possible
risk. So they would not be downloaded without confirmation.
There could be a problem with other file types too though, this is something
that I'm still not sure about ... but it certainly worries me :/

Seth I'm ccing you too, if you have a bit of time to look at the issue I'd
be grateful. This is what I wanted to talk about in irc ...

Marco