The XDG discussion about XDG_STATE_HOME made me realize that "things we would want in a VCS" should be in ConfigLocation.
kxmlgui5/app/appui.rc is definitely configuration, and should therefore move to ConfigLocation.
I think we just didn't dare create directory structures within the old kde3/4 config dir, but now in ~/.config it's actually pretty common.
If we're changing that 5 into a 6 anyway, this won't create an additional migration issue.
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Open | None | T12202 KXmlGui | ||
| Open | None | T12409 Move kxmlgui files from GenericDataLocation to ConfigLocation |
Proposed implementation:
Question raised during that:
Currently "kxmlgui5/" is used as root dir, and then apps put their ui files into a subdir "kxmlgui5/APP". Is there any need for that order, instead of having this "APP/kxmlgui5/" instead? I.e. are there any utils which look up all the subdirs of kxmlgui, instead of just using one subdir based on APP?
Given you @dfaure proposed to use ConfigLocation, not GenericConfigLocation, this made me look at https://doc.qt.io/qt-6/qstandardpaths.html#StandardLocation-enum and wonder if not instead AppConfigLocation should be used?
Afterall ConfigLocation on Windows has APP already in the dir ("C:/Users/<USER>/AppData/Local/<APPNAME>", "C:/ProgramData/<APPNAME>"), so that would be duplicatd there Thus for now I used GenericConfigLocation in the propossed MRs to use the variant without the duplication.
By switching to AppConfigLocation instead for human file browsing in the config dir things would make more sense, by being more consistent and also being able to handle all app related config together, instead of having ui.rc config in a separate world still?
@dfaure Any chance on your "old-timer knowledge" on the question whether to keep using "kxmlgui5/APP" (i.e. GenericConfigLocation/ConfigLocation) or to instead switch to "APP/xmlgui5" (i.e. AppConfigLocation)?
The latter seems to me more intuitive, bundling config data per app, not per technology. Might e.g. help people who want to manually remove or copy app config around. So I would be motivated to adapt the MRs linked above to switch to app-centric locations instead, unless there is a good reason to keep the storage location technology-centric?
I wrote ConfigLocation without much thinking as to whether that should be the Generic variant or not. The main point was: not in state.
I see your argument in favour of APP/xmlgui5 (well, 6?), feel free to go for that. I indeed cannot think of a good reason to group by technology.
You'll have to think about the case of the QRC path too, which iirc was :/xmlgui5/APP?
Thanks for the input, good to have :)
Okay, will then go for that.
Yes, with the change in the location pattern and thus breaking the spec, switching to 6 in the naming makes sense now to me.
For KDE_INSTALL_KXMLGUIDIR having now a variable in the final dir, that will be a new kind of thing. Guess we have to instruct people to use KDE_INSTALL_CONFDIR/app/kxmlgui6 manually, where they still use KDE_INSTALL_KXMLGUIDIR. And to my joy I just found/learned that there actually is a way to deprecate CMake vars, so at least for those who do read build logs there is a gentle way into the future.
For the QRC path, yes, guess we should adapt the order as well, for consistency. Fear that will result in some "joy" with Qt5/Qt6-same-branch projects, needing to template the qrc files... oh well. No pain, no gain...
Updated functionality:
Found that AppConfigLocation actualy cannot be directly used, as plugins have their separate component name to use in place of the appname. So sticked with GenericConfigLocation/cpmonentName, which though is pretty the same as AppConfigLocation for apps anyway.
Sample consumer adaptions:
Especially the Kate one shows the pain with the qrc files and the desire to use a different path with the same sources... meh... anyone a better idea?
In https://invent.kde.org/frameworks/extra-cmake-modules/-/merge_requests/374#note_745927, @krop comments:
Although technically correct, I'm not particularly happy to see ui files being installed in XDG_CONFIG_DIR by default. There's nothing a system administrator should touch. I'm not convinced that's the right move.
Sounds like the approach in the current MRs needs some more design first. Let's reflect on the current state:
The main idea of this task would be about the admin/user customization, i.e. overriding any build-time defaults. Those overrides would not be using KDEInstallDirs locations, as they do not want to change the installed data, given that the next package update would replace them again. Also is there a need to be able to reset to defaults, and that default data needs to be somewhere present, read-only.
Default read-only config file, where to place
For historic reasons currently the default data (blob) can be deployed both as separate file as well as baked-into-binary via a Qt resource (or both for development needs). The purpose of the KDE_INSTALL_KXMLGUIDIR variable is to support the separate file approach. The idea to switch to CONFDIR here was mainly driven by the implementation which uses QStandardPath look-up, so placing the file in the proposed location would nicely integrate into the first-in-ordered-list-of-path look-up logic around GenericConfigLocation . With DATAROOTDIR as base and GenericDataLocation this was read-only by design. Whereas GenericConfigLocation seems to cover only read-write locations, corect?
So should it be rather SYSCONFDIR than CONFDIR (cmp. https://api.kde.org/ecm/kde-module/KDEInstallDirs6.html) where the read-only default file is installed to? Though prefix/etc or /etc (the path here) are not part of QStandardPaths look-up locations (and for other platforms KDEInstallDirs fails to document the values), so that does not work with the single QStandardPaths::locate(GenericConfigLocation) lookup.
Looking for other users of the CONFDIR var, I find a set of KDE apps deploys rc file there, would that not also be broken? E.g.
install(FILES konsolerc DESTINATION ${KDE_INSTALL_CONFDIR})Any pattern for look-up of single deployed non-overwriteable data file?
If we have to look-up the default file in a separate way, that should be done with the least minimal needed filesystem stats. As there should be only one file, and we should not "search" for it, but know where to find it. And this should work also with relocatable app bundles. Anyone would know how this is solved elsewhere?
Separate ui.rc file has development purpose
Most simple would be to just discard the option for separate file install, and require with KF6 to have the default as Qt resource. But from experience of development with KXmlGui-based programs, it can be useful to have a separate file to test/debug things by just changing the deployed file and restart the app, instead of having to go full circle of rebuilding the binary. Abusing the user customization override file would prevent some kind of testing, one really wants a separate file in the install prefix to toy around with.
I think having that in /etc is very wrong as most applications totally break or even crash on any non-trivial modification of this and /etc somehow implies this is config.
The files in the config dir in the home are only meant to be written by the shortcut config and Co. and not manually altered.
In Kate and Co., if you just remove some menus or toolbars in the worst case it will just crash.
An ui file for KXmlGui is in that respect more or less like a QML file, you would not install that in /etc either. It must match the current application version, every non trivial change might be fatal. You can do customization in the QML but that is not intended.
A configuration file that is modified by a GUI, is still a configuration file.
This isn't about editing with a text editor or not, it's about whether you want such a file to be backed up and synced between computers. I'd say yes, for local xmlgui files. If you spend 1h setting up 50 shortcuts and customizing your toolbar, you want that backed up.
I'm pretty sure many many things would break upon non-trivial modifications of files in /etc, surely? I can't see how that's an argument against it.
And /etc/mplayer/menu.conf is very much like xmlgui.... It's XML that defines a GUI...
The problem is that package managers will not overwrite /etc stuff on install, that will lead very easily to issues.
As said, I see the point for the user local config, why not in .config, all fine for me.
But I would like to have the shipped ones as data, that allows to be sure updates will enforce the new state is used.