4 'Kickoff' menu issues in a fully-updated tumbleweed system

In the fullscreen ‘dashboard’ menu alternative, I can execute either of two remaining ‘Favorites’ from the left column. But the all of the other submenus (right column) will only pop up their icons into the middle area for a moment before the icons vanish. That includes even the self-generated and self-maintained “All Applications” submenu.

The ‘Application Menu’ alternative has the same issue. It does not try to show ‘favorites’ at all, but all of the sub-menus create only temporary pop-ups on the screen, those secondary pop-up panels quickly vanish.

The ‘Application Launcher’ alternative does work, with only two smaller issues regarding the ‘favorites’ list. #1, I can only remove items, I can’t add any new apps. and #2, my nearly empty 'favorites list cannot be moved from the top of the categories. I always have to drag the mouse down into a category I created in the editor for ‘more favorites’. (Not a huge deal, but the problem bugs me every single time.)

Right click of the plasmoid icon offers ‘Edit Applications’ as a separate entry from ‘Enter Edit Mode’, even though the invoke the same editor. That editor is unable to manage ‘favorites’ in any way, because favorites are hidden in a weird database I can’t touch. (‘All Applications’ is probably generated dynamically as well, but the other entries are kept in a regular text file.)

How many different bug reports should I create on these things? I don’t have a ton of time next week, but will test with a new userid. I use Wayland with scaling. Does anyone have hints for testing or bug reporting?

Thanks in advance.

Hm, not reproducible here on different TW installations (up to date and all Wayland). Did you already test with a fresh user profile?

Favorites are added/removed only via right click on the app in the dashboard/application menu and not via the menu editor…

I am also Wayland but my current profile has migrated through several versions (and contains likely damaging ‘cruft’.)

As I described, right click of a selected application to offer ‘add to favorites’ does not work at all, it can only remove (when an application within favorites has been selected). I have not yet truied a “fresh” profile, because the migration of app config files and runtime data would take many hours. I will agree that the problem likely wouldn’t exist in a new profile – but where the heck is that database, and what tool can I use to fix it?

@hui means:

  • create a new user
  • logout as your user
  • login as the new user
  • see if issue exists for the new user

As I described - the new profile would be useless for me. I understood the request from @hui just fine (and I had already proposed that test myself). My “best” help on the issue would be how to edit the database table or have it rebuilt .

Probably the Desktop Menu Specification is what you are looking for.

Try kbuildsycoca --incremental.

Thanks! my /usr/bin contains both a ‘kbuildsycoca5’ and a ‘buildsyscoca6’. Version 6 runs without error, but version 5 complains about a missing merge tag in an un-named file.

When I test whether YAST Software is willing to remove ‘kservice’ version 5.116.x, YAST warns that ‘kf6-service’ (and many other things) depend on the legacy version 5 package. I also see some files from 2020 within ‘/etc/xdg/menus’, along with an empty directory named ‘applications merged’. The presence of that directory might be pushing new ‘add to favorites’ into broken legacy paths which have not been tested by anyone else.

It is getting too late to look at the other XML-formatted menu locations, but I suspect that other old baggage is the cause of my problem. I’ll try the new UserID after I play some weekend music shows, and then maybe do some tests with other changes. Thanks!

Login as “root”
move your current /home/USER to /home/USER_Backup
make a new /home/USER
change the owner of /home/USER to USER:USER

That gives USER an empty /home (which will get populated with the default settings on first login), you still have a backup of the “old” /home and it saves you the hassle to find all files with ownership USER:USER and change change their ownership to a new UID:GROUP.

PS: In the above you have to adjust USER to your individual situation!

Thanks for your clever backup and and re-creation scheme! I was planning a less efficient “migration” process.

After login, copying non-KDE items from the “Backup” .config into the newly-populated one worked well, except for Brave Browser passwords. I think they are in the older wallet, and a new kde wallet (with an empty brave passwords list) was built when I logged in. My profile, history, and favorites are all intact. I’m not sure how to address that wallet issue, I might look at it tomorrow.

The rebuilt menu works in all 3 alternatives (dashboard, launcher, and pop-up submenus). The “all applications” list was built correctly, I can also add and remove favorites again.

If given a second chance, I would export the Brave passwords first, before constructing the “fresh” home directory and logging in. I may or may not have an easy time swapping the older versus new the wallets.

If you followed post #9 then you should be able to do

  • Logout as USER
  • Login as “root”
  • Rename /home/USER to /home/USER_New
  • Rename /home/USER_Backup to /home/USER
  • Logout as “root”
  • Login as USER
  • Export the brave passwords
  • Move the Export to /home/USER_New/somewhere
  • Logout as USER
  • Login as “root”
  • Rename /home/USER to /home/USER_Backup
  • Rename /home/USER_New to /home/USER
  • Logout as “root”
  • Login as USER
  • Import the brave passwords
1 Like

If the passwords are stored in a KDE wallet, it would be maybe easier to simply copy the password files over. The kwallet files are under ~/.local/share/kwalletd/

1 Like

Definitely!

But I’m not familiar with the brave browser so I don`t know if it uses kwallet.

And one should always keep in mind:

Copying things over from /home/USER_Backup will not only bring back the good stuff but probably the errors as well.

I used both techniques, just to be sure. Solved.

First (as root), I moved the new $HOME directory to a temporary save name, and did rsync to bring some $HOME/.local subdirectories under into that temporary save name. (That included the kwallwet stuff).

Then I moved the old (and bad) save $HOME to match the userid, so that I could log in one last more time to export the brave passwords to a CSV file.

Switched to root and renamed the new $HOME root directory to be active again. I did need to import the passwords from the CSV file, but I am having no other issues.

SOLVED!

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.