Sigil on Linux: "A plugin by that name does not exist"

[st_albert]

Here's an interesting tidbit. I decided to build 0.9.7 on a Kubuntu 14.04.1 system using the "Building_on_cutting-edge-linux.md" instructions. I installed Qt5.5.1 from the repos, including all the required packages per the instructions.

Sigil built and installed fine (and thanks for getting rid of those warnings!).

However when I tried to run the test plugin, I got the same "a plugin by that name does not exist" error as discussed on this old thread for sigil 0.9.5 (from repo). As before, if the plugin is launched via the plugin buttons, it runs (and reports no error).

When I rebuilt Sigil using Qt 5.4.1 from the official Qt website (which I've used for previous Sigil versions) the problem went away. I don't know if anyone ever got to the bottom of what was going on in the older case, but maybe the problem was in the Qt package(s), not the Sigil package.

Albert

Spoiler:

$ cat /etc/os-release
NAME="Ubuntu"
VERSION="16.04.1 LTS (Xenial Xerus)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 16.04.1 LTS"
VERSION_ID="16.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
VERSION_CODENAME=xenial
UBUNTU_CODENAME=xenial

$ apt-cache policy qtbase5-dev
qtbase5-dev:
  Installed: 5.5.1+dfsg-16ubuntu7.2
  Candidate: 5.5.1+dfsg-16ubuntu7.2
  Version table:
 *** 5.5.1+dfsg-16ubuntu7.2 500
        500 http://us.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     5.5.1+dfsg-16ubuntu7 500
        500 http://us.archive.ubuntu.com/ubuntu xenial/main amd64 Packages

Edited to add: KDE desktop, of course.

[DiapDealer]

Originally Posted by st_albert

When I rebuilt Sigil using Qt 5.4.1 from the official Qt website (which I've used for previous Sigil versions) the problem went away. I don't know if anyone ever got to the bottom of what was going on in the older case, but maybe the problem was in the Qt package(s), not the Sigil package.

I never really heard much more about it, to tell the truth. I couldn't tell from the old thread whether those repo versions that were having the problem used Qt5.5.1. Does that version come stock with Xenial? If so, it's definitely worth looking into. I've never had any problems building Sigil against the repo versions of Qt5.6/7 on Arch, so it's possible there's something about 5.5.1.

[st_albert]

Originally Posted by DiapDealer

I never really heard much more about it, to tell the truth. I couldn't tell from the old thread whether those repo versions that were having the problem used Qt5.5.1. Does that version come stock with Xenial? If so, it's definitely worth looking into. I've never had any problems building Sigil against the repo versions of Qt5.6/7 on Arch, so it's possible there's something about 5.5.1.

Xenial comes with Qt 5.5.1 out of the box. On another Xenial machine, I built Sigil 0.9.6 with Qt 5.5.1 from the official QT website, and it has no problems. When I get time, I'll try building 0.9.7 on that machine with the "official" Qt 5.5.1 and see what happens. I'll be surprised if it doesn't work.

ETA: Yep, it does work. So there's nothing intrinsically wrong with Qt 5.5.1 with respect to Sigil.
It's probably beating a dead horse, but perhaps I'll install the extra -dev packages and build it per the "cutting edge linux" method (i.e. with all the repo-built Qt components) and if it has the bug, that'll be interesting. Prediction: I bet it does.

... and... yes, the same error occurs. Therefore I conclude that when Sigil is built with the repo-supplied Qt 5.5.1 the bug will appear, but if built with Qt 5.5.1 installed from the Qt website, it does not exhibit that bug. BTW, even with the buggy sigil, I can still execute the plugin via the plugin button. Same situation as in the older thread mentioned above.

[Doitsu]

@st_albert: I built Sigil using the cutting edge instructions on my Antergos Arch Linux system and ended up with Qt 5.7.0, which works fine.
I.e., you might even be able to use Qt 5.7.0 from the Qt website.

Apparently you can't use Qt 5.7.0 from the Qt website. For more information see DiapDealer's post.

[DiapDealer]

Originally Posted by Doitsu

@st_albert: I built Sigil using the cutting edge instructions on my Antergos Arch Linux system and ended up with Qt 5.7.0, which works fine.
I.e., you might even be able to use Qt 5.7.0 from the Qt website.

5.7.0 from the Qt website won't have QtWebKit. The last precompiled version that includes QtWebKit is 5.5.1.

I'll have to take look at Sigil's code and see how Qt is involved with launching the plugin via the menu, and how it differs from launching via the plugin button. It almost has to be a QString path getting botched somehow with the former.

If something in Sigil can be changed to work with the repo versions of 5.5.1 (and I have to believe it can, since assigning the plugin to a button still works in the repo version of 5.5.1), then I'd like to find it. They could stay parked on 5.5.1 for quite a while.

[Doitsu]

Originally Posted by DiapDealer

5.7.0 from the Qt website won't have QtWebKit. The last precompiled version that includes QtWebKit is 5.5.1.

I totally forgot about QtWebKit. (I corrected my post.)

[DiapDealer]

Originally Posted by Doitsu

I totally forgot about QtWebKit. (I corrected my post.)

Trust me ... it's not hard to forget. Remembering which Qt can be used and which has to be compiled from scratch (for which OS) is getting to be a real brain teaser.

[DiapDealer]

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:

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.

[DiapDealer]

I confirmed this Qt5 KDE plugin bug on Kubuntu 16.04

QAction*->text() is returning "&testplugin" for the name when run in KDE. The accelerator ampersand doesn't belong there (it's not there on other Desktop Environments). That's why the plugin can't be found via the menu.

Also confirmed that QAction*->toolTip() returns "testplugin" (which is proper and allows the plugin to be launched via the menu like with other DEs).

Not sure exactly what the best solution is right now, but we should be able to have a fix workaround for this KDE issue in the next release.

[DiapDealer]

A workaround for this issue has been committed to Sigil's master branch on Github.