Hi, thank you for the feedback about this PR. I have gone through all the change requests and tried to implement them or leave a comment. Those, I'm not sure about, I left unresolved. I hope the changes suit you well.

I think I have implemented all requested changes. But now for some reason the clang format pipeline fails, and I can't figure out what is causing this.

Ah, if you rebase onto latest master, the clang-format check should be working properly (and hopefully validate this PR).

Then I'll squash and merge this!

Ok now clang-format is also passing, just had to add some more commits for formatting. Looks like my local formatter was not setup correctly.

Thank you for your reviews and suggestions on how to improve the code.

Just realized that after rebasing onto the current master branch, I cannot build the project anymore.

I get the following error:

I can solve this issue by adding #include <memory> to the TinyVector.h file, but this wasn't required before.

Could this issue be linked to the rebase?

Just realized that after rebasing onto the current master branch, I cannot build the project anymore.

I get the following error:

I can solve this issue by adding #include <memory> to the TinyVector.h file, but this wasn't required before.

Could this issue be linked to the rebase?

Interesting. The cppreference says that std::destroy and std::destroy_at are defined in the memory.h header. It seems to get included via the stdexcept header (included in TinyVector.h), that in turn includes the string header. Running g++ -E TinyVector.h > TinyVector.preprocessed I see in it:

# 41 "/usr/include/c++/12/string" 2 3
# 1 "/usr/include/c++/12/bits/allocator.h" 1 3
# 46 "/usr/include/c++/12/bits/allocator.h" 3
# 1 "/usr/include/x86_64-linux-gnu/c++/12/bits/c++allocator.h" 1 3
# 33 "/usr/include/x86_64-linux-gnu/c++/12/bits/c++allocator.h" 3
# 1 "/usr/include/c++/12/bits/new_allocator.h" 1 3
# 41 "/usr/include/c++/12/bits/new_allocator.h" 3

and the last listed file indeed includes a definition of destroy.

Similarly via

# 52 "/usr/include/c++/12/string" 2 3

# 1 "/usr/include/c++/12/bits/basic_string.h" 1 3
# 37 "/usr/include/c++/12/bits/basic_string.h" 3
       
# 38 "/usr/include/c++/12/bits/basic_string.h" 3

# 1 "/usr/include/c++/12/ext/alloc_traits.h" 1 3
# 32 "/usr/include/c++/12/ext/alloc_traits.h" 3
       
# 33 "/usr/include/c++/12/ext/alloc_traits.h" 3

# 1 "/usr/include/c++/12/bits/alloc_traits.h" 1 3
# 33 "/usr/include/c++/12/bits/alloc_traits.h" 3
# 1 "/usr/include/c++/12/bits/stl_construct.h" 1 3
# 73 "/usr/include/c++/12/bits/stl_construct.h" 3

we get a definition of destroy_at.

I think the root problem is that TinyVector.h implicilty depends on <memory>; the simplest fix is to insert #include <memory>. I would do this as a separate commit.

I think the root problem is that TinyVector.h implicilty depends on <memory>; the simplest fix is to insert #include <memory>. I would do this as a separate commit.

I just did that via #4743.
I also rebase this onto it (and squashed the commits together) so the pipeline can check is all works out.

Merging in 24 hours unless an obstruction is raised (or the pipeline complains).

⚠️ Please do not merge yet ! ⚠️

I have just tested all changes again and found several new issues.

• The selected style is not saved in the settings.xml correctly (because of the static_cast)
• "Magical constant" in SidebarPreviewPageEntry::getWidgetHeight()
• For some reason, the circle and the square background are drawn some pixel too high now
  
• Very low text contrast for the page numbers in Light Theme
  

I will try to push fixes for these issues asap, but merging the current state would be bad. Sorry about the inconvenience!

OK, now all the issues should be fixed. Sorry about the late intervention yesterday.

For some reason, I cannot reproduce the first issue with the truncated page numbers, neither with GDK_SCALE=2 nor without.
Does this appear all the time or only under certain circumstances? Which display resolution do you use?

For some reason, I cannot reproduce the first issue with the truncated page numbers, neither with GDK_SCALE=2 nor without. Does this appear all the time or only under certain circumstances? Which display resolution do you use?

It appears all the time. It seems to go away for the number of a given page if I change the page's size.

Do you mean changing the page zoom scaling or changing the paper format?

Do you mean changing the page zoom scaling or changing the paper format?

The paper format

So the second issue should be fixed now.

I still cannot reproduce the first issue. What display resolution are you using?

I have also reworked the third style now. Here is what it looks like now:

Light Theme	Dark Theme

I prefer this darker gray color over the previous one, but please let me know what you think.

Regarding the issue with the truncated page numbers. I think I found what was causing this. It was that the page preview widget were never properly resized to handle the additional number at the bottom. I have fixed this now.

But when the style is changed in the preferences, it does not immediately update the widget size. In that case, it can be that either the widget is displayed too large or the page number is truncated until the sidebar is redrawn and layouted the next time.

A solution would be to always layout the sidebar immediately after the preferences were saved.

I had a couple minutes to test this this morning. Most of the issues seen gone. The truncated page numbers seem fixed as well.

You are mentioning another minor issue though: I agree the layout should be updated whenever the setting is changed.

I'll try to have a look at the code later today.

The layout issue after changing styles in the preferences should be fixed now.

Thanks a lot for the hard work!
If that's ok with everyone, I'll be squashing and merging this in 72 hours (unless someone objects)