GNOME Bugzilla – Bug 704316
Add support for eBooks
Last modified: 2014-12-01 14:04:23 UTC
For testing. I'm not sure that we want to show electronic books in gnome-documents though the UI would be very very similar.
Created attachment 249267 [details] [review] Add support for eBooks Load up EPub documents as well as other documents
Created attachment 249268 [details] ebooks screenshot This is what it looks like when filtering for eBooks in gnome-documents, with the gnome-epub-thumbnailer installed. Note that we cannot view the file though...
Looks great and I'd love to have a nice GNOME app to read books. However, after talking this over on IRC we think maybe a new app would be better. It would be slightly different from Documents: * Have no Edit * Have no Present * Different sync/device options * Access to a "store" * Possibly different read/view modes I guess the trick would be to reuse as much code as we can.
*** Bug 670684 has been marked as a duplicate of this bug. ***
*** Bug 692592 has been marked as a duplicate of this bug. ***
I think we should keep this in just one applications. Here are some the reasons for it. > * Have no Edit Today, Documents show PDF documents which sometimes, most times, can't be edited. So this should not be for using a different applications for books. > * Have no Present I can't see a reason for not wanting this for Books, might not be a primary use, but might be of use. > * Different sync/device options > * Access to a "store" These two are obviously only for a Books applications. > * Possibly different read/view modes But this one can be used as well in Documents. Now, my main point is about the Gnome Desktop Environment as a whole, would have two applications Books and Documents with almost the same purposes, read documents. Yes, Documents allow you to edit documents, but that's not is main use. When a user want to edit/make a documents most probably would reach to LibreOffice than Documents. Yes. Books allow to navigate and get content from a store, but it's main point is to read Books (which are documents by itself). It seems to me that Documents purposes somehow superseeds Books one. As a user I would find trouble thinking of two different applications when the only main difference between them is that Books allows me to navigate a *store* and get content from there. When were talking about the Gnome Deskto Also from the implementation stand-point the amount of code and infrastructure those two would have to share is huge. Not only the UI machinery, but the tracker integration, and some others.
Even I think a documents and a books application will be overkill. But at the same time I love the new books application designs that are proposed (two-page mode, bottom scroll-bar etc. are wonderful/must). Also what happened to the idea that gnome documents is a content browser which will show all the documents in the system (thus bypassing nautilus completely)? In any case, I guess ebooks support is a must for any modern desktops and it is high time we have proper ebook support.
(In reply to comment #6) > I think we should keep this in just one applications. Here are some the reasons > for it. > <snip> > > * Different sync/device options > > * Access to a "store" > These two are obviously only for a Books applications. > > > * Possibly different read/view modes > But this one can be used as well in Documents. > > Now, my main point is about the Gnome Desktop Environment as a whole, would > have two applications Books and Documents with almost the same purposes, read > documents. Why are books documents? The consumption model is very different, the presentation of the files is very different. Why does it make sense for (possibly hundreds or thousands) books to be mixed in with my electricity bill, or a spreadsheet of my accounts? > Yes, Documents allow you to edit documents, but that's not is main > use. When a user want to edit/make a documents most probably would reach to > LibreOffice than Documents. Yes. Books allow to navigate and get content from a > store, but it's main point is to read Books (which are documents by itself). It > seems to me that Documents purposes somehow superseeds Books one. > As a user I would find trouble thinking of two different applications when the > only main difference between them is that Books allows me to navigate a *store* > and get content from there. When were talking about the Gnome Deskto > > Also from the implementation stand-point the amount of code and infrastructure > those two would have to share is huge. Not only the UI machinery, but the > tracker integration, and some others. I don't think anyone discounted the fact that gnome-documents can be used as a basis for an ebooks app. Could even be in the same tree to make it easier to share code. But that's a technical decision, not a design one. (In reply to comment #7) > Even I think a documents and a books application will be overkill. But at the > same time I love the new books application designs that are proposed (two-page > mode, bottom scroll-bar etc. are wonderful/must). > > Also what happened to the idea that gnome documents is a content browser which > will show all the documents in the system (thus bypassing nautilus completely)? It doesn't show videos, it doesn't show music, it doesn't show photos. ebooks aren't the "documents" you want to see in gnome-documents... > In any case, I guess ebooks support is a must for any modern desktops and it is > high time we have proper ebook support. Agreed, which is why it's being discussed.
(In reply to comment #8) > Why are books documents? .... > Why does it make sense for (possibly hundreds or thousands) books to be mixed > in with my electricity bill, or a spreadsheet of my accounts? Why does gnome-documents think my pdf books are documents? My hundreds of (pdf) books are already mixed with real 'documents' in gnome-documents. How do you propose we split those? > (In reply to comment #7) > > Also what happened to the idea that gnome documents is a content browser which > > will show all the documents in the system (thus bypassing nautilus completely)? > > It doesn't show videos, it doesn't show music, it doesn't show photos. ebooks > aren't the "documents" you want to see in gnome-documents... This is also true for other formats. Say, an audio file could be a song or an audio book. Do we need (or if its even possible) to split audio books from songs? Again, how can we possibly split the documents from the 'books'? The file extensions do not tell the complete story.
(In reply to comment #9) > Again, how can we possibly split the documents from the 'books'? The file > extensions do not tell the complete story. Saw this bug report in GSOC ideas page.. A way that comes to my mind is by having multiple tabs --> Misc, Documents, Books (maybe more) and the user can label them as books or private docs or something else. We can store this in a local db like the thumbnails db is stored. any new document shows up in misc and the user can just label it accordingly as we do in emails. Using these labels we can also organize the files in folders for the user.
That is good idea to have Tabs to distinguish between Documents and book.We can do here is that if item is marked as Document we will remove from this book application and send it to Document application. As this application is intended to have only books. Moreover, i should have two buttons in top-center position as "finished" or "previously read" or any other suitable label for book which are finished reading.And second button as "new" or "ongoing"or any other label. Motto:generally,book are read once,twice,(or some finite no. if it's interesting to user).And documents are needed frequently.So,document are not actually needed the filter such as 'read' or 'unread'.But Books needs this kind of things,because we generally say that these are the books which i have read,or these books are pending to read it. Then more features than can be added:- 1.As mention above page layout-two page,flip pages animation effects 2.Display mode:-day/night mode.or brightness control 3.short comment can be added to each page.and this comment will be binded with file local db content 4.resuming to previous stop page by having ribbon. 5.share option:-this book can be shared with friends(via. attachment) Note:This additional features can not be added to Gnome-Documents,So,There is need of Gnome-Books. I think these feature will really impress the gnome user. Please review on this. And I would like to work on this idea for gsoc2014.
*** Bug 704589 has been marked as a duplicate of this bug. ***
Created attachment 284693 [details] [review] Add support for eBooks
Reopening. Here's a patch that does quite a bit of what's required for an e-Book reading application. Missing are: - a way to tag PDFs as being books (in gnome-documents) and not books (in gnome-books) - an ebook RDF type (bug 735460) - a better default mode for CBZ books (it's too zoomed in by default) - a view for ePubs (Marta's GSoC should help here) - an icon for the new application - maybe magazines support (would need a way to change the PDF type from within gnome-books and/or gnome-documents)
Created attachment 284752 [details] [review] Add support for eBooks Add a new application, "Books" (aka gnome-books) to the gnome-documents git repository. This application shares most of its code with Documents, and it supports: - Categorising e-Books vs. Comics - Searches - Preview of CBZ/CBR/etc. comic formats (supported through the libevince backend) XXX TODO before merging: - a way to tag PDFs as being books (in gnome-documents) and not books (in gnome-books) - a better default mode for CBZ books (it's too zoomed in by default) - a view for ePubs (Marta's GSoC should help here) - an icon for the new application - maybe magazines support (would need a way to change the PDF type from within gnome-books and/or gnome-documents) - Disable online accounts support for now? - Move gnome-epub-thumbnailer into gnome-documents? XXX Longer term TODO items (in Bugzilla once merged): - ComicBook metadata (see bug 735613) - More properties - Mobi/FB2 view support - Blacklist "open in archive manager" in context popup (epub and CBZ) - e-Book reader synchronisation (Kobo) - Remember state between sessions (page, zoom, read/unread) - Online accounts support?
Review of attachment 284752 [details] [review]: I have not tested this extensively, but I do like the general approach of this patch. Thanks, Bastien.
Comment on attachment 284752 [details] [review] Add support for eBooks Attachment 284752 [details] pushed as 17322bb - Add support for eBooks
(In reply to comment #15) > TODO before merging: > - a way to tag PDFs as being books (in gnome-documents) and not books > (in gnome-books) https://bugzilla.gnome.org/show_bug.cgi?id=740970 > - a better default mode for CBZ books (it's too zoomed in by default) That was fixed. > - a view for ePubs (Marta's GSoC should help here) https://bugzilla.gnome.org/show_bug.cgi?id=740971 > - an icon for the new application https://bugzilla.gnome.org/show_bug.cgi?id=740972 > - maybe magazines support (would need a way to change the PDF type from > within gnome-books and/or gnome-documents) https://bugzilla.gnome.org/show_bug.cgi?id=740973 > - Disable online accounts support for now? https://bugzilla.gnome.org/show_bug.cgi?id=740974 > - Move gnome-epub-thumbnailer into gnome-documents? https://bugzilla.gnome.org/show_bug.cgi?id=740975 > Longer term TODO items (in Bugzilla once merged): > - ComicBook metadata (see bug 735613) Already in tracker bugzilla. > - More properties https://bugzilla.gnome.org/show_bug.cgi?id=740976 > - Mobi/FB2 view support https://bugzilla.gnome.org/show_bug.cgi?id=740977 > - Blacklist "open in archive manager" in context popup (epub and CBZ) https://bugzilla.gnome.org/show_bug.cgi?id=740978 > - e-Book reader synchronisation (Kobo) https://bugzilla.gnome.org/show_bug.cgi?id=740979 > - Remember state between sessions (page, zoom, read/unread) https://bugzilla.gnome.org/show_bug.cgi?id=740980 > - Online accounts support? Punted. Marking bug as fixed, for now :)