Bug 416731 - kxmlgui stores configuration in XDG_LOCAL_HOME
Summary: kxmlgui stores configuration in XDG_LOCAL_HOME
Status: ASSIGNED
Alias: None
Product: frameworks-kxmlgui
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: unspecified
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: kdelibs bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-01-25 09:41 UTC by Ben Creasy
Modified: 2022-11-28 23:24 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ben Creasy 2020-01-25 09:41:50 UTC
SUMMARY

Using the example of Okular, refiling https://bugs.kde.org/show_bug.cgi?id=416729:

The configuration files for Okular includes a particularly surprising place at ~/.local/share/kxmlgui5/okular/shell.rc which prompts questions https://askubuntu.com/questions/1090285/where-does-okular-store-its-config-files. It should be moved to XDG_CONFIG_HOME per https://bugs.kde.org/show_bug.cgi?id=397602 with any state remaining in XDG_LOCAL_HOME.

There's also ~/.config/okularpartrc and ~/.config/okularrc and the latter contains state data (State, Height, Width) which should be moved to XDG_LOCAL_HOME.

STEPS TO REPRODUCE
1. Follow steps in AskUbuntu question to see the configuration file pop up.
2. 
3. 

OBSERVED RESULT


EXPECTED RESULT


SOFTWARE/OS VERSIONS
Windows: 
macOS: 
Linux/KDE Plasma: 
(available in About System)
KDE Plasma Version: 
KDE Frameworks Version: 
Qt Version: 

ADDITIONAL INFORMATION
Comment 1 Nicolas Fella 2020-08-22 10:01:48 UTC
As for the .rc files, we plan to move those to XDG_CONFIG_HOME, but it is unclear whether that will happen before KDE 6. See https://phabricator.kde.org/T12409

As for the window state: That indeed belongs into XDG_LOCAL_HOME, I proposed to move it there
Comment 3 Björn Bidar (Thaodan) 2022-11-25 13:46:16 UTC
(In reply to Nicolas Fella from comment #2)
> See https://invent.kde.org/frameworks/kxmlgui/-/merge_requests/13

Is this bug therefore a duplicate?