[Feature Request] Divide built-in booklist styles and custom ones apart

[CloneWith]

Seemingly built-in booklist styles use one "Default" setting, and each custom rule use individual settings. If we split them into two sections, built-in and custom, the list should be more organized, since each style only uses two lines. and users then would be less confused about questions like "I changed the sorting setting in Settings, why the booklist stayed the same".

[tfonteyn]

They way it's designed (for now) is that built-in styles

• use a common set of defaults for their basic settings
• differ mainly/only in the groups (fields) they use to build the book-list hierarchical view.
• can be used directly, or as a template for creating a custom style

Custom styles (UserStyle class) are initially a copy of a built-in style, but once created, they have no link to the original built-in style, and hence no link to the common settings.

I did think of using an inheritance system so that custom style options would basically have a "use default"; for example: the "List/Grid" option would be "List/Grid/use-default". So far I've not had the time to tackle this but I agree it would be nice to have this and sometime I will implement this.

As to you question on splitting the list: not sure where exactly you mean ? In the side-menu "Booklist styles" or in the style picker dialog?

[CloneWith]

As to you question on splitting the list: not sure where exactly you mean?

This might be a little too abstract 😅 Explaining below:

• Custom
  • Style 1
  • Style 2
• Built-in
  • Author
  • Style
  • ...

The Custom and Built-in list items refer to headers or groups.

It would be better to divide all styles like this. Then when there are two styles with a same name, one is built-in and the other custom (especially when duplicating), it's easier to tell them apart. When I tested sorting styles earlier this confused me, since I didn't notice I'm using a custom rule, and I felt there must be something wrong with the database, until I realized my stupid mistake 😵

[tfonteyn]

I rather spend time on implementing the hierarchical "use-default" for the options.

But maybe I can improve the style list by better distinguishing built-in style names from custom ones. I'll need to think about this.

[tfonteyn]

better distinguishing built-in style names from custom ones.

I've added a visual reminder () to builtin styles with a note "( default style)" in the styles picker. It'll be in the next release.

Closing this issue now, but the

hierarchical "use-default" for the options.

is still on my todo list