Move custom drawing of splitter handle into the style where it belongs.
This means all splitters now use the custom handle without needing to
sprinkle a special class everywhere.
Note that this only works when using the calibre style not the system
one. This is by design, since we do not want to override drawing of
"system" components.
- Improve rendering of splitter handle using fewer, closer spaced,
circular dots
- Fix book details splitter not being rendered correctly on first start
when there is no saved state to restore
- Remove geometry save/restore of splitter as this is handled by
restore_state
- Remove call to setChildrenCollapsible before any children were added,
causing Qt to print an error to stderr
Fixes#1994065 [Enhancement Request: Details pane: Splitter between cover and details](https://bugs.launchpad.net/calibre/+bug/1994065)
This is a rather invoved PR. I first looked at putting a splitter in book details, and decided to in the process fix something that has bothered me for years. On Windows in light mode I can't see the splitter handles. In dark mode I can, but I run in light mode and don't want to change. This PR adds a custom QSplitterHandle class that draws the handle depending on the palatte.
The PR includes changes for the splitters in classes I know how to test: the main UI, Pinned columns, QuickView, Edit metadata, tweak books, single download metadata, Check library, Book info, and (of course) Book details.
Also indicate when the debugger is waiting for the 'Go' button. This fixes problems when people don't notice they have checked the Enable breakpoints box.
The major change is using a new class SearchToolBar to mimic a ToolBar. This lets the BarsManager treat the SearchToolBar as a "normal" toolbar. This fixed the two problems reported in this bug report.
In addition I fixed:
- "Mark Books" to install its event listener on SearchToolBar buttons.
- SavedSearchs to find SearchToolBar buttons when using keyboard shortcuts.
- Prevent the location manager and the donate action from being added to the SearchToolBar.
The buttons on the search bar dont behave like they do in the toolbars.
Clicking on a button with a menu pops up the menu but does not perform
the action. And right clicking on them has no effect. This will be
confusing and a source of bug report noise. So maybe if the action has a
menu, have it open on right click only, depending on popup_type in the
action definition.
This problem arose because my code for keyboard shortcuts in Saved searches and Manage categories didn't work if the buttons on the search toolbar had menus. The popup menu appeared in some seemingly random spot. Of course it wasn't random, but ... I fixed it by changing the button to pop up the menu. That caused the behavior change.
I fixed this by removing the shortcuts from the main actions of Saved searches and Manage categories. Instead I used the API you provided in InterfaceAction to create menu items with shortcuts. With the change the 'main' qaction acts like it should, triggering the action for the button pressed. Right-click shows the menu as does clicking the down arrow.
Using a shortcut triggers the hidden menu action, which causes the code to search for any convenient place to put the menu. FWIW: this is a much better implementation. The 'hunt around' code only executes when the user presses a shortcut.
As a consequence existing shortcuts for Manage categories are lost because the shortcut name changed. Oh well. I doubt there are many, probably not any, calibre users who have defined a keyboard shortcut. They haven't had long -- only a release or two.
Given that the saved searches action and the saved search button on the search bar now do the same thing, it seems reasonable to allow the user to choose whether the saved search button shows. I went from there to "Why not allow adding other buttons to the bar?" There is a lot of available real estate on that bar. This commit does that using a new toolbar in preferences / toolbars.
I didn't use a QToolBar, instead constructing a 'classic' toolbar in an QHBoxLayout. That gave me more control over the look and placement. And also, I had no end of trouble trying to work through how to use a QToolBar that isn't attached to a QMainWIndow.
In the process I removed the legacy Saved Search combo box, its associated buttons, and the tweak. I am sure there are some people still using the years-old interface and that they will complain. I can accept that, given that the button is better in almost every way.
