Bug 408015 - Global menu doesn't work
Summary: Global menu doesn't work
Status: RESOLVED FIXED
Alias: None
Product: krita
Classification: Applications
Component: General (show other bugs)
Version: 4.2.0
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Krita Bugs
URL:
Keywords:
: 408876 410434 413137 458882 (view as bug list)
Depends on:
Blocks:
 
Reported: 2019-05-28 06:17 UTC by Antonio Rojas
Modified: 2022-09-17 09:51 UTC (History)
20 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Antonio Rojas 2019-05-28 06:17:10 UTC
SUMMARY
Global menu doesn't work in Plasma with 4.2.0, so if you have a global menu applet enabled the menu is not accessible at all.

It broke somewhere between 05baa5b07c36dc69a2a0865c0155d886ab79f128 and 4d345627649dfe8dfcdb97f9fdd0351151d4f5e4, I can't bisect any further since all commits in between require a patched Qt.
Comment 1 Antonio Rojas 2019-05-28 07:02:08 UTC
Seems to happen with Qt 5.13 only, works fine in Qt 5.12. Rebuilding with 5.13 has no effect
Comment 2 Halla Rempt 2019-05-28 07:44:56 UTC
That sounds like it's a regression in Qt then, not in Krita. We don't do anything special in any case.
Comment 3 Antonio Rojas 2019-05-28 16:00:00 UTC
Actually, scratch that. This is also reproducible with Qt 5.12
Comment 4 Philipp A. 2019-05-29 09:36:35 UTC
Krita must be doing something special, as everything else works fine. Qt (KDE or not), GTK, Electron, no problem.
Comment 5 beojan 2019-05-29 09:56:32 UTC
The problem is that Krita's connection to the DBus session bus is suspended when it's opened. This is probably due to this commit in Qt: https://git.merproject.org/mer-core/qtbase/commit/1f6fa1f37a14742ddf53c753ce52d9dc048cd1dc?view=parallel (sorry, not on Qt's own git repository because that doesn't come up in a Google search).

In Krita, delivery isn't being unsuspended when the event loop starts. It looks like Krita creates throwaway QApplication instances while starting up, so perhaps this is connected to that.

This also means nothing that connects to Krita via DBus actually works.
Comment 6 Halla Rempt 2019-05-29 14:30:19 UTC
We also don't provide a dbus interface for anything useful. And yes, we create a temporary QCoreApplication to get the root so we can correctly setup all the language support. If that's causing this problem, I'm not sure how to solve that.
Comment 7 Antonio Rojas 2019-05-30 19:03:16 UTC
Removing this block fixes the issue

--- a/krita/main.cc
+++ b/krita/main.cc
@@ -227,16 +227,6 @@ extern "C" int main(int argc, char **argv)
         qputenv("QT_ANGLE_PLATFORM", "d3d11");
 #endif
 
-        const QSurfaceFormat format =
-            KisOpenGL::selectSurfaceFormat(preferredRenderer, rootSurfaceFormat, enableOpenGLDebug);
-
-        if (format.renderableType() == QSurfaceFormat::OpenGLES) {
-            QCoreApplication::setAttribute(Qt::AA_UseOpenGLES, true);
-        } else {
-            QCoreApplication::setAttribute(Qt::AA_UseDesktopOpenGL, true);
-        }
-        KisOpenGL::setDefaultSurfaceFormat(format);
-        KisOpenGL::setDebugSynchronous(openGLDebugSynchronous);
 
 #ifdef Q_OS_WIN
         // HACK: https://bugs.kde.org/show_bug.cgi?id=390651
Comment 8 Halla Rempt 2019-05-30 19:41:22 UTC
Um... but that's not exactly optional code :-)
Comment 9 Dmitry Kazakov 2019-06-03 10:06:29 UTC
Hi, beojan!

