Addview not working

[ihewitt]

Under dev GoldenCheetah, on Linux, Qt5.5.1 the Add Chart menu from the main menu doesn't work for me. The small toolbar menu option does still work.

On my machine/config it appears that this is because the call to text() in MainWindow::addChart is returning a string with accelerator markup. (i.e. it returns "&Workout" rather than "Workout")

if (GcWindows[i].name == action->text()) {

Replacing this with a call to toolTip() instead returns the correct text and fixes the issue for me since this defaults to the original message text unless explicitly set.

if (GcWindows[i].name == action->toolTip()) {

[ihewitt]

Is this a qt5 issue? just a kde/linux issue?

[liversedge]

Never seen this.

[ihewitt]

Strange, I have had it consistently on qt5. The documentation implies this shouldn't be happening though: http://doc.qt.io/qt-5/qaction.html#QAction-1 stating that the action will use a stripped version of the text, although that's a bit vague and says that's for tool buttons.
Perhaps this is a qt bug for this version, I'll try a little test app to see what the scenarios/permutations are.

[ihewitt]

Ok, weird. It seems to happen for the actions passed via the "selected" slot, querying the menu action when it is added returns the plain text, but from the action to the slot has the accelerator.
I can reproduce in a simple application: https://gist.github.com/ihewitt/8a3e15e60e8c7f20cf22

I see the output as shown in the screenshot.

(Qt 5.5.1 Linux 64bit)

[liversedge]

What I really don't understand is those texts do not have shortcuts in them, they are defined in GcWindowRegistry.cpp

[liversedge]

And I build with QT 5.5.1 on OSX and have no issues.

[liversedge]

https://bugs.kde.org/show_bug.cgi?id=345023

[ihewitt]

Aha, interesting, although that short testcase I wrote shows has nothing to do with designer. It looks like there's a deeper library issue there. I'll comment on that bug.

[liversedge]

Its the kde plugin

[ihewitt]

No, it's a KDE runtime issue, since we're not relying on the designer-or its plugin for creating the resources, we're doing it programatically both in GC and in that short testcase.
It's just that the original reporters were seeing the underlying bug exposed using the kde plugin.

So well, yes, it is the kde plugin, but only because there's a deeper problem. :)

[ihewitt]

ok, there's a simple workaround, adding:

[Development]
AutoCheckAccelerators=false

to ~/.config/kdeglobals

Fixes the problem, although that does mean that anyone running on KDE will not understand why the menus aren't working and might take some time to locate the fix. :(
In the process I had the attached patch locally, which adds window manager detection, reports window manager in the version dialog, and uses the alternative text if running on KDE. just feels like a sledgehammer to a minor issue!
Patch: wm-detect.diff

[liversedge]

Why not just use the tooltip instead, or are there other issues with that?

[ihewitt]

Nope no issues - misinterpreted your comments as "this is a platform issue" so implemented a platform fix. ;)
Just feels slightly wrong doing the tooltip, after all the text() should work.

[liversedge]

oh lord, if the simple answer is to use the tooltip lets do that !
(and a comment to explain why text() isn't used)

👍

[amtriathlon]

I think this proposed solution could also be applied here, since is it is simple and safe: #2930 (comment)