After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 704316 - Add support for eBooks
Add support for eBooks
Status: RESOLVED FIXED
Product: gnome-documents
Classification: Core
Component: general
unspecified
Other All
: Normal normal
: ---
Assigned To: GNOME documents maintainer(s)
GNOME documents maintainer(s)
: 670684 704589 (view as bug list)
Depends on: 735460
Blocks: 692592
 
 
Reported: 2013-07-16 12:21 UTC by Bastien Nocera
Modified: 2014-12-01 14:04 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Add support for eBooks (1.50 KB, patch)
2013-07-16 12:21 UTC, Bastien Nocera
none Details | Review
ebooks screenshot (503.19 KB, image/png)
2013-07-16 12:23 UTC, Bastien Nocera
  Details
Add support for eBooks (20.22 KB, patch)
2014-08-28 12:39 UTC, Bastien Nocera
none Details | Review
Add support for eBooks (21.50 KB, patch)
2014-08-28 20:22 UTC, Bastien Nocera
committed Details | Review

Description Bastien Nocera 2013-07-16 12:21:52 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.
Comment 1 Bastien Nocera 2013-07-16 12:21:54 UTC
Created attachment 249267 [details] [review]
Add support for eBooks

Load up EPub documents as well as other documents
Comment 2 Bastien Nocera 2013-07-16 12:23:47 UTC
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...
Comment 3 William Jon McCann 2013-07-16 15:30:42 UTC
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.
Comment 4 Bastien Nocera 2013-07-16 15:46:41 UTC
*** Bug 670684 has been marked as a duplicate of this bug. ***
Comment 5 Bastien Nocera 2013-07-16 15:47:21 UTC
*** Bug 692592 has been marked as a duplicate of this bug. ***
Comment 6 Erick Perez Castellanos 2013-07-16 17:49:31 UTC
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.
Comment 7 Justin 2013-07-17 18:20:16 UTC
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.
Comment 8 Bastien Nocera 2013-07-18 09:00:28 UTC
(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.
Comment 9 Justin 2013-07-22 05:56:31 UTC
(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.
Comment 10 Ishaan 2014-03-08 05:48:41 UTC
(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.
Comment 11 prasad mhatre 2014-03-08 08:48:25 UTC
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.
Comment 12 Cosimo Cecchi 2014-03-16 03:07:51 UTC
*** Bug 704589 has been marked as a duplicate of this bug. ***
Comment 13 Bastien Nocera 2014-08-28 12:39:09 UTC
Created attachment 284693 [details] [review]
Add support for eBooks
Comment 14 Bastien Nocera 2014-08-28 12:44:46 UTC
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)
Comment 15 Bastien Nocera 2014-08-28 20:22:57 UTC
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?
Comment 16 Debarshi Ray 2014-09-09 14:43:08 UTC
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 17 Bastien Nocera 2014-12-01 13:27:29 UTC
Comment on attachment 284752 [details] [review]
Add support for eBooks

Attachment 284752 [details] pushed as 17322bb - Add support for eBooks
Comment 18 Bastien Nocera 2014-12-01 14:04:23 UTC
(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 :)