[GUI Plugin] Last Modified

[chaley]

Originally Posted by ownedbycats

Just curious: Could Last Modified also populate a column with which column was last modified? I'm not sure how this would work for editing multiple fields in the dialog rather than using the book list though.

One way to do that would be to use a tags-like column of items with identifier syntax. Something like "col1:date, col2:date, ...". Updating a column would add/replace the item. You would end up with a list of columns with the last mod time of each.

I have no idea if something like that fits into the architecture of this plugin. Also, the fact that datetime values have colons in them might create interesting problems.

[capink]

The plugin current design does not allow for this. Maybe I will revisit this sometime in the future, taking into account chaley's suggestion.

[capink]

Changes for the upcoming PyQt6.

[ownedbycats]

PSA: If you exclude a series-like column, you'll also want to exclude the #serieslike_index.

[bilbags]

Installed the plugin, restarted, and when I go to configure it, I cannot do anything in the Date Column. There is a drop-down arrow at the end of it, which does nothing. Not sure what I am doing wrong!

I'm running the latest version of Calibre.

[BetterRed]

Originally Posted by bilbags

Installed the plugin, restarted, and when I go to configure it, I cannot do anything in the Date Column. There is a drop-down arrow at the end of it, which does nothing. Not sure what I am doing wrong!

I'm running the latest version of Calibre.

You need to add a Date custom column e.g.



Which isn't obvious from the instructions in the first post.

BR

[bilbags]

Originally Posted by BetterRed

You need to add a Date custom column e.g.

Attachment 193274

Which isn't obvious from the instructions in the first post.

BR

Thank you so much, BetterRed! I assumed I needed some sort of custom column, but couldn't figure it out. Got it working now, thanks to you!

[capink]

Originally Posted by BetterRed

You need to add a Date custom column e.g.

Attachment 193274

Which isn't obvious from the instructions in the first post.

BR

Note added to the first post.

[capink]

Version 0.8.4

• Update: update to calibre6 icon themes. Code borrowed from @JimmXinu.

[Comfy.n]

Hi @capink,

Thanks for this awesome plugin.

Whenever I apply changes to existing custom columns in Calibre - even minor modifications like "Column Heading" -, my custom Last Modified date, for all books, gets reset to the timestamp of this change.

Is there a way to prevent this?

[Comfy.n]

When I installed this, my goal was to have it update a timestamp for a yes/no column, which adds a title to 'Favorites', adding a star icon as emblem in cover grid. So I have #favdate.

A while later I've tried to settle down with a #m = Last modified column which gets updated in any event listed on the PI checkboxes, but I wasn't expecting the above issue. Maybe it's just a matter of adding some exception, but I can't figure out how...

[capink]

Originally Posted by Comfy.n

Hi @capink,

Thanks for this awesome plugin.

Whenever I apply changes to existing custom columns in Calibre - even minor modifications like "Column Heading" -, my custom Last Modified date, for all books, gets reset to the timestamp of this change.

Is there a way to prevent this?

I tried doing this on my system and it did not change anything. Maybe different calibre versions leading to different results.

Anyway, here is what I think is happening: When you change a column heading calibre will change it's own "last_modified" date field for all books to update the cache for composite columns, which will trigger the "Last Modified" plugin to change the custom column date for all books.

Try excluding "last_modified" in the plugin options, and see whether this makes a difference. If this turns out to be the culprit, I will modify the plugin to automatically exclude last_modified.

Strange that it took so long for this bug to surface. Either the plugin or the "update on all columns" option are not extensively used. I only use myself with the include/exclude options.

Edit: A new version is released to fix this bug. Should be available in Calibre in an hour or so, or alternatively can be downloaded from the first post and installed manually.

[Comfy.n]

Hi @capink, thank you for looking but I think I had a little PEBKAC, though. I hope I can clarify what happened:

Even though I had appreciated BetterRed column-heading naming approach (Last Action), as it avoids confusion and is perhaps more accurate semantically, I chose to insist on the 'modified' nomenclature.

The reason for this insistence was that I had decided to forget completely the built-in Modified (last_modified) column, by hiding it for good in the book list, and replacing it with an almost identical column from this plugin: #m = Last Modified.

However, probably due to my constantly alternating book list layouts with the View Manager Plugin, I realise that at some point I was actually sorting by the built-in column Modified, instead of Last Modified, lol. So the timestamp reset I was seeing upon customising custom columns was NOT being originated by the plugin.

Also, when I tried to add the built-in 'Modified' to the plugin exceptions, I was using the incorrect lookup name "modified" instead of "last_modified". What a mess on my part, sorry!

Anyway, in order to prevent any further mistakes, I changed the headings and lookup name for this PI column. This is what I had before:


Now I have:


I should note that I've just tested v0.84 against v0.85 and I can confirm that, at least with the plugin settings as shown below, there occurs no timestamp reset, as I wrongly assumed.

[capink]

No problem. Your report uncovered a bug in the plugin, even if it did not affect you. The main point of the plugin is to circumvent the builtin last_modified, so it has to exclude it to make sure any changes to columns or templates, which might update the builtin last_modified, does not trigger the plugin.

I only use the plugin with exclude/include columns so that would not have happened to me, and when doing the initial testing for the plugin it never occurred to check for this. I was not able to replicate this by renaming columns , which is what I assume you meant by changing column headers. However, I'm sure there are scenarios where it could happen.

[Wiggo]

Originally Posted by capink

Edit: A new version is released to fix this bug. Should be available in Calibre in an hour or so, or alternatively can be downloaded from the first post and installed manually.

It could also be a weird coincidence, but since this update Calibre is a lot faster for me (search, metadata update) - really a lot