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.
- Add some "manage" actions to the saved searches menu
- Make the saved search button on the search toolbar and the saved searches action use the same menu
- Change some of the icons to use the existing dedicated saved search icons.
- Display the menu under a toolbar action or a menu action if either exists. NB: I don't know if this works on a Mac or Linux
- Make manage categories and saved searches use the same code to place the menu on the screen.
