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 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! > > 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
