Bulk delete books from app library

[francium]

Is your feature request related to a problem? Please describe.

I have a number of books imported into the app, mainly because I wanted to (1) see how long the book was, (2) how well foliate renders it (foliate is really really good!), (3) wanted to browse the book briefly.

However, now I have a bunch of things in the library which I'm not actively reading. I would like to remove dozens of books from the app library.

Describe the solution you'd like While I can delete each book, this however, required moving my mouse, clicking, then clicking again. Repeating this dozens of times is tedious. Luckily I only have a few dozen (less than 50) books to remove, not hundreds.

It would be nice if there was a multiselect + delete selected option.

Describe alternatives you've considered Delete each book one at a time.

Looked at the app's underlying data directory, and while I imagine I can delete things manually from there, it would be possible to delete too much or too little and leaving the app possibly broken or orphaned files behind.

I could also maybe just delete the whole app data directory and add back the books I want.

Additional context I haven't looked at the codebase, but technically I could help contribute this feature. But it seems like a non-trivial feature to add, since it would involve introducing a new UI workflow (multi selection). Not sure if it would be a trivial thing for an existing contributor who's already familiar with the codebase or a new contributor can add such a feature without too much effort.

[johnfactotum]

I have a number of books imported into the app, mainly because I wanted to (1) see how long the book was, (2) how well foliate renders it (foliate is really really good!), (3) wanted to browse the book briefly.

See also #471.

I haven't looked at the codebase, but technically I could help contribute this feature. But it seems like a non-trivial feature to add, since it would involve introducing a new UI workflow (multi selection). Not sure if it would be a trivial thing for an existing contributor who's already familiar with the codebase or a new contributor can add such a feature without too much effort.

Firstly I think the objects in the list model needs to have some kind of selection-enabled property, so that it can show checkboxes only when selection mode is on. Here the slightly non trivial part is that currently the model contains GFile objects. So either have to extend the class (not sure if that's possible), or need to create a new a new class.

I'm not sure how to best handle selection, though. It could either use a JavaScript Set (which it used to use in v2.x) or it could use GtkMultiSelection. Or add a selected property on the objects in the list model.

Next one has to add event controllers to the row/item widgets, to make right clicking and long tapping trigger selection mode. Then, when in selection mode, the activate should toggle the selection.

---

Another alternative would be to switch to using Tracker to populate the library. Then it would only show books that are tracked by Tracker (see also #730). Doing that would also fix #582.

[crimsonfall]

I have also briefly mentioned this issue too in #1196, but in addition, I mentioned bulk adding books as well.

[francium]

See also https://github.com/johnfactotum/foliate/issues/471 (Ephemeral mode)

I first thought such a mode would be kind of going against the current overall UX of the app -- where it stores data about what you are reading, have read, etc, without being a complete book management system. But I suppose such a mode is similar to browser's private/incognito mode. Maybe you can make a in memory filesystem or something of that nature to store data, then that data is discarded when the app is closed? I see that you raised that issue, so ultimately it's your call as the creator in terms of where you want to take the project, but to me it seems like an odd thing given how the app currently works.

Maybe a "factory reset" or "delete all history" or similar option would serve the purpose -- it wouldn't make it 100% bulletproof in the sense data would still be written to disk technically only to be "deleted" (files aren't actually deleted when you delete them) later.

Another alternative would be to switch to using Tracker to populate the library. Then it would only show books that are tracked by Tracker (see also https://github.com/johnfactotum/foliate/issues/730). Doing that would also fix https://github.com/johnfactotum/foliate/issues/582.

I think Tracker is enabled by default? I personally never use it and always disable it after a new install. Any how, my files are on a network file system that I samba/sshfs/nfs mount, so I don't think Tracker would even detect them anyway -- nor would I want it indexing that network filesystem. So it wouldn't be safe to assume everyone is reading files only on their local filesystem -- this is actually a great feature of Foliate currently, my network filesystem books just work perfectly in the app.

[johnfactotum]

I first thought such a mode would be kind of going against the current overall UX of the app -- where it stores data about what you are reading, have read, etc, without being a complete book management system. But I suppose such a mode is similar to browser's private/incognito mode.

Not sure how it would fit in terms of the UX. But it's definitely a use case that I'd like to consider. Personally I've been using the online demo reader lately to open some books that I'm not really reading but more like previewing. Can perhaps add an "Open as Preview…" option where it would open the book without saving any data. A sort of workaround for now is that instead of closing the app, after viewing the book one could navigate to the Library view and delete the book. So maybe there could be a sort of "Forget This Book" option in the Book Menu (on the sidebar).

I think Tracker is enabled by default? I personally never use it and always disable it after a new install. Any how, my files are on a network file system that I samba/sshfs/nfs mount, so I don't think Tracker would even detect them anyway -- nor would I want it indexing that network filesystem.

I don't think there's any technical reason why it can't index files over the network. It probably can. Anyway, there are a few different ways how Tracker could be integrated:

• Currently it only uses Tracker to get the file's URI.
• It could show books from Tracker in addition to the books known by Foliate.
• It could be used to do housekeeping, i.e. a sort of "remove books not indexed by Tracker" action.
• It could (possibly optionally) show only books indexed by Tracker (but still save data for books that aren't indexed).
• It could save data only for books that are indexed.

[francium]

I don't think there's any technical reason why it can't index files over the network

My, and likely others, network storage is in the hundreds-of-GBs/multiple-TBs, so I'd definitely want to avoid Tracker trying to crawl all of that and potentially cause other issues.

Re: UX for previewing, what about some kind of option to switch the app when it starts and then having two separate .desktop files, one is regular Foliate and other could be a Foliate Preview. I don't know if that simplifies anything from a coding perspective, but it offers the user two "separate" apps they can choose between when opening an .epub/other ebook file.

I just checked Calibre, it provides the following separate "applications" (at least on my distro),

usr/share/applications/calibre-ebook-edit.desktop usr/share/applications/calibre-ebook-viewer.desktop usr/share/applications/calibre-gui.desktop usr/share/applications/calibre-lrfviewer.desktop

Anyway, I feel like discussing this previewing feature is off topic for this issue and best left for #471

[johnfactotum]

I don't think there's any technical reason why it can't index files over the network

My, and likely others, network storage is in the hundreds-of-GBs/multiple-TBs, so I'd definitely want to avoid Tracker trying to crawl all of that and potentially cause other issues.

Yes, and that applies to local files as well. I meant that (I think) Tracker is designed so that it could work with any filesystem, even online ones.

Re: UX for previewing, what about some kind of option to switch the app when it starts and then having two separate .desktop files, one is regular Foliate and other could be a Foliate Preview. I don't know if that simplifies anything from a coding perspective, but it offers the user two "separate" apps they can choose between when opening an .epub/other ebook file.

There would be a command line argument. A separate desktop entry could work, though it should probably have NoDisplay=true.