Summary: | Okular Menu got totally disrupted by changing settings/configuration via menu | ||
---|---|---|---|
Product: | [Applications] okular | Reporter: | JMB9 <jmb_tux> |
Component: | general | Assignee: | Okular developers <okular-devel> |
Status: | RESOLVED WORKSFORME | ||
Severity: | normal | CC: | aacid, jmb_tux, john.kizer |
Priority: | NOR | ||
Version First Reported In: | 24.12.2 | ||
Target Milestone: | --- | ||
Platform: | Neon | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Attachments: | Screenshot showing broken menu structure with 'no text' and my choice for toolbar - which may caused this |
Description
JMB9
2025-02-25 14:30:53 UTC
This happens to people, but no one has been able to give us a way to reproduce it, so it remains unfixable for now. You can fix it locally by removing the files in ~/.local/share/kxmlgui5/okular (you will lose your customizations when you remove those files). If you find the exact customization steps that you that cause this breakage please tell us. I still hope to reproduce it and aimed at making a video with vokoscreenNG to help in reproducing the problem. At 1st I thought the entire configuration would be lost - but when moving "okular" to "OLD_bad_menue_OLD_okular_OLD" in the directory "~/.local/share/kxmlgui5", the menu works as described but all I configured in Settings and okular_part was still there - but just okular_shell was empty - so I changed that - and the menu stays ok. So this seems to be a valid workaround ... but not a point I could start to search for a trigger event so the problem could finally be reproduced. If I remember correctly the breakage of the menu happens quite fast when starting changing okular_part - i.e. putting several things from left to right to make it visible in the toolbar, changing order and deleting a few by putting them from right to left. And that happened reliably in freshly installed KDE neon ... Is it possible to move away all okular configs so I start as if okular was not yet configured in any way (especially losing the config of "okular_part" - as I suspect something here must be the trigger)? With that point I could configure it and if any "no text" label in the menu appears, I should have found a valid trigger ... and can provide the video ... Just out of curiosity: Why is the label "No text" no point to start for finding the problem? I thought it is a label to debug if a label was left empty which should not happen for a menu point ... or what is the use of "No text"? The part configuration is stored in ~/.local/share/kxmlgui5/okular/part.rc
Are you sure removing that file doesn't reset the part configuration?
> Just out of curiosity: Why is the label "No text" no point to start for finding the problem?
We know it's broken, we don't know how it breaks, having a way to reproduce it is the key.
I was waiting for Ocular 25.4.0 to make a video to get a reproducible bug about the trashed menu. Unfortunately I was shocked when seeing a new bug in Ocular, that instead of cursor up/down just going to a previous/next entire page only getting some lines up/down, while the former behavour is now in cursor left/right. And to make it worse - also Page Up/Down does the stupid thing which does cursor up/down now. This is an extreme regression - ones again - and I am using faith in LDE developer fixing the mess KDE 6 was (incl. Framework, Gears etc.). Updating status as this is pending steps to reproduce from the reporter. ๐๐งน โ ๏ธ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME. For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging. Thank you for helping us make KDE software even better for everyone! ๐๐งน This bug has been in NEEDSINFO status with no change for at least 30 days. Closing as RESOLVED WORKSFORME. |