Bitcoin-Qt: use statustips in addition to tooltips #1923

• add setStatusTip() in addition to setTooltip() where it makes sense
• add only setStatusTip() if GUI element is only used in main- or tray menu
• add an event filter on our BitcoinGUI object to prevent garbelled text on the status bar, which happens when we use it for e.g. displaying block-sync state and then a QEvent::StatusTip wants to write own text to it
• remove a double translation of "Bitcoin client"

This solves #1079.

To be more precise you removed "all tooltips from QActions"?

No, not from all, just from the ones, which were only used for tray menus and in our main menu. The tooltips on toolbar buttons (e.g. QAction *overviewAction;) are still there. I verified which were safe to remove.

ok.. "except from the tab buttons". I agree they are pointless at the moment.

But it's a bit sad to throw these messages away, which have been translated into many languages. I wonder if there is another way to show a short help message for menu items?

It appears that on the Qt documentation they recommend using status tips for menu items:

openAct->setStatusTip(tr("Open an existing file"));

I wonder if we can fit these in somehow, or use another way.

You are absolutely right, it even looks nice to use tooltips for these :). I'll change this pull.

Edit: Well it doesn't look nice, when hovering a menu item which has a tooltip during block-sync as the statusbar text get's garbelled pretty ugly (2 different texts displayed at the same place -> unreadable).

Hm, indeed, as we use the status bar for different purposes, we'd need to find a solution for that. I think most straightforward would be to hide status tips when something else occupies the status bar?

I've currently no idea how to do this ... but I'll try via an event filter :).

I got it working, will update this pull later. I installed a global event filter on qApp and use this code to prevent the garbelled text:

<pre> bool BitcoinGUI::eventFilter(QObject *object, QEvent *event) { // Catch status tip events if (event->type() == QEvent::StatusTip) { // Prevent adding text from setStatusTip(), if we currently use the status bar for displaying other stuff if (progressBarLabel->isVisible() && progressBar->isVisible()) return true; } return QMainWindow::eventFilter(object, event); } </pre>

What do you think?

I think it's a good solution!

Updated with event filter, would be nice if @laanwj could test it, too.

Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/da1962e2fd6c27a3a34d1f6108042b0c35c94c93 for binaries and test log.

I can't get status tips to appear at all on Ubuntu. This is likely an Ubuntu problem :cry: (as it exports the menu), not a bug in the code.

Edit: It works when disabling the "Native menubar":

QT_X11_NO_NATIVE_MENUBAR=1 ./bitcoin-qt -testnet

This proves that the problem is in https://launchpad.net/appmenu-qt and thus out of the scope of this issue. Even filed a upstream bug: https://bugs.launchpad.net/appmenu-qt/+bug/1068974

It works in windows! That means it will also work in other Linux distributions that don't hijack everything.

ACK

I think another pull should be made after this, to get a tooltip for every single item used in the main menu, which is currently not the case. It feels incomplete when we leave it that way IMO.

I recommend setting the status tip equal to the tooltip for all QActions by default. This keeps the amount of messages relatively small, and they're never visible at once anyway (ie, tooltips show when the QAction is used for buttons and statustips when the same action is used for menu item).

@laanwj I updated this pull to now use statustips in addition to tooltips where it makes sense and added new descriptive texts for some elements that were missing these.

Instead of repeating the message, why not do:

widget->setStatusTip(widget->getToolTip())

(or other way around) Otherwise they're bound to diverge over time.

Sure that is way better :).

Updated to reflect your suggestion.

@laanwj I guess this needs a rebase after your warning bar pull is in, but are you ok with it now?

I have a question on our used eventFilter() functions. The Digia doc says:

<pre> If all the event filters allow further processing of an event (by each returning false), the event is sent to the target object itself. If one of them stops processing (by returning true), the target and any later event filters do not get to see the event at all. </pre>

Then why are we nearly everywhere doing something like return QObject::eventFilter(obj, evt); at the end of your eventFilter() instead of just false, to send the event to the target object?

QObject is not the target object. It is the superclass, it's customary to call the superclass method when overriding a method in Qt. It might well be implemented as "return false", but that's an internal implementation detail.

Edit: yes this is ok with me now

Alright, but we also have some that use QWidget or QDialog and one that uses just false. I just want to understand, if we should harmonize that and what are the resons we did it like it's now.

Yes, if your superclass is QFoo you should use QFoo. QObject is used for classes that derive from QObject. Etc.

Using just false could cause bugs in event propagation in some cases, at least theoretically.

Can I get an ACK?

Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/3c4bac3c2f3eb4ff9b60d6f64b5e035dee7e5fd4 for binaries and test log.

ACK