Bug 448390

Switching Kate sessions also triggers this issue

I never use Kate and have this issue. There must be some other cause.

KDE Plasma: 5.18.6
KDE Framework: 5.76.0
QT Version: 5.12.7

It renders the KDE desktop nearly unusable. I am limping along by creating desktop icons that invoke the programs I most need to use. Sadly, I do not know the names of all the executables I need. e.g. if I kick off system settings as a normal user, it comes up in normal GUI mode allowing me to only change user changeable settings. If I kick it off as root, it uses VT100 escape codes to manage a terminal window, and the color scheme uses low contrast foreground/background for much of it. (purple-on-black and yellow-on-white should be made illegal, yet are all too common.)

P.S. clicking "save" on kmenuedit doesn't save me. It still doesn't work. At least I can use that to find the apps I need.

> Issue exists under both Plasma and Gnome
GNOME doesn't have an Application Launcher menu; do you mean that their full-screen Activities Overlay is rendered empty in the same way?

P.S. I'd suggest moving this to plasmashell since the problem does not seem to be related to Kate. Kate just does something that bothers plasmashell.

I've learned how to run the menu from the command line:

> plasmawindowed org.kde.plasma.kickoff

It wasn't happy:

https://www.flickr.com/photos/bruce-korb/51993266044/in/datetaken-public/

and that doesn't include all the complaints about trying to run yast2

    Usage: /usr/bin/kdesu [options] command
    Runs a program with elevated privileges.

    Options: [...]
    QSocketNotifier: Invalid socket 8 and type 'Read', disabling...
    QSocketNotifier: Invalid socket 19 and type 'Read', disabling...
    QSocketNotifier: Invalid socket 15 and type 'Read', disabling...
    Unable to start Dr. Konqi
    Re-raising signal for core dump handling.

    [1]+  Segmentation fault      (core dumped) plasmawindowed org.kde.plasma.kickoff

(In reply to bkorb from comment #5)
> P.S. I'd suggest moving this to plasmashell since the problem does not seem
> to be related to Kate. Kate just does something that bothers plasmashell.
Probably, but it won't be easily actionable in plasmashell until we figure out what exactly Kate is doing to trigger it.

I don't use Kate. At all. I haven't the foggiest idea what I might be doing to trigger it, but it is quite consistent. Upon first boot after my install, the menu works just fine. Then it stops working. Once, it came back for a little while. Now it's gone for good. And I am quite weary of re-installing openSUSE 15.3 over and over. :) My solution is a script, but it's pretty tacky:

> $ cat bin/kde-menu 
> #! /bin/bash
> 
> if test $# -gt 0
> then logf=$1
> else logf=/dev/null
> fi
> 
> exec 1> $logf 2>&1 < /dev/null
> exec plasmawindowed org.kde.plasma.kickoff &

So you don't use Kate at all, but then for some reason you had the chance to use a Kate AppImage, and upon opening it, the problem happened?

Does it happen with any other AppImages too? Or just the Kate AppImage?

Does it happen if you open the distro-packaged Kate from openSUSE's repos?

I do not believe that the Kate application has ever run on my system. If it can be run non-interactively via some script I don't know about I also cannot say. For quick text edits, I use vi/vim. For serious editing, I use emacs. Since I wasn't paying attention to exactly when the menu broke, I additionally cannot say what may have been the trigger for me. I can say that on one (and only one) occasion, the broken menu came back for a little while. That happened on this current install. But it is gone now and has been for several days and multiple reboots.

(In reply to bkorb from comment #10)
> I do not believe that the Kate application has ever run on my system.

Then I am confused, because in the bug report, you wrote:

> After Kate starteded up (tested only Appimage version) the (system-wide)
> application menu entries are disappeared. 
So are you saying now that the menu broke *before* you opened the Kate AppImage, and running the Kate AppImage was unrelated? Or something else?

Could we get some clarification?

AH! I see the cause of the confusion: I am not the author of this bug. :)
The author _did_ use Kate.

Oh I see! My bad, sorry. I was confused

Any chance you can narrow down out what action triggers the issue?

Sorry, no, I'm retired now.
I'd have to do a re-install and be told how to track the status of "kickoff."
It's enough effort that I'd wind up asking to be paid.

I was able to trigger the issue  just by starting up Kate. Changing a Kate session also triggers the issue, so I suppose when Kate starts up it loads a Kate session, therefore I would look somewhere the session loading mechanism.

I actually attempted to build Kate from source several times in order to be able to play around with it, however I kind of stuck with some build errors. For example Ubuntu 20.04 ships an older version of Qt5, so I also had to build it as well, which built successfully, but kwindowmanager unable to build due missing Qt5X11Extras cmake files, which infact missing, it also looks like the Qt5X11Extras build produces no shared object files.

Duplicating, deleting, saving (save/save as) sessions also triggers the issue. It looks like every operation which somehow affect the sessions (always) triggers the issue.

One more addition: If session chooser is enabled upon startup the issue is already triggered by the time when the chooser dialog is shown. If I reset the menus by the workaround mentioned, then I select a session it loads up properly without re-triggering the issue. It might not the session loading which cause problem, rather the changes of/in sessions.

Ok, let's move this back to Kate for now since it seems like something in Kate is triggering it, and we should start the investigation there.

Any ideas, Christoph or Waqar?

OK. Back to Kate. But take note: I've never used Kate and I have almost precisely the same symptoms. My guess is that Kate, in the reporter's context, does something that makes kickoff unhappy. On my system, I do some unknown thing that makes kickoff similarly unhappy. Either way, since it's not a pervasive problem, the solution is going to depend on being able to figure out how to reproduce the problem. Pozsgay seems to be able to re-create and fix the problem over and over. I cannot. Perhaps he can be given an instrumented version of Kate & kickoff.

I'm making some progress here. I checked the source code of the kmenuedit to figure out what fixes my menus, and I found the following line particularly interesting:
        KBuildSycocaProgressDialog::rebuildKSycoca(this);
As I figured out KSyCoCa is a configuration cache for KDE, and indeed executing the kbuildsycoca5 command fixes the menus. I suspect there is some caching problem, maybe the AppImage semi-sandboxing mechanism prevents the KDE to detect some changes and rebuild/update the cache properly. My knowledge in KDE internals are very limited, but it looks like this is the good direction. It would be good to test out on a non-sandboxed version as well.

I can no longer reproduce this problem from version kate-21.12.3-???-linux-centos_64-gcc.AppImage. Tested build id 449, but might fixed in earlier versions as well. Tested kate-22.04.0-485-linux-64-gcc.AppImage as well, bug neither reproducable here.