On Tuesday 09 June 2009 16:29:37 Matthew Toseland wrote: > On Tuesday 09 June 2009 12:51:09 xor wrote: > > On Wednesday 03 June 2009 23:47:49 Matthew Toseland wrote: > > > Bug 3040 suggests getting rid of the Key column and linking to the key > > > from the filename column. We link to the key from the identifier column > > > already but it isn't shown in simple mode. I am not sure I agree with > > > p0s's logic: > > > > > > The purpose of the filename column is to show *where the file is being > > > downloaded to*. Downloads to temporary space don't have one, although > > > they are unusual. Sometimes the filename will be a full, absolute path, > > > usually it will be downloads/blah. > > > > > > So out of filename, identifier, and key, which do we keep in simple > > > mode? IMHO it makes more sense to keep the key than the identifier. We > > > can make the key slightly more user friendly by decoding spaces and > > > foreign characters in the visible version, and we already truncate the > > > crypto stuff. > > > > The problem is not only that the Key column is redundant, it is also that > > it *does not fit on 1280x1024 for medium length filenames (freEbooks with > > Author - Date - Title for example)* which is already a rather high > > resolution. > > I really hope aforesaid books are legally redistributible ... We have a > policy of not providing tech support to known pirates ...
I said "FREEbooks". Such as www.gutenberg.org > > > I would suggest to instead of removing it rename the key column to > > "Download link" and have the CONTENT of the column be always a link to > > the key named "Link" instead of a text which relates to the actual fie. > > For multiple reasons: > > > > 0. "Download link" is easier to understand than "Key". > > > > 1. It does not matter what the link looks like in plain text, the user > > just wants to copy-paste it usually, so you do not need to show it in the > > column. > > > > 2. Showing an abbreviated link is confusing, the user might copy the name > > of the link instead of its destination. > > > > 3. When showing an abbreviated link, we will always abbreviate it to only > > display the key type and the file name. But the filename is already > > displayed in the file name column so its redundant! > > Unless it is a download to temporary space, in which case we have NO useful > information about which file it is that is being downloaded! We could > perhaps include the > > We could change "Key" to "Download link", but "key" is pretty universal, > e.g. what should we say on the bulk downloads form or the fetch a freesite > form? How about "Freenet address" instead of "Key"? I think thats a good compromise. And please change the content of the column from "c...@.../filename" to "Link". > > > > For completed downloads, we could reasonably link to the file on disk > > > in one of the columns. We also need to provide the link in case > > > somebody else wants the file, and some way to fetch it through the node > > > without going to disk. The last and the first could be the same, if we > > > check the downloaded files before returning a DNF. So: > > > > > > Remove > > > > > > Key > > > c...@.../somefile.txt > > > [ link can be copied, but also if clicked on it will return the data ] > > > > > > Size > > > 5.5MB > > > > > > Type > > > Plain text > > > [ we will have a lookup table for common mime types to be translated > > > into human readable strings ] > > > > > > Location on disk > > > downloads [ just the directory name to save space, but the link has the > > > full name ] [ links to a file:/// URL ] > > > > > > Persistence > > > forever > > > [ tooltip: The download will not be removed unless you click Remove; > > > the other version is that it will be removed on restart ] > > > > > > For downloads in progress: > > > > > > Remove > > > > > > Key > > > c...@.../somefile.txt > > > > > > Progress > > > 54% > > > > > > Size > > > 5.5MB > > > > > > Type > > > Plain text > > > > > > Location on disk [ tooltip: this is where the data will be stored when > > > the download is complete ] downloads > > > > > > Thoughts??? Another option would be to handle downloads to temporary > > > space in some other way, accepting that they are quite rare, and it is > > > okay for them to be ugly...
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