(In reply to beojan from comment #5)

> In Krita, delivery isn't being unsuspended when the event loop starts. It
> looks like Krita creates throwaway QApplication instances while starting up,
> so perhaps this is connected to that.

Yes, we create a lot of throw-away instances of QApplication, and we cannot avoid that. Which code in Qt we should patch to allow multiple instances of QApplication?
Comment 10 Antonio Rojas 2019-06-08 07:52:24 UTC
Just found out that this only happens when using the Plasma QPA. Running krita with the Gnome or the generic QPA shows the global menu correctly (which also explains why it works fine in the appimage)
Comment 11 Halla Rempt 2019-06-15 14:28:35 UTC
So, it's not the dbus issue, but a bug in the plasma qpa?
Comment 12 Antonio Rojas 2019-06-15 14:46:42 UTC
(In reply to Boudewijn Rempt from comment #11)
> So, it's not the dbus issue, but a bug in the plasma qpa?

No idea. CC'ing plasma devs for opinions
Comment 13 beojan 2019-06-15 15:51:15 UTC
It's definitely the DBus issue because that's how the global menu plasmoid communicates with the application.

Rather, there's a bug in the Plasma QPA (or in how the QPA interacts with Krita) that must be causing the DBus problem.
Comment 14 Halla Rempt 2019-06-18 15:51:36 UTC
*** Bug 408876 has been marked as a duplicate of this bug. ***
Comment 15 Halla Rempt 2019-06-24 13:31:28 UTC
Git commit 8d6a2a5d123c90bfb2a4cabdff78a8fc54584e20 by Boudewijn Rempt.
Committed on 24/06/2019 at 13:31.
Pushed by rempt into branch 'master'.

Do not load the platform theme when created a test QApplication

Doing so breaks the plasma qpa so the global menu plasmoid doesn't
work anymore.
Differential Revision: https://phabricator.kde.org/D21886
Patch by David Edmundson, thanks!

M  +5    -2    libs/ui/opengl/KisOpenGLModeProber.cpp

https://invent.kde.org/kde/krita/commit/8d6a2a5d123c90bfb2a4cabdff78a8fc54584e20
Comment 16 Halla Rempt 2019-07-08 14:59:29 UTC
Git commit be0976cb715884a8445c9c980d841866bebc8390 by Boudewijn Rempt.
Committed on 08/07/2019 at 14:59.
Pushed by rempt into branch 'krita/4.2'.

Do not load the platform theme when created a test QApplication

Doing so breaks the plasma qpa so the global menu plasmoid doesn't
work anymore.
Differential Revision: https://phabricator.kde.org/D21886
Patch by David Edmundson, thanks!

M  +5    -2    libs/ui/opengl/KisOpenGLModeProber.cpp

https://invent.kde.org/kde/krita/commit/be0976cb715884a8445c9c980d841866bebc8390
Comment 17 Kai Uwe Broulik 2019-07-31 07:19:30 UTC
*** Bug 410434 has been marked as a duplicate of this bug. ***
Comment 18 Alison Watson 2019-08-06 16:17:17 UTC
Issue does not appear to be resolved as of Krita master/Plasma 5.16.4? Can someone confirm this is fixed on their setup?
Comment 19 emilianh 2019-08-06 17:28:05 UTC
(In reply to Alison Watson from comment #18)
> Issue does not appear to be resolved as of Krita master/Plasma 5.16.4? Can
> someone confirm this is fixed on their setup?

Global menu works here with Krita 4.2.5 on Plasma 5.16.4
Comment 20 M 2019-08-06 21:22:23 UTC
I can confirm it working here too with master and 4.2.5 on Plasma 5.16.4.
Comment 21 Alison Watson 2019-08-06 21:39:57 UTC
Strange, both 4.2.5 (release) and 4.3.0 prealpha (master) don't work for me, running Plasma 5.16.4 and Qt 5.13.0. Using the packages from Arch Linux's repository.
Comment 22 Vladimir Yerilov 2019-08-07 05:54:10 UTC
I can confirm Alison Watson's words, there's no menu on Manjaro as well.
Comment 23 Alison Watson 2019-08-07 05:59:18 UTC
This would appear to be an issue with Arch/Manjaro/other arch based distros then, since I also tried the AppImage, and it works fine. Should contact the maintainers about that.
Comment 24 M 2019-08-07 17:43:42 UTC
Hmm, I'm on Manjaro too and like I said ever since the commit I can use the global menu again without issues.
Comment 25 evan 2019-10-01 07:58:17 UTC
excuse me, it says this bug is fixed but i still have this problem, am i missing something?
i have krita 4.2.6 on kde neon 5.16.5
Comment 26 Halla Rempt 2019-10-01 08:19:58 UTC
Is that the neon package, or the appimage?
Comment 27 evan 2019-10-01 08:25:20 UTC
(In reply to Boudewijn Rempt from comment #26)
> Is that the neon package, or the appimage?

it is the neon package, the appimage version works fine even with version 4.2.0
Comment 28 Halla Rempt 2019-10-01 08:26:45 UTC
Then something broke again in the plasma QPA. These global menu hacks have never been really stable...
Comment 29 David Edmundson 2019-10-01 11:55:41 UTC
If you have a debug build handy can you add a breakpoint on 

QPlatformTheme::QPlatformTheme

and see if you hit it more than once.
Comment 30 evan 2019-10-01 14:24:08 UTC
(In reply to David Edmundson from comment #29)
> If you have a debug build handy can you add a breakpoint on 
> 
> QPlatformTheme::QPlatformTheme
> 
> and see if you hit it more than once.

where can i find that line? i've never compiled krita from source before, but i'll try it.
Comment 31 Halla Rempt 2019-10-01 15:24:38 UTC
This going to get complicated, because that's not in Krita itself, it's probably in Qt.
Comment 32 evan 2019-10-04 07:55:13 UTC
ok, so i tried to run krita using newly created user and the global menu works!
so this is clearly a configuration issue.
thought i've tried removing my kritarc file but it doesn't seems to have any effect, i also purged and reinstalled krita later but it still doesnt work.
it could be the global menu's config, i don't know, can anyone help me?
Comment 33 Halla Rempt 2019-10-04 08:02:37 UTC
It is impossible that it's the kritarc file -- Krita really hasn't got anything to do with global menus. Where the configuration for that is stored, I don't know, I'm afraid.
Comment 34 Vladimir Yerilov 2019-10-05 06:38:43 UTC
Ha, I've found the culprit, or, to say more precisely, incompatible settings which cause absence of the global menu.
I used to have `.pam_environment` file in my home folder with the following content:
```
XMODIFIERS=@im=fcitx
GTK_IM_MODULE=fcitx
QT_IM_MODULE=fcitx
DefaultIMModule=fcitx
```
That's to be able to use fcitx for Japanese input in Plasma. Without it, no complex input possible. But also without it, Krita's global menu is present.

So there's something should be done to resolve this. I'm not a coder and have no idea why these things influence each other.
Comment 35 Vladimir Yerilov 2019-10-05 07:08:48 UTC
Just checked on Plasma git version and another user account, same thing always happens when QT_IM_MODULE is set to fcitx.
Comment 36 evan 2019-10-05 08:02:40 UTC
i also use fcitx for japanese input, that could be what my problem is as well.
how do you change QT_IM_MODULE value? i wanna test it.
Comment 37 Vladimir Yerilov 2019-10-05 08:44:47 UTC
I've just commented it out, but this makes Japanese input in all QT apps impossible.
Comment 38 evan 2019-10-05 09:07:23 UTC
i can't seem to find .pam_environment file but i did disabled fcitx and the global menu works.
Comment 39 Halla Rempt 2019-10-05 11:19:58 UTC
Okay, then that's definitely not a krita bug, so this bug can stay closed.
Comment 40 Vladimir Yerilov 2019-10-07 10:08:44 UTC
evan, a quick and ugly workaround is to alter krita launch command from `krita %F` to `QT_IM_MODULE=ibus krita %F`.
Comment 41 evan 2019-10-07 10:46:23 UTC
(In reply to Vladimir Yerilov from comment #40)
> evan, a quick and ugly workaround is to alter krita launch command from
> `krita %F` to `QT_IM_MODULE=ibus krita %F`.

i see, thanks for the info.
but this will disable japanese input inside krita, right?

also the other workaround is to use KDE_NO_GLOBAL_MENU=1 when launching krita to disable global menu and make the menu bar shows up.
Comment 42 Halla Rempt 2019-10-18 11:49:49 UTC
*** Bug 413137 has been marked as a duplicate of this bug. ***
Comment 43 Weng Xuetian 2019-11-09 03:55:01 UTC
Just FYI, I tried to root cause the issue. There are some underlying dbus issue in krita that blocks things to be processed. I doubt there could be some deadlock. I tried to make fcitx im module to use its own dbus connection and seems that will solve the problem.
Comment 44 Halla Rempt 2019-11-09 11:23:56 UTC
Krita itself doesn't use dbus at all, we don't even provide a dbus api to control the application, though we don't disable dbus in the appimage's version of Qt.
Comment 45 beojan 2019-11-09 11:53:21 UTC
The Plasma QPA loaded into Krita uses DBus to communicate with the Plasmoid (/ service).

Does fcitx interfere with dbus in other applications.
Comment 46 Halla Rempt 2022-09-17 09:51:10 UTC
*** Bug 458882 has been marked as a duplicate of this bug. ***