[GUI Plugin] Reading Goal

[thiago.eec]

Thanks for the report. I just fixed it. I'll release the fix in a few minutes.

[thiago.eec]

Version 1.6.2 - 19 Aug 2024

- Bug fix: when marking books, it would not work if the genre had more than one level

[sandrilea]

Great

I am delighted that you can have more than one genre level. Is it supposed to work with three levels? When I tried it, there was just the word for the subgenre with the number zero in parenthesis in genre view and the book with this genre won't show up.

When I sort by title in genre view the subgenres are sorted as titles. Example: I have the genre Fantasy at the top, then titles A-T, then the subgenre Urban Fantasy, then titles V-Z in Fantasy. It would be nice to have all the titles for Fantasy together and then the titles for the subgenre.

[thiago.eec]

Originally Posted by sandrilea

I am delighted that you can have more than one genre level. Is it supposed to work with three levels?

Yes, up to three levels.

Originally Posted by sandrilea

When I tried it, there was just the word for the subgenre with the number zero in parenthesis in genre view and the book with this genre won't show up.

When you have more than 3 levels, the remaining levels are grouped with the third level. Something like this:



The complete tag is 'Ficção.Ação e aventura.Teste.Quarto nível'.
If this is not the case for you, send me your database file (json), so I can take a look and figure out what's going on.

Originally Posted by sandrilea

When I sort by title in genre view the subgenres are sorted as titles. Example: I have the genre Fantasy at the top, then titles A-T, then the subgenre Urban Fantasy, then titles V-Z in Fantasy. It would be nice to have all the titles for Fantasy together and then the titles for the subgenre.

If they have exactly the same tag, with the same hierarchy, they should definitely be together. If you could pm me your database file, it would be easier for me to find the problem.

EDIT: Check out the new version released. I think it fixes all your problems.

[thiago.eec]

Version 1.6.3 - 20 Aug 2024

- Bug fix: use a case sensitive match for genres, since that's how calibre's tags work
- Bug fix: check the subgenre's parent before assigning a book to it, so we can differentiate repeated names

[chaley]

Originally Posted by thiago.eec

Version 1.6.3 - 20 Aug 2024

- Bug fix: use a case sensitive match for genres, since that's how calibre's tags work

Where does calibre do case sensitive matching for tags, either custom or standard? It shouldn't. AFAIK one cannot have two tags in a library that differ only in case. For example, given

s = some_string.lower()
for t in tags:
    if s == t.lower():
        print('foo')

it should be impossible to print more than one line.

Another example:

set1 = db.all_tags() #made up function
set2 = set()
for t in set1:
    set2.add(t.lower())

len(set1) will always equal len(set2)

[thiago.eec]

Originally Posted by chaley

AFAIK one cannot have two tags in a library that differ only in case.

Actually you can (standard 'tags' field, hierarchy active):



I used the word 'match', like it was a search in calibre. I was actually referring to the Tag Browser. 'Some Tag' and 'Some tag' are displayed separately in there.

EDIT: After further testing, it looks like only the intermediate levels of hierarchical tags are case sensitive. The image above illustrates such a case: 'Tema.Seres fantásticos.Dragões'.

[chaley]

Originally Posted by thiago.eec

Actually you can (standard 'tags' field, hierarchy active):



I used the word 'match', like it was a search in calibre. I was actually referring to the Tag Browser. 'Some Tag' and 'Some tag' are displayed separately in there.

I see.

The example happens because the real "tag" is composed of all pieces of the hierarchical item. Individual bits, in this case "Seres Fantàsticos", are not real tags and don't exist in the database. For example, you can have "Seres Fantàsticos.AAA" and "Seres fantàsticos.BBB" because the tag differs in content. However, you can't have "Seres Fantàsticos.AAA" and "Seres fantàsticos.AAA" because in this case the tag differs only in case. Nor can you have "Seres Fantàsticos.AAA" and "Seres Fantàsticos.aaa". One of the two will win and be in the db. Bottom line: you can't compare individual items in a hierarchy to see if they are the same tag. You can only compare the entire tag.

It is very possible that none of this matters for what you are doing.

[thiago.eec]

Originally Posted by thiago.eec

EDIT: After further testing, it looks like only the intermediate levels of hierarchical tags are case sensitive. The image above illustrates such a case: 'Tema.Seres fantásticos.Dragões'.

Yes. That's about the same of what I found out.

Originally Posted by chaley

It is very possible that none of this matters for what you are doing.

The plugin parses the tag, breaking it down into pieces. Then, it uses those pieces to create a QTreeWidget, following the original hierarchy. Right now it mimics the tag browser behaviour, treating 'Seres fantásticos' and 'Seres Fantásticos' as different tags. Maybe I should treat them as one.

The most important fix was checking the parents to avoid messing up when the user have the same string used repeatedly in different places.

[ownedbycats]

Originally Posted by chaley

I see.

The example happens because the real "tag" is composed of all pieces of the hierarchical item. Individual bits, in this case "Seres Fantàsticos", are not real tags and don't exist in the database. For example, you can have "Seres Fantàsticos.AAA" and "Seres fantàsticos.BBB" because the tag differs in content. However, you can't have "Seres Fantàsticos.AAA" and "Seres fantàsticos.AAA" because in this case the tag differs only in case. Nor can you have "Seres Fantàsticos.AAA" and "Seres Fantàsticos.aaa". One of the two will win and be in the db. Bottom line: you can't compare individual items in a hierarchy to see if they are the same tag. You can only compare the entire tag.

It is very possible that none of this matters for what you are doing.

I've had this happen before -- I think I reported a slight bug involving list_union that could result in tag browser misbehaviour.