I don't use it but did some digging. Found posts of users of other distros having the same problem an suggesting installing appmenu-gtk2-module (vala-panel-appmenu on Solus) solves the problem, but that is already installed.

We need to create the file: /usr/share/defaults/etc/profile.d/appmenu-gtk2-module.sh

Containing the lines:

GTK_MODULES=gail:atk-bridge:appmenu-gtk-module
export GTK_MODULES

Reboot, an it loads instantly.

Source: https://forums.linuxmint.com/viewtopic.php?p=1982045&sid=66d7a9a988d2d1375904f9830d8e6c9d#p1982045

Arch has:

#!/bin/sh

if [ -n "$GTK_MODULES" ]; then
    GTK_MODULES="${GTK_MODULES}:appmenu-gtk-module"
else
    GTK_MODULES="appmenu-gtk-module"
fi

if [ -z "$UBUNTU_MENUPROXY" ]; then
    UBUNTU_MENUPROXY=1
fi

export GTK_MODULES
export UBUNTU_MENUPROXY

https://git.archlinux.org/svntogit/community.git/tree/trunk/80-appmenu-gtk-module.sh?h=packages/appmenu-gtk-module&id=9e8b4142392e3ed9d505043c44effb960f755df4

Just out of curiousity, for those that have the issues. Running x11 or wayland?

We don't support Wayland so probably not related.

I think something like this is more appropriate for us:

#!/bin/sh

if [ -n "$GTK_MODULES" ]; then
    GTK_MODULES="${GTK_MODULES}:appmenu-gtk-module"
else
    GTK_MODULES="appmenu-gtk-module"
fi

export GTK_MODULES

I can confirm that @DataDrake's script allows Hexchat to load instantly again. @JonnyCodewalker noticed a similar problem with Audacity, but that isn't fixed by this script, so it might be a different issue.

