Bug 1108846

Summary: gmenudbusmenuproxy needs appmenu-gtk-module
Product: [openSUSE] openSUSE Tumbleweed Reporter: Cor Blom <cornelis>
Component: KDE Workspace (Plasma)Assignee: E-Mail List <opensuse-kde-bugs>
Status: RESOLVED FIXED QA Contact: E-mail List <qa-bugs>
Severity: Critical    
Priority: P5 - None CC: 20alexrod, cornelis, fabian, fvogt, sor.alexei
Version: Current   
Target Milestone: ---   
Hardware: Other   
OS: Other   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description Cor Blom 2018-09-18 15:51:00 UTC
gmenudbusmenuproxy (part of plasma5-workspace) requires appmenu-gtk-module during runtime, not unity-gtk-module. It is since a few days in Factory. Part of the package "vala-panel-appmenu".

See also the build log.
Comment 1 Cor Blom 2018-11-08 14:52:30 UTC
The current version of appmenu-gtk-module in tumbleweed makes gtk apps crash in plasma (segmentation fault). So sticking to unity-gtk-module is better for now.
Comment 2 Fabian Vogt 2018-11-08 15:50:58 UTC
(In reply to Cor Blom from comment #0)
> gmenudbusmenuproxy (part of plasma5-workspace) requires appmenu-gtk-module
> during runtime, not unity-gtk-module. It is since a few days in Factory.
> Part of the package "vala-panel-appmenu".

It does not - unity-gtk-module works just fine.
Comment 3 Fabian Vogt 2018-11-08 16:02:18 UTC
(In reply to Cor Blom from comment #1)
> The current version of appmenu-gtk-module in tumbleweed makes gtk apps crash
> in plasma (segmentation fault). So sticking to unity-gtk-module is better
> for now.

If we were to switch to appmenu-gtk-module this would need to be done:

gmenudbusmenuproxy gains two subpackages:

gmenudbusmenuproxy-unity
gmenudbusmenuproxy-appmenu

which require unity-gtk-module or appmenu-gtk-module respectively and provide "gmenudbusmenuproxy-gtk-module" each. gmenudbusmenuproxy can than require that and the user/zypper is free to choose between those.

There would need to be a script for appmenu-gtk-module to configure the GTK(3)_MODULES environment variable though.

Would you mind to create a bug report against appmenu-gtk-module as it crashes?
Comment 4 Cor Blom 2018-11-08 17:53:55 UTC
(In reply to Fabian Vogt from comment #2)
> (In reply to Cor Blom from comment #0)
> > gmenudbusmenuproxy (part of plasma5-workspace) requires appmenu-gtk-module
> > during runtime, not unity-gtk-module. It is since a few days in Factory.
> > Part of the package "vala-panel-appmenu".
> 
> It does not - unity-gtk-module works just fine.

It does not work fine with gtk2 apps. Gimp for example has two menubars, the one in the application and the global menu. This does not happen with appmenu-gtk-module.

But it is the only difference I saw.
Comment 5 Cor Blom 2018-11-08 18:01:46 UTC
(In reply to Fabian Vogt from comment #3)
> Would you mind to create a bug report against appmenu-gtk-module as it
> crashes?

See bug #1115273
Comment 6 Cor Blom 2019-12-24 00:34:56 UTC
(In reply to Cor Blom from comment #5)
> (In reply to Fabian Vogt from comment #3)
> > Would you mind to create a bug report against appmenu-gtk-module as it
> > crashes?
> 
> See bug #1115273

The crash does not happen anymore in current Tumbleweed
Comment 7 Cor Blom 2020-04-10 19:30:16 UTC
Are there any plans to do something with this bug? The new appmenu-gtk-module is also in Leap 15.2 and working fine there. Also with gtk2 apps like gimp. the unity module can be removed and the appmenu-gtk-module installed and it is working as expected.

If the plan is to leave everything as it is and let the user choose what to do, it's better to close this bug, IMHO. Although the appmenu module is still developed, the unity variant not, as far as I can see.
Comment 8 Fabian Vogt 2020-04-14 09:10:36 UTC
Meanwhile gmenudbusmenuproxy is able to enable the appmenu-gtk-module on demand, so no modifications to the packaging should be necessary anymore.
However, this needs some testing and the migration would need a
Conflicts: unity-gtk-module-common

and I'm not fully sure how that would behave with upgrades...

Test package is building here:
https://build.opensuse.org/package/show/home:Vogtinator:boo1108846/plasma5-workspace

Can you give this a try, maybe even test the upgrade scenario (Make sure unity-gtk*-module is installed, then zypper -v dup --from $aboverepo)?
Comment 9 Cor Blom 2020-04-14 09:51:37 UTC
Can you also add 15.2?
Comment 10 Fabian Vogt 2020-04-14 10:10:39 UTC
(In reply to Cor Blom from comment #9)
> Can you also add 15.2?

Done, it's building now.
Comment 11 Cor Blom 2020-04-14 11:13:19 UTC
On 15.2 update removes the following:

unity-gtk-module-common
unity-gtk2-module
unity-gtk3-module

It leave the following installed, which I assume should also be removed (but maybe they are needed by something??):

libunity-gtk2-parser0
libunity-gtk3-parser0

And it wants to install the following new packages:

appmenu-gtk-module-common
appmenu-gtk2-module
appmenu-gtk3module
libappmenu-gtk2-parser0
libappmenu-gtk3-parser0

I cannot test op 15.1 or TW at the moment, but I assume the result is the same. If necessary I can do a test on 15.1 later.
Comment 12 Fabian Vogt 2020-04-14 11:19:40 UTC
(In reply to Cor Blom from comment #11)
> On 15.2 update removes the following:
> 
> unity-gtk-module-common
> unity-gtk2-module
> unity-gtk3-module

Was manual conflict required or did zypper do that automatically?

> It leave the following installed, which I assume should also be removed (but
> maybe they are needed by something??):
> 
> libunity-gtk2-parser0
> libunity-gtk3-parser0

Probably just kept because auto cleanup of deps is only possible with "zypper rm --clean-deps"...

> And it wants to install the following new packages:
> 
> appmenu-gtk-module-common
> appmenu-gtk2-module
> appmenu-gtk3module
> libappmenu-gtk2-parser0
> libappmenu-gtk3-parser0

Sounds sensible. I assume it works fine with enabling/disabling the global menu?

> I cannot test op 15.1 or TW at the moment, but I assume the result is the
> same. If necessary I can do a test on 15.1 later.

15.1 doesn't have appmenu-gtk{2,3}-module packages, so the switch wasn't possible there.
Comment 13 Cor Blom 2020-04-14 11:30:53 UTC
The issue was that plasma 5.18.4.1 is not yet available in 15.2, so I had to allow come incompatibility. It required manual intervention, the following:

Probleem: gmenudbusmenuproxy-5.18.4.1-lp152.514.1.x86_64 is in conflict met unity-gtk-module-common die geleverd is door unity-gtk-module-common-0.0.0+bzr20171202-lp152.3.6.x86_64
 Oplossing 1: De volgende acties worden uitgevoerd:
  verwijderen van unity-gtk-module-common-0.0.0+bzr20171202-lp152.3.6.x86_64
  verwijderen van unity-gtk3-module-0.0.0+bzr20171202-lp152.3.6.x86_64
  verwijderen van unity-gtk2-module-0.0.0+bzr20171202-lp152.3.6.x86_64
 Oplossing 2: De volgende acties worden uitgevoerd:
  verwijderen van gmenudbusmenuproxy-5.18.3-lp152.1.4.x86_64
  verwijderen van plasma5-workspace-branding-openSUSE-84.87~git20190606T185118~3d37a0c-lp152.10.1.noarch
  verwijderen van plasma5-desktop-5.18.3-lp152.1.5.x86_64
  verwijderen van patterns-kde-kde_plasma-20181130-lp152.3.1.noarch
  verwijderen van plasma5-desktop-emojier-5.18.3-lp152.1.5.x86_64
  verwijderen van plasma5-desktop-lang-5.18.3-lp152.1.5.noarch
  verwijderen van sddm-branding-openSUSE-0.18.0-lp152.4.10.x86_64
  verwijderen van patterns-kde-kde-20181130-lp152.3.1.noarch
 Oplossing 3: verouderde gmenudbusmenuproxy-5.18.3-lp152.1.4.x86_64 handhaven

Sorry, system is Dutch. :) I chose 1: removal ("verwijderen") of unity*. I don't know if with the right plasma versions available this intervention would have been necessary. Hereafter it is shown what will be done.
Comment 14 Fabian Vogt 2020-04-14 11:47:43 UTC
(In reply to Cor Blom from comment #13)
> The issue was that plasma 5.18.4.1 is not yet available in 15.2, so I had to
> allow come incompatibility. It required manual intervention, the following:

That looks more like the conflicts cause the issue than the version jump.
Can you try just "zypper in gmenudbusmenuproxy-5.18.4.1"?

I'm not sure whether this conflict would be acceptable for a pretty much default upgrade.
What happens if both modules are installed at once?
Comment 15 Cor Blom 2020-04-14 12:10:52 UTC
Manual intervention is still required. The message say that there is a conflict that needs a solution. Then two options, similar like before, but without the plasma version conflicts.

unity-module and appmenu-module can co-exist happily. Looking at a global menu with gimp, when both are installed the appmenu-module is used.

(BTW, in my experience unity-module can be uninstalled without problems, but at a certain stage it wants to be installed again. Some package probably recommends it. Don't know which package. That was at least the case with a TW system, where zypper dup is the normal procedure.)
Comment 16 Fabian Vogt 2020-04-14 13:21:00 UTC
(In reply to Cor Blom from comment #15)
> Manual intervention is still required. The message say that there is a
> conflict that needs a solution. Then two options, similar like before, but
> without the plasma version conflicts.

Ok, so something that has to be worked around...

> unity-module and appmenu-module can co-exist happily. Looking at a global
> menu with gimp, when both are installed the appmenu-module is used.

It seems like both modules are loaded and used - that doesn't sound great. Is there some guarantee that only one (and which one) ends up being effective?

> (BTW, in my experience unity-module can be uninstalled without problems, but
> at a certain stage it wants to be installed again. Some package probably
> recommends it. Don't know which package. That was at least the case with a
> TW system, where zypper dup is the normal procedure.)

Yes, gmenudbusmenuproxy recommends it depending on whether GTK2 and GTK3 are installed.
Comment 17 Cor Blom 2020-04-14 13:47:50 UTC
(In reply to Fabian Vogt from comment #16) 
> > unity-module and appmenu-module can co-exist happily. Looking at a global
> > menu with gimp, when both are installed the appmenu-module is used.
> 
> It seems like both modules are loaded and used - that doesn't sound great.
> Is there some guarantee that only one (and which one) ends up being
> effective?

I do not know. I can only speak about what I see when I use it and it is my impression that when both appmenu-* and unity-* are installed, gmenudbusmenuproxy prefers appmenu-* But I must say I only see a difference with gtk2 apps, as said before. I don't really know anything about the internal workings of  gmenudbusmenuproxy.
Comment 18 Fabian Vogt 2020-04-14 14:14:46 UTC
(In reply to Cor Blom from comment #17)
> (In reply to Fabian Vogt from comment #16) 
> > > unity-module and appmenu-module can co-exist happily. Looking at a global
> > > menu with gimp, when both are installed the appmenu-module is used.
> > 
> > It seems like both modules are loaded and used - that doesn't sound great.
> > Is there some guarantee that only one (and which one) ends up being
> > effective?
> 
> I do not know.

Let's ask the maintainer then.

> But I must say I only see a difference
> with gtk2 apps, as said before. I don't really know anything about the
> internal workings of  gmenudbusmenuproxy.

I just checked QT_LOGGING_RULES=*.debug=true gmenudbusmenuproxy here and it seems to connect to /com/canonical/unity and only after removing unity-gtk*-module it uses /org/appmenu/gtk/. I assume that appmenu-gtk2-module hides the menu bar but unity-gtk2-module is the one actually exporting the menu?
Comment 19 Cor Blom 2020-12-30 00:25:53 UTC
Revisited global menus today and saw that libunity is deleted from Tumbleweed months ago. After having failed to build for weeks.
Comment 20 Fabian Vogt 2022-10-17 18:02:19 UTC
Info was never provided :-/

Here's a SR to switch over: https://build.opensuse.org/request/show/1029582