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 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?
> 
> > 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
> > CHK at .../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
> > CHK at .../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...
> 
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20090609/056eb7e7/attachment.pgp>

Reply via email to