View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002041 | gnunet-gtk | gnunet-fs-gtk | public | 2011-12-26 20:59 | 2012-02-28 11:06 |
| Reporter | Christian Grothoff | Assigned To | Christian Grothoff | ||
| Priority | urgent | Severity | tweak | Reproducibility | N/A |
| Status | closed | Resolution | fixed | ||
| Product Version | 0.9.1 | ||||
| Target Version | 0.9.2 | Fixed in Version | 0.9.2 | ||
| Summary | 0002041: suggested filenames for downloads are not ideal | ||||
| Description | When downloading a directory search result, the suggested filename is something like "$HOME/dirname/", which is bad as this is not a valid filename. The "correct" default would be "$HOME/dirname.gnd" (as we're downloading the file with the directory representation in it). Furthermore, if we then download a file from that directory manually (not recursive-download), the suggested filename is again "$HOME/filename" instead of what would be more appropriate, namely "$HOME/dirname/filename" (as it is a file from within 'dirname/'). | ||||
| Tags | No tags attached. | ||||
|
|
Fixed '/' -> ".gnd" part. |
|
|
There's a problem in saving a file that is part of a directory. I can construct a filename with extra parent directories - no problem. The problem is that suggesting such a name leads to "directory does not exist" error in gnunet-fs-gtk, because GtkFileChooser can't pick a file to save in a directory that doesn't exist. Also, it occurred to me that torrent clients (which is what people are used to) don't really offer you to re-name files when you download. At least, not in the same way. For example, Azureus will let you pick the directory where torrent contents (files and directories alike) will be saved, and will show you a full flat list of relative (to the directory where they will be saved) file names in the torrent, and will let you to change filenames individually (the Save as dialog that it shows for that will has no non-existent subdirectories, i.e. it has the same limitations as GtkFileCHooser; i'm not sure why they didn't allow filenames to be edited by hand there). I'm not sure how to fix this. Some possibilities: 1) Extra context menu item for files - "Download with suggested name", which will use suggested name (with parent directory components, creating subdirectories where necessary), without displaying a "Save as..." dialog (will display "Select directory" dialog instead, to select destination directory) 2) Scrap "Save as..." dialog and use a custom-built Save dialog similar to the one Azureus uses. "Save as ..." will be invoked from it when individual files need to be re-named. It will also allow to download only some files, not all of them (right now GNUnet search and orphan tabs do not allow multiple selections, which means that you either download files one-by-one, or have to download the whole directory (with all subfiles and sub-subfiles, etc); enabling multi-selection is not straightforward, and is likely to lead to (1)). |
|
|
Suggesting the filename is easy to fix: just manually (mkdir from C) create the directory before suggesting it. I think that should be fine. Now, I was actually not really thinking of even doing this: you picked the top-level name of the directory when starting the download (i.e. test.gnd). If you then choose to download files from within that directory (i.e. test/a.jpg), then I don't think it is necessary to prompt you AGAIN for the filename (just use test/a.jpeg), except maybe if the meta data doesn't specify a filename (which can theoretically happen). So my suggestion is "save as..." only for top-level downloads (from search result / URI), and then for recursive downloads (manually triggered or automatically triggered) we never ask unless we have to (i.e. no filename given in meta data). |
|
|
mkdir a directory before asking? And if i cancel the dialog? Leave the directory there, or delete it? What if it already existed when we have tried to create it, and had files inside it - deleting it, with its contents? This is fixable, with some effort (will have to track some things, and check the directory before saving things to it), but sounds rather messy. |
|
|
As I said, I'd not even ask in this case and just put the file in there. |
|
|
Suggestions are now pretty sane and work nicely (~SVN 19688). |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2011-12-26 20:59 | Christian Grothoff | New Issue | |
| 2011-12-27 23:46 | Christian Grothoff | Priority | normal => urgent |
| 2011-12-27 23:46 | Christian Grothoff | Target Version | => 0.9.2 |
| 2012-01-01 21:27 | Christian Grothoff | Note Added: 0005234 | |
| 2012-01-01 23:30 | Christian Grothoff | Status | new => confirmed |
| 2012-01-17 14:50 | LRN | Note Added: 0005267 | |
| 2012-01-17 15:17 | Christian Grothoff | Note Added: 0005268 | |
| 2012-01-17 15:32 | LRN | Note Added: 0005269 | |
| 2012-01-17 15:37 | Christian Grothoff | Note Added: 0005270 | |
| 2012-01-31 13:11 | Christian Grothoff | Assigned To | => Christian Grothoff |
| 2012-01-31 13:11 | Christian Grothoff | Status | confirmed => assigned |
| 2012-02-04 22:10 | Christian Grothoff | Note Added: 0005424 | |
| 2012-02-04 22:10 | Christian Grothoff | Status | assigned => resolved |
| 2012-02-04 22:10 | Christian Grothoff | Fixed in Version | => 0.9.2 |
| 2012-02-04 22:10 | Christian Grothoff | Resolution | open => fixed |
| 2012-02-28 11:06 | Christian Grothoff | Status | resolved => closed |
