Bug 408015

Seems to happen with Qt 5.13 only, works fine in Qt 5.12. Rebuilding with 5.13 has no effect

That sounds like it's a regression in Qt then, not in Krita. We don't do anything special in any case.

Actually, scratch that. This is also reproducible with Qt 5.12

Krita must be doing something special, as everything else works fine. Qt (KDE or not), GTK, Electron, no problem.

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.

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.

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

Um... but that's not exactly optional code :-)

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?

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)

So, it's not the dbus issue, but a bug in the plasma qpa?

(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

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.

*** Bug 408876 has been marked as a duplicate of this bug. ***

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

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

*** Bug 410434 has been marked as a duplicate of this bug. ***

Issue does not appear to be resolved as of Krita master/Plasma 5.16.4? Can someone confirm this is fixed on their setup?

(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

I can confirm it working here too with master and 4.2.5 on Plasma 5.16.4.

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.

I can confirm Alison Watson's words, there's no menu on Manjaro as well.

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.

Hmm, I'm on Manjaro too and like I said ever since the commit I can use the global menu again without issues.

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

Is that the neon package, or the appimage?

(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

Then something broke again in the plasma QPA. These global menu hacks have never been really stable...

If you have a debug build handy can you add a breakpoint on 

QPlatformTheme::QPlatformTheme

and see if you hit it more than once.

(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.

This going to get complicated, because that's not in Krita itself, it's probably in Qt.

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?

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.

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.

Just checked on Plasma git version and another user account, same thing always happens when QT_IM_MODULE is set to fcitx.

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.

I've just commented it out, but this makes Japanese input in all QT apps impossible.

i can't seem to find .pam_environment file but i did disabled fcitx and the global menu works.

Okay, then that's definitely not a krita bug, so this bug can stay closed.

evan, a quick and ugly workaround is to alter krita launch command from `krita %F` to `QT_IM_MODULE=ibus krita %F`.

(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.

*** Bug 413137 has been marked as a duplicate of this bug. ***

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.

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.

The Plasma QPA loaded into Krita uses DBus to communicate with the Plasmoid (/ service).

Does fcitx interfere with dbus in other applications.

*** Bug 458882 has been marked as a duplicate of this bug. ***

The bug is again present with Krita 5.1.1

this is my configuration

Operating System: Manjaro Linux
KDE Plasma Version: 5.26.2
KDE Frameworks Version: 5.99.0
Qt Version: 5.15.7
Kernel Version: 6.0.6-2-MANJARO (64-bit)
Graphics Platform: X11
Processors: 8 × 11th Gen Intel® Core™ i5-1135G7 @ 2.40GHz
Memory: 15.4 GiB of RAM
Graphics Processor: Mesa Intel® Xe Graphics
Manufacturer: Dell Inc.
Product Name: Inspiron 5502

Sorry, global menus on X11/Plasma are a hack, and it's really a waste of time to try to use them or support them: if there was a point, Qt would support it natively, but it doesn't.

global menu is a KDE feature and Krita is a KDE software.
So, this is a legitimate bug.
As far as I know, Krita is the only KDE software that has this problem with the global menu.

(In reply to Guido from comment #49)
> global menu is a KDE feature and Krita is a KDE software.
> So, this is a legitimate bug.
> As far as I know, Krita is the only KDE software that has this problem with
> the global menu.

Take a look at the duplicate 45882 (https://bugs.kde.org/show_bug.cgi?id=458882). It's not really an upstream bug, it's caused by Krita creating throwaway QApplication instances in it's startup routine (which the Qt documentation warns against). I'm not sure if there's an easy fix for this though.

Please do not reopen bugs that developers have closed. That is rude. We are already overloaded and if we close a bug it's because we won't look into it. Reopening will only make us close it again.

FWIW anyone who wants to look into fixing this is welcome to; the bug report doesn't have to be open for them to do that. If a fix is submitted that works and doesn't regress anything else, I have to imagine it would be accepted and merged.

(In reply to Nate Graham from comment #53)
> FWIW anyone who wants to look into fixing this is welcome to; the bug report
> doesn't have to be open for them to do that. If a fix is submitted that
> works and doesn't regress anything else, I have to imagine it would be
> accepted and merged.

Let's see if that's the case
https://invent.kde.org/graphics/krita/-/merge_requests/1634

Git commit f128f7c2896c7772e83ba7a6e81e2fbb5e7e8bb1 by Antonio Rojas.
Committed on 02/11/2022 at 20:55.
Pushed by lsegovia into branch 'master'.

Fix global menu on Wayland with KDE Qt Patch Collection

Prevent the throwaway QApplication instance to launch xdg-desktop-portal, which makes it claim the dbus interface and breaks global menu

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

https://invent.kde.org/graphics/krita/commit/f128f7c2896c7772e83ba7a6e81e2fbb5e7e8bb1

Git commit 5216b3e396d8d89beebca0428d6bb2dccc8de558 by L. E. Segovia, on behalf of Antonio Rojas.
Committed on 03/11/2022 at 00:30.
Pushed by lsegovia into branch 'krita/5.1'.

Fix global menu on Wayland with KDE Qt Patch Collection

Prevent the throwaway QApplication instance to launch xdg-desktop-portal, which makes it claim the dbus interface and breaks global menu
(cherry picked from commit f128f7c2896c7772e83ba7a6e81e2fbb5e7e8bb1)

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

https://invent.kde.org/graphics/krita/commit/5216b3e396d8d89beebca0428d6bb2dccc8de558

(In reply to Antonio Rojas from comment #58)
> Let's see if that's the case
> https://invent.kde.org/graphics/krita/-/merge_requests/1634
Lo and behold, it is. :)

Thanks for the quick work!

(In reply to Antonio Rojas from comment #59)
> Git commit f128f7c2896c7772e83ba7a6e81e2fbb5e7e8bb1 by Antonio Rojas.
> Committed on 02/11/2022 at 20:55.
> Pushed by lsegovia into branch 'master'.
> 
> Fix global menu on Wayland with KDE Qt Patch Collection
> 
> Prevent the throwaway QApplication instance to launch xdg-desktop-portal,
> which makes it claim the dbus interface and breaks global menu
> 
> M  +2    -0    libs/ui/opengl/KisOpenGLModeProber.cpp
> 
> https://invent.kde.org/graphics/krita/commit/
> f128f7c2896c7772e83ba7a6e81e2fbb5e7e8bb1

Thank you Antonio, I confirm the bug is fixed on X11.

Git commit ea5fde3df58e67aa044959f1dd055ac0d9daf9a3 by Sharaf Zaman, on behalf of Dmitry Kazakov.
Committed on 23/12/2022 at 10:04.
Pushed by dkazakov into branch 'master'.

Disable prober workaround for plasma

This workaround causes Krita to crash on Windows with Qt 5.15.7

The patch basically reverts 8d6a2a5d123c90bfb2a4cabdff78a8fc54584e20
and theoretically may introduce bug 408015.

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

https://invent.kde.org/graphics/krita/commit/ea5fde3df58e67aa044959f1dd055ac0d9daf9a3

(In reply to sh_zam from comment #63)
> Git commit ea5fde3df58e67aa044959f1dd055ac0d9daf9a3 by Sharaf Zaman, on
> behalf of Dmitry Kazakov.
> Committed on 23/12/2022 at 10:04.
> Pushed by dkazakov into branch 'master'.
> 
> Disable prober workaround for plasma
> 
> This workaround causes Krita to crash on Windows with Qt 5.15.7
> 
> The patch basically reverts 8d6a2a5d123c90bfb2a4cabdff78a8fc54584e20
> and theoretically may introduce bug 408015.
> 
> M  +4    -2    libs/ui/opengl/KisOpenGLModeProber.cpp
> 
> https://invent.kde.org/graphics/krita/commit/
> ea5fde3df58e67aa044959f1dd055ac0d9daf9a3

It would be better an ifdef at compile time...
Anyway, hope Antonio will fix this for ArchLinux.

Git commit 5ad940678e7d3d1c86cde5a6d581272d71a05e7b by L. E. Segovia.
Committed on 30/04/2023 at 02:21.
Pushed by lsegovia into branch 'krita/5.1'.

KisOpenGLModeProber: disable prober workaround for plasma only on 5.15+

This workaround causes Krita to crash on Windows with Qt 5.15.7.

The original patch (see commit ID below) reverts
8d6a2a5d123c90bfb2a4cabdff78a8fc54584e20 wholesale. To preserve 5.1
compatibility, here I wrapped the removed bits in a version check,
so that they keep executing with 5.12.
(cherry picked from commit ea5fde3df58e67aa044959f1dd055ac0d9daf9a3)

M  +7    -0    libs/ui/opengl/KisOpenGLModeProber.cpp

https://invent.kde.org/graphics/krita/commit/5ad940678e7d3d1c86cde5a6d581272d71a05e7b