Some problems with the Find plugin in master

[ccordoba12]

After merging PR #13376 I found the following problems with the Find plugin in master:

• The Find in Files action in the Search menu does nothing when Spyder is started with clean settings. That's because now it's associated to the Search button in its toolbar:

  

  So it's clear why it does nothing: because there's no text to search by default. But in Spyder 4 that action was associated to the toggle action of the plugin, so it showed the plugin in case it was hidden (which is the default with clean settings).

• All buttons in the Find toolbar are now QAction's, whereas in Spyder 4 they were QToolButton's. That doesn't allow us to remove their tooltips because QActions always have an associated tooltip. For instance, in PR PR: Fix some issues with the Find and Code Analysis panes #13376 I removed the tooltip of the Search button because it was really unnecessary.

---

The last problem points to a really significant change (switching QToolButton's for QAction's). I don't understand its purpose because it makes things less flexible for us in master (like the above issue clearly shows).

@goanpeca, could you explain your rationale for this? Also, is it possible for us to revert to QToolButton's everywhere where they were used in Spyder 4?

[goanpeca]

The Find in Files action in the Search menu does nothing when Spyder is started with clean settings. That's because now it's associated to the Search button in its toolbar:

See #13398

All buttons in the Find toolbar are now QAction's, whereas in Spyder 4 they were QToolButton's. That doesn't allow us to remove their tooltips because QActions always have an associated tooltip. For instance, in PR #13376 I removed the tooltip of the Search button because it was really unnecessary.

See #13398

I don't understand its purpose because it makes things less flexible for us in master (like the above issue clearly shows).

That is how Qt works and is meant to be used. See https://doc.qt.io/qt-5/qaction.html

In applications many common commands can be invoked via menus, toolbar buttons, and keyboard shortcuts. Since the user expects each command to be performed in the same way, regardless of the user interface used, it is useful to represent each command as an action.

Actions can be added to menus and toolbars, and will automatically keep them in sync. For example, in a word processor, if the user presses a Bold toolbar button, the Bold menu item will automatically be checked.

Actions can be created as independent objects, but they may also be created during the construction of menus; the QMenu class contains convenience functions for creating actions suitable for use as menu items.

A QAction may contain an icon, menu text, a shortcut, status text, "What's This?" text, and a tooltip. Most of these can be set in the constructor. They can also be set independently with setIcon(), setText(), setIconText(), setShortcut(), setStatusTip(), setWhatsThis(), and setToolTip(). For menu items, it is possible to set an individual font with setFont().

Actions are added to widgets using QWidget::addAction() or QGraphicsWidget::addAction(). Note that an action must be added to a widget before it can be used; this is also true when the shortcut should be global (i.e., Qt::ApplicationShortcut as Qt::ShortcutContext).

Once a QAction has been created it should be added to the relevant menu and toolbar, then connected to the slot which will perform the action. For example:

---

Also, is it possible for us to revert to QToolButton's everywhere where they were used in Spyder 4?

I would not recommend it. Doing the way it is now, reduces work everywhere for users and developers and core developers. See #13398 which already adds a fix for the issue.

[ccordoba12]

I would not recommend it. Doing the way it is now, reduces work everywhere for users and developers and core developers.

Ok, no problem. Thanks for the detailed explanation!