In D24141#539524, @woltherav wrote:

I double checked, and if I remove pages from a file the filesize goes down, so it must be deleting properly :)

I double checked, and if I remove pages from a file the filesize goes down, so it must be deleting properly :)

In D24141#536284, @woltherav wrote:

In D24141#536115, @leinir wrote:

Looks pretty good, but i'm not entirely certain... we might need to do some housekeeping in the zip file when removing pages, to ensure we don't leave graphics files behind that aren't referenced somewhere (cbzs are already large enough without stray files sitting around inside the archive)... but that seems perhaps like something that'd want to be in the save part of the process, maybe

I thought we were already completely rewriting the zip file in question? If not I'll take a look at ensuring only files that the bookmodel knows about are in the zip file.

In D24141#536115, @leinir wrote:

Looks pretty good, but i'm not entirely certain... we might need to do some housekeeping in the zip file when removing pages, to ensure we don't leave graphics files behind that aren't referenced somewhere (cbzs are already large enough without stray files sitting around inside the archive)... but that seems perhaps like something that'd want to be in the save part of the process, maybe

Looks pretty good, but i'm not entirely certain... we might need to do some housekeeping in the zip file when removing pages, to ensure we don't leave graphics files behind that aren't referenced somewhere (cbzs are already large enough without stray files sitting around inside the archive)... but that seems perhaps like something that'd want to be in the save part of the process, maybe

Looks good from here - unless @pino has further to add, go for it :)

Added fixes @pino requested. I hope I did the desktop file one correctly.

Also, please append the %f placeholder to the command in the Exec of the two .desktop files: this way, it will be possible to select peruse (and perusecreator) as application for opening the comics.

bindValue is a good choice, yes, thank you ;) Go for it :)

Making use of bindvalue when possible, this'll avoid drama with quotes.

In D15766#333186, @woltherav wrote:

I was thniking in terms of 'putting seriesNumbers and Volumes next to the series entry', and such. But I'll push this after my daily walk :)

I was thniking in terms of 'putting seriesNumbers and Volumes next to the series entry', and such. But I'll push this after my daily walk :)

Not entirely sure how we would really make the database any nicer.. don't particularly want to add more tables, though i guess that might be what we'd end up doing (in essence, a new table for everything that's currently a csv list). If you feel like doing it, though, do go ahead :)

ack forgot to close this one O_O

Good stuff, let's roll with this one :)

This changes to QFileInfo::exists(filename), because the docs say that is a little faster.

hm... will have to chase down an sd card reader first :D

In D15748#331640, @woltherav wrote:

Well, the thing is, I have a large collection(sqlitebrowser counts about 586 entries right now), yes, but I also have a fairly beefy computer. Starting peruse with clear-db takes way longer than this(which is near instantaneous), but because I have a beefy computer I suspect it might be the debug messages that is the major cause of the slowdown with clear-db. Either someone with a slow harddrive should check this, or I'll drop the patch and wait for one that is theoretically speedier.

Well, the thing is, I have a large collection(sqlitebrowser counts about 586 entries right now), yes, but I also have a fairly beefy computer. Starting peruse with clear-db takes way longer than this(which is near instantaneous), but because I have a beefy computer I suspect it might be the debug messages that is the major cause of the slowdown with clear-db. Either someone with a slow harddrive should check this, or I'll drop the patch and wait for one that is theoretically speedier.

The reason i didn't do this before is that it does file system access, which is precisely what the cache is supposed to try to avoid... You've got a large collection, right? What sort of impact does this have on load time? (baloo shouldn't matter in this case, but it's good to test with that turned off anyway...)

Similarly unsure whether we can reasonably make it appreciably cleaner... let's roll with it :)

In D15713#331048, @woltherav wrote:

In D15713#330966, @leinir wrote:

Great stuff, push away! :)

No showstopper or anything, just for a bit of background: The reason behind caching everything is that file system access is super expensive, so causing file system access for cached entries seems perhaps less than good. To test whether this is sufficiently fast for you, turn off your file indexer (balooctl stop should do that nicely). If it is, indeed, fast enough, then go for it, otherwise caching will want to happen for those parts as well... We need some way to update the cache when the filesystem has changed, but i'm as yet unsure of how to properly deal with that... However, that doesn't have to stop the patch going in, just something to check :)