Incidentally, I submitted an update for vala-panel-appmenu, not realizing that it was the package that @Harvey referenced above (installing/updating it had no effect for me, for what it's worth). If the script has to be installed with it, I can add it, or someone else can push it and I can rebase my patch.

Does this need to be a profile script? Or can it be a wrapper script around the binary instead?

So my system didn't have vala-panel-appmenu so I had to add it as a run dep of Hexchat. I also tested and a wrapper script is fine for setting that environmental variable (I think using a wrapper script is the safer approach as it has less of a chance of affecting other things unexpectedly).

If someone on this issue that knows how to compile packages wants to try out that revision and see if it fixes the issue for them then that would be much appreciated!

The same issue also affects e.g. anki and keepassxc, and is fixed by the script above.

Given that multiple applications are affected and that the script I suggested only appends to available modules for GTK, it makes the most sense to solve this with a profile script in vala-panel-appmenu and then make sure it is a rundep of the affected programs.

Now that I think about it, weren't there big changes to menus in GNOME 40? This could be fallout from that.

Changed the title to increase visibility so that people can report any other affected programs.

Mediainfo, Grsync & WinFF also seem to be affected by this.

@DataDrake I think this variation on that function might be slightly better so as to avoid the possibility if appmenu-gtk-module from being appended multiple times (which I noticed could happen if you launched something from a terminal):

#!/bin/sh

if [ -z "$GTK_MODULES" ]; then
    GTK_MODULES="appmenu-gtk-module"
elif [[ ${GTK_MODULES} != *"appmenu-gtk-module"* ]]; then
    GTK_MODULES="${GTK_MODULES}:appmenu-gtk-module"
fi

export GTK_MODULES

@ReillyBrogan Not sure what your system did to make that happen, but the whole point of profile.d is that it only gets sourced once, making that kind of check unnecesary. On my system where I tested this, I specifically tested that that didn't happen before I added the script to the package.

Since update:
Can confirm what @Staudey reported about keepassxc: wildly inconsistent. Links/unlinks inconsistently/erratically today.
Grsync will not launch from budgie menu. Launches fine from terminal.
Budgie.
All the rest of my go-to menu stuff, including browsers/themes seems unaffected as far as GTK and this update
Only submitted to access variables.

@brent this point the issue is well-understood and a fix exists. We're still trying to understand which packages are affected as we need to add the fixed vala-panel-appmenu as a dependency so we make sure the fix gets installed alongside the package.

Thank you for reporting that the keepassx and grsync seem to be having this issue for you. Someone has already tested Keepass but it would be very helpful if you could install the fix and let us know if it helps with grsync (so that we know to add the dependency).

Can you please download and install this updated package from the Solus unstable repo?
Just download it with your browser and then run the following from the folder it's in to install it:

sudo eopkg install ./vala-panel-appmenu-0.7.3-11-1-x86_64.eopkg

And then reboot your system. After you log back in check to see if grsync is back to normal and report your findings.

@Katoa if you could test Mediainfo, winff, and grsync with the above steps it would be appreciated as well.

vala-panel-appmenu absolutely should not be runtime dependencies of these applications. The associated changes related to menus were made over a year ago, do not apply to Budgie, were not changed in GNOME 40. The appmenu-gtk-module is not required to run these applications and has absolutely no relation to the functionality in GNOME Shell 40. It is not installed on my system and I do not have the respective startup issues you are facing with Hexchat, KeepassXC. My GTK_MODULES as an example only has gail:atk-bridge.

In that case I will remove the dependency from anki again when I get home today.
Still, without the appmenu-gtk-module in profile.d the startup times were extreme, as described above. In my case under Budgie. Will try to get some logs or sth later.

Here is my relevant hexchat strace.

All openat calls.

GTK specific.

Hexchat with appmenu not part of GTK_MODULES (slow start)

Hexchat WITH appmenu part of GTK_MODULES for direct comparison (fast start):

The issue facing @ReillyBrogan stems from 25.024526 write(11, "\1\0\0\0\0\0\0\0", 8) = 8

The closest FD I'm seeing to that is:

0.000017 openat(AT_FDCWD, "/usr/lib64/gio/modules/libgvfsdbus.so", O_RDONLY|O_CLOEXEC) = 11
0.000011 read(11, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0@\317\0\0\0\0\0\0"..., 832) = 83

Then a timeout associated with dbus:

0.000019 connect(9, {sa_family=AF_UNIX, sun_path="/run/user/1000/bus"}, 110) = 0
0.000010 sendmsg(9, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\0", iov_len=1}], msg_iovlen=1, msg_control=[{cmsg_len=28, cmsg_level=SOL_SOCKET, cmsg_type=SCM_CREDENTIALS, cmsg_data={pid=25613, uid=1000, gid=1000}}], msg_controllen=32, msg_flags=0}, MSG_NOSIGNAL) = 1
0.000016 sendto(9, "AUTH\r\n", 6, MSG_NOSIGNAL, NULL, 0) = 6
0.000017 recvfrom(9, 0x55fb0f835400, 4096, 0, NULL, NULL) = -1 EAGAIN (Resource temporarily unavailable)
0.000010 poll([{fd=9, events=POLLIN}], 1, -1) = 1 ([{fd=9, revents=POLLIN}])
0.000011 recvfrom(9, "REJECTED EXTERNAL\r\n", 4096, 0, NULL, NULL) = 19
0.000018 sendto(9, "AUTH EXTERNAL 31303030\r\n", 24, MSG_NOSIGNAL, NULL, 0) = 24
0.000013 recvfrom(9, 0x55fb0f835400, 4096, 0, NULL, NULL) = -1 EAGAIN (Resource temporarily unavailable)
0.000011 poll([{fd=9, events=POLLIN}], 1, -1) = 1 ([{fd=9, revents=POLLIN}])
0.000013 recvfrom(9, "OK 14b990da4b7787fd42c9456a608e1"..., 4096, 0, NULL, NULL) = 37
0.000014 sendto(9, "NEGOTIATE_UNIX_FD\r\n", 19, MSG_NOSIGNAL, NULL, 0) = 19
0.000012 recvfrom(9, 0x55fb0f835400, 4096, 0, NULL, NULL) = -1 EAGAIN (Resource temporarily unavailable)
0.000009 poll([{fd=9, events=POLLIN}], 1, -1) = 1 ([{fd=9, revents=POLLIN}])
0.000010 recvfrom(9, "AGREE_UNIX_FD\r\n", 4096, 0, NULL, NULL) = 15
0.000012 sendto(9, "BEGIN\r\n", 7, MSG_NOSIGNAL, NULL, 0) = 7
0.000015 write(12, "\1\0\0\0\0\0\0\0", 8) = 8
0.000013 eventfd2(0, EFD_CLOEXEC|EFD_NONBLOCK) = 11
0.000010 write(11, "\1\0\0\0\0\0\0\0", 8) = 8
0.000020 write(12, "\1\0\0\0\0\0\0\0", 8) = 8
0.000010 poll([{fd=11, events=POLLIN}], 1, 25000) = 1 ([{fd=11, revents=POLLIN}])
0.000011 read(11, "\1\0\0\0\0\0\0\0", 16) = 8
0.000010 poll([{fd=11, events=POLLIN}], 1, 25000) = 0 (Timeout)

Would like straces of any other programs that may be affected. Can typically be done by running: strace -r PROGRAMNAME 1>PROGRAMNAME-log 2>&1

Grsync:

dbus-monitor log:

@ReillyBrogan Mediainfo, Grsync & Winff started instantly with the updated vala-panel-appmenu-0.7.3-11-1-x86_64.eopkg.

Rolled back to vala-panel-appmenu-0.7.3-10-1-x86_64.eopkg and rebooted, before i started the strace logs.

Mediainfo-gui log:

Edit > Have the logs with vala-panel-appmenu-0.7.3-11-1-x86_64.eopkg installed, if that is in any way useful...

Just wanted to note that even though i have the 20+ sec. delay with Mediainfo-gui, Grsync & Winff, i have no delay launching Hexchat or Keepassxc. Tried launching Hexchat 10 times and Keepassxc 50 times.

strace output with vala-panel-appmenu not installed:

KeepassXC:

Anki:

strace logs with vala-panel-appmenu not installed:

Mediainfo-gui log:

The update to vala-panel-appmenu does not appear to have fixed MediaInfo's launch time for me.

In T9696#184384, @Katoa wrote:

Just wanted to note that even though i have the 20+ sec. delay with Mediainfo-gui, Grsync & Winff, i have no delay launching Hexchat or Keepassxc. Tried launching Hexchat 10 times and Keepassxc 50 times.

Without the installation of the external vala package, I can report the Keepass thing fixed itself. Maybe needed a day to work out the kinks,and a reboot, and to my unqualified eye, may be unrelated to this. (I have keepassxc as an autostart program).
Grsync would not launch yesterday, but today is a 10 second lag time. Can live with that.
fyi

@brent we've determined that this is some sort of race condition and will not sort itself out.

In T9696#184392, @DataDrake wrote:

@brent we've determined that this is some sort of race condition and will not sort itself out.

I didn't mean to sound presumptuous-- I had no/intermittent functionality of keepassxc yesterday and full functionality today, and my hypothesis is wrong...so maybe interaction with the keepassxc (firefox store) browser plugin a factor on my end yesterday? Either way--will leave it with the pros.

@brent I just don't want people to get there hopes up at the moment. Josh and I spent a not small amount of today debugging this together and the results were all over the place. That's the trouble with a race condition, any number of things can change the timing just enough to make it appear or disappear, seemingly at random. That's what we were seeing with the fix that I tried yesterday. It seemed to slow things down just enough for the condition to pass, but that's a band-aid when we need stitches.

"...spent a not small amount of today debugging this together and the results were all over the place. That's the trouble with a race condition, any number of things can change the timing just enough to make it appear or disappear, seemingly at random. That's what we were seeing with the fix..."

Gotcha. ^^maddening.

I am not sure what was the cause, however at a certain point the entire system started lagging (starting with the mouse), however a reboot not only fixed that, but also MediaInfo's slow startup.

Now it only takes ~3 seconds for MediaInfo to start up cold (i.e., first start after boot), and less than a second for subsequent launched (and this is on an HDD, albeit a 7200RPM HDD).

Should be resolved as of R1126:43b5d78138a4: Revert ProxyVolumeMonitor free of proxy object.

Restartet my pc 4 times and launched the apps several times in random order, for me everything is back to normal with Mediainfo, Grsync, WinFF, Audacity (had no issues with Hexchat & Keepassxc), they all start without delay as they used to.

Thank you so much for fixing this, expected this to take much longer to pin down, great job!

Edit - My stable installation is also back to normal behavior, after installing the updated package mentioned on the forum.

Can confirm that KeepassXC and Anki launch normally again after the gvfs update.