View Single Post
Old 11-06-2016, 12:43 PM   #8
DiapDealer
Grand Sorcerer
DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.
 
DiapDealer's Avatar
 
Posts: 28,691
Karma: 205039118
Join Date: Jan 2010
Device: Nexus 7, Kindle Fire HD
I moved these posts from the Sigil 0.9.7 release page, as I think I've had some success in tracking the problem down. I hope you don't mind.

This actually appears to be a KDE bug affecting Qt5 applications.

It doesn't manifest when using the stock Qt because the KDE Qt plugins are not included with those versions (only with the repo-supplied Qt on KDE flavors). I can also verify that it doesn't occur when building with the repo-supplied versions of Qt on a stock Xenial (Gnome/Unity) Ubuntu installation.

Particularly relevant from that bug report is the last part of comment #6:
Quote:
This shows that the problem surfaces when a QAction* is passed back to a triggered event at which point the text() has an accelerator, although the toolTip() text remains correct.
That is exactly how Sigil gets the plugin's name from the Main Menu (QAction* is passed back to a triggered event and the name of the plugin is retrieved with QAction->text())

The three assignable plugin buttons get the plugin name directly from the SettingsStore pluginMap -- which is why it doesn't suffer from the same problem.

I just need to get a KDE VM up and running to see if I can verify the issue (and a solution). The toolTip() property of QAction is purported to default to the text assigned (if not explicitly set or changed) and doesn't seem to suffer from the accelerator injection that happens with text() on KDE. I can verify that using toolTip() still works great on non-KDE versions of Linux, so maybe the fix is as simple as that.

Anyway ... thanks for bringing it back to my attention.

Last edited by DiapDealer; 11-06-2016 at 01:24 PM.
DiapDealer is online now   Reply With Quote