acceleration keys are not always working and then shown "as text"

[GitMensch]

trafficstars

the title has a contained &.

Hm, this isn't shown in the Dec2020 screenshot https://raw.githubusercontent.com/KDAB/hotspot/master/screenshots/dockwidgets.png is that a new issue or only happening on this machine?

[milianw]

I wonder if that's a system level thing - what version of Qt are you using? Are you using KDE Plasma or something else? If not, can you try with Plasma and see if the issue persists?

[milianw]

no input since many months, closing

[GitMensch]

So I now could reproduce this on different machines and OS (Debian, CentOS7, CentOS8) using the current AppImage.

You can see this when dragging out tabs into its own window, and it is also visible in the timeline view. All machines are "terminal and X-forward-only" so I guess "try with Plasma" won't work, would it?

[milianw]

hm maybe the accelerator doesn't work properly on other platform styles? the &i should be turned into an accelerator and pressing alt should highlight the i and alt+i should focus that then...

[GitMensch]

Wherever it is recognized the acceleration key works fine (menu, "within the view", ...) but not for separate "windows"

[lievenhey]

~~I can confirm this issue on 5.26.3 with wayland~~ ~~happens after moving a dockwidget in its own window~~

This is the title bar. Normally there are no accelerators, so this is somewhat exspected if you use a title with an accelerator.

[lievenhey]

doesn't happen when using x11 (QT_QPA_PLATFORM=xcb hotspot when running wayland)

[GitMensch]

So that's actually a QT issue? [note: the setting above does not change anything on the gitpod or local builds using x11 forwarding]?

Any idea how to tackle that?

[lievenhey]

not really, I am not sure if the problem is in Qt, KDDockWidgets or KWin

[iamsergio]

I think we reached the conclusion this was a Qt bug (not with all styles), with the implementation of drawing QStyle::CE_DockWidgetTitle

[GitMensch]

Thanks for the note - is there a known workaround?

[iamsergio]

Bug should be reported to Qt. Here's a minimal repro without dock widgets

#include <QtWidgets>

// These work:
// ./qtwidgets_basic -style Breeze
// ./qtwidgets_basic -style Oxygen

// This one doesn't:
// ./qtwidgets_basic -style Fusion

class MyWidget : public QWidget {
public:
  void paintEvent(QPaintEvent *ev) override {
    QPainter p(this);

    QStyleOptionDockWidget titleOpt;
    titleOpt.initFrom(this);
    titleOpt.title = "&My Title";

    style()->drawControl(QStyle::CE_DockWidgetTitle, &titleOpt, &p, this);
  }
};

int main(int argc, char **argv) {
  QApplication app(argc, argv);

  qDebug() << QStyleFactory::keys();

  MyWidget window;

  window.show();

  return app.exec();
}

[GitMensch]

Thank you very much for inspecting this - I assume that is specific to (some) QT_QPA_PLATFORM? Any clue if this is QT version specific?

Note: even after installing kde-style-breeze kwin-style-breeze -style Breeze raised a warning:

QApplication: invalid style override 'Breeze' passed, ignoring it.

... is this possibly an AppImage problem (= do the additional styles need to be included there)?

[iamsergio]

It's specific to style, and not to QPA. I expect the same problem in all platforms where fusion is used.

No idea about AppImage, but that's plausible

[GitMensch]

Just a note, while waiting on possibly more styles to test with the appimage to have a workaround: This can also be produced with kcachegrind, so is totally a QT style issue.

Default style (same for -style Windows)	-style Breeze

Can someone point me to the right issue tracker to report this "upstream" - or even better - to an existing ?