Feature request: display file sizes in content server details screen
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| | calibre |
Undecided
|
Unassigned | ||
Bug Description
As described. When viewing the content server in the browser, and browsing to the details page of any book item, there are Read and Download buttons (as well as Read and Download options after clicking on individual "Formats:" links) but nowhere does it indicate the size of that format. This information can be vitally important for a variety of reasons, ranging from slow or capped network connections, to devices with very limited storage. Being able to immediately see the filesizes somewhere in this details screen before would be immensely helpful.
(Example scenario: I have a full older tablet, and a 2GB high-definition graphical ebook refused to download properly because the target device's storage was too limited and I did not realise the file was so large ahead of choosing to download it.)
| Daniël Bonomo (dgbonomo) wrote : | #2 |
I have an alternative suggestion, based on my previous feature request (for displaying book titles in a hover box by setting a title attribute on the item div).
The "Read" and "Download" buttons as well as the links in "Formats: ..." already have a mostly redundant title attribute that explains what these buttons/links do (ie "Download this book in the PDF format"). Perhaps the size information can be added in the title attribute (in a short human-readable format)? That way the information is more easily accessible, and it doesn't clutter the rest of the UI.
| Kovid Goyal (kovid) wrote : | #3 |
Certainly, that takes care of the UI space objection. However, I am
still reluctant to do this. Implementing it means either:
1) Making N extra filesystem accesses per book when loading the book
list
2) Loading the file sizes asynchronously when the details page is
displayed
(1) is a big performance hit (the book list is typically populated
directly from RAM) for an somewhat obscure use case.
(2) is a fair bit of work to implement
I wont refuse a patch implementing (2), however.
| Kovid Goyal (kovid) wrote : | #4 |
Actually, on second thoughts, this can be done with no extra filesystem
accesses.
| Kovid Goyal (kovid) wrote : Fixed in master | #5 |
Fixed in branch master. The fix will be in the next release. calibre is usually released every alternate Friday.
status fixreleased
| Changed in calibre: | |
| status: | Won't Fix → Fix Released |
Doesn't your browser tell you the size of a file being downloaded?
I'm afraid that the use case of downloading very large ebooks onto full
devices is not common enough IMO to devote space for it in the UI.
status wontfix