Weirdly enough, on my system, if a file has not been indexed by baloo, Peruse just doesn't see it.

In D15713#330966, @leinir wrote:

Great stuff, push away! :)

No showstopper or anything, just for a bit of background: The reason behind caching everything is that file system access is super expensive, so causing file system access for cached entries seems perhaps less than good. To test whether this is sufficiently fast for you, turn off your file indexer (balooctl stop should do that nicely). If it is, indeed, fast enough, then go for it, otherwise caching will want to happen for those parts as well... We need some way to update the cache when the filesystem has changed, but i'm as yet unsure of how to properly deal with that... However, that doesn't have to stop the patch going in, just something to check :)

Great stuff, push away! :)

In D15692#330285, @woltherav wrote:

In D15692#330282, @pino wrote:

Not sure I understand, what is the exact workflow that involves writing a .pot file, and reading .po files? Is it because peruse so far is not translatable?
If so, then it'd be much better to extract the messages, and make sure to use ki18n to translate the strings at runtime, just like all the other applications.

Ah, no, what this is for is something else. You see, Peruse Creator makes cbz(comic book) files, and also generates metadata files for cbz, this is done in the ACBF format. The ACBF format supports metadata for text within the comic and holding translations for said text. I figured that it'd be helpful to be able to take these translatable entries, and generate POT files for them (as well as import of translation po files). That way people who'd want to translate a comic can use their favourite pot/po compatible translation tools.

In D15692#330282, @pino wrote:

Not sure I understand, what is the exact workflow that involves writing a .pot file, and reading .po files? Is it because peruse so far is not translatable?
If so, then it'd be much better to extract the messages, and make sure to use ki18n to translate the strings at runtime, just like all the other applications.

Not sure I understand, what is the exact workflow that involves writing a .pot file, and reading .po files? Is it because peruse so far is not translatable?
If so, then it'd be much better to extract the messages, and make sure to use ki18n to translate the strings at runtime, just like all the other applications.

Updating with...

Niiiiice... Really neat stuff, thank you! Sure, i'll do a bit of hooking up with keys and whatnot :)

Hmm... i have no comments to make, this is good stuff! Fire away :)

Okay, added the commit where I did the last change (labels for volumes and numbers in sequences), and the commit where I added the last thing we discussed :)

In D15542#327982, @woltherav wrote:

I actually did manage to get the swap working just now, I replaced the counts with stringlists with the points of the frames(which should be useful for debug as well :) )

I actually did manage to get the swap working just now, I replaced the counts with stringlists with the points of the frames(which should be useful for debug as well :) )

In D15542#327620, @woltherav wrote:

Okay, updated with the changed you suggested. (And all my own changes I thought were really necessary.)

I forgot to save a file.

Okay, updated with the changed you suggested. (And all my own changes I thought were really necessary.)

In D15542#327446, @woltherav wrote:

It also needs a property registery? But I can't for the life of me figure out how to set that up, when I copy qmlplugin to the acbf folder it complains it cannot find the qmlengine type despite including QtQml/QQmlEngine. I am giving up on this now.

Frame/Textarea/Jump swap seems broken because I build up those repeaters from the count of those values, but if the count stays the same, the repeater has no need to change, so they effectively don't update.

Yes, I've got it sort of working. But I am wondering whether the method used for 'author' isn't easier(count of objects, count notified, add/remove entries, getentry). It is what I've used for the other metadata.

Okay, I've managed to get all the entries in the metadata section editable from peruse creator, meaning that part is done. This is pushed in a branch.

Hmm... this is const because the getter is const... going by what the example suggest, implementing a QQmlListProperty requires the getter not to be const, which of course seems weird for a READ function, but that is what it expects, so... yeah, try that?

Hmm! Yes, that's a good idea, hadn't really thought of that :)

Hmm... Yeah, that sounds like a pretty good idea, really... let's do it :)