Bug 458882

Created attachment 151927 [details]
On top the menubar showing on krita ran as super user, on bottom krita ran as normal user

Quick question - do you have a global menu applet enabled in your Plasma desktop? Does this behaviour persist if you remove it, if so?

(In reply to Qualimer Judith from comment #2)
> Quick question - do you have a global menu applet enabled in your Plasma
> desktop? Does this behaviour persist if you remove it, if so?

No, I haven't Installed any applet for Plasma that shouldn't be the cause. 
I've been using Linux for a little less than a month, I'm not really sure what a 'global menu applet' is.

Judging from your screenshot you are using a titlebar menu button. That means that the in-app menubar is disabled.

If you want the in-app menu bar you need to remove the menu button from the window decoration

(In reply to Nicolas Fella from comment #4)
> Judging from your screenshot you are using a titlebar menu button. That
> means that the in-app menubar is disabled.
> 
> If you want the in-app menu bar you need to remove the menu button from the
> window decoration

I prefer the menu button over the in-app menubar but the problem is that neither of them work as non root user

The system that allows various menubar options works using dbus, so it sounds like there's a misconfiguration there. Either that, or the integration broke again: it's a very fragile and little used system. Does the appimage work for you?

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

(In reply to Halla Rempt from comment #6)
> The system that allows various menubar options works using dbus, so it
> sounds like there's a misconfiguration there. Either that, or the
> integration broke again: it's a very fragile and little used system. Does
> the appimage work for you?

AppImage looks fine on arch linux. Package from repository doesn't

Um, then please do also report an Arch bug?

This is caused by https://invent.kde.org/qt/qt/qtbase/-/commit/1b3f742baf1ed2e4171ced79541f1e4647058a0a

The following minimal Qt patch is enough to break the global menu in Krita (and only in Krita)

diff --git a/src/platformsupport/services/genericunix/qgenericunixservices.cpp b/src/platformsupport/services/genericunix/qgenericunixservices.cpp
index f0d1722c95..fa92a0dfa6 100644
--- a/src/platformsupport/services/genericunix/qgenericunixservices.cpp
+++ b/src/platformsupport/services/genericunix/qgenericunixservices.cpp
@@ -298,6 +302,13 @@ static inline QDBusMessage xdgDesktopPortalSendEmail(const QUrl &url)
 }
 #endif // QT_CONFIG(dbus)
 
+QGenericUnixServices::QGenericUnixServices()
+{
+#if QT_CONFIG(dbus)
+    QDBusMessage message;
+    QDBusPendingCall pendingCall = QDBusConnection::sessionBus().asyncCall(message);
+#endif
+}
 QByteArray QGenericUnixServices::desktopEnvironment() const
 {
     static const QByteArray result = detectDesktopEnvironment();
diff --git a/src/platformsupport/services/genericunix/qgenericunixservices_p.h b/src/platformsupport/services/genericunix/qgenericunixservices_p.h
index 8ac3de6f03..30924e64bd 100644
--- a/src/platformsupport/services/genericunix/qgenericunixservices_p.h
+++ b/src/platformsupport/services/genericunix/qgenericunixservices_p.h
@@ -59,7 +59,7 @@ QT_BEGIN_NAMESPACE
 class QGenericUnixServices : public QPlatformServices
 {
 public:
-    QGenericUnixServices() {}
+    QGenericUnixServices();
 
     QByteArray desktopEnvironment() const override;

I'm happy to see that at least a the culprit was found.
In the mean time i gave up on the "app menu" button entirely.
I turned off the button and after rebooting the Menu Bar reappears on krita,
(Ctrl + Shift + M does not work btw)

Sorry for the inconvenience

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

We've had many  reports like this over the years. https://bugs.kde.org/show_bug.cgi?id=408015 is an example: there David Edmundson resolved the issue with a hack: https://invent.kde.org/kde/krita/commit/be0976cb715884a8445c9c980d841866bebc8390.

dbus has big problems if a process creates two QApplication objects. It somehow latches onto the first one. And we cannot work around that, we have to have this probing QApplication instance. 

I don't think we can do anything about this from within Krita :-(

*** This bug has been marked as a duplicate of bug 408015 ***

> dbus has big problems if a process creates two QApplication objects. It
> somehow latches onto the first one. And we cannot work around that, we have
> to have this probing QApplication instance. 
> 
> I don't think we can do anything about this from within Krita :-(

Why can't the global `KisApplication::instance()` be used instead of creating an additional QApplication instance?

The Qt documentation contains this sentence as part of the QApplication reference:

> For any GUI application using Qt, there is precisely one QApplication object, no matter whether the application has 0, 1, 2 or more windows at any given time.

Because the first QApplication instance is used to probe, and then destructed, and then a new one is created.

Could the main KisApplication instance be constructed earlier, so it can be used for the probing?

Alternatively, could the probing be done without constructing a QApplication instance (maybe by using other libraries)?

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

also getting this issue on plasma 6.0.1 on arch