... in some scenarios at least. e.g. having: [General] BrowserApplication=firefox within /etc/xdg/kdeglobals and if user changes that to e.g. [General] BrowserApplication[$e]=chromium-browser.desktop within ~/.config/kdeglobals, after logout-> login, one finds [General] BrowserApplication[$e]=chromium-browser.desktop BrowserApplication=firefox in ~/.config/kdeglobals (thus effectively makes firefox again default browser) i am not 100% sure this is kconfig bug, or some app/components is misusing API, but will start at the source ;-) Reproducible: Always
Hi Hrvoje, I looked into your report, I wasn't able to see anything obvious in the code that should trigger this. I tried just reproducing this, but I have not been able to so far. To test, I created /etc/xdg/kdeglobals, filled as you had. I created a new user, verified firefox started. I then changed the settings in systemsettings, logged out, logged in, and verified chrome now starts. Checking the file, it has the correct the contents. Could try reproducing with a fresh user, and see if that helps? If it does not, can you give me an exact set of steps to reproduce, including any apps that start on login, etc? If it does, can you let me know what software you have installed/what distribution you use?
yep, i can always reproduce with a clean config. steps to reproduce are, as written: have /etc/xdg/kdeglobals with [General] BrowserApplication=firefox inside; start a plasma 5 session with a clean user, change default browser either with kcm, or by hand in ~/.config/kdeglobals, logout, login -> observe the ~/.config/kdeglobals, it has both firefox and browser added by user
so i have now tried again to see does 915976c1238be811f169eab1b02f7e8dad6410e0 have some effect, and can no longer reproduce this behaviour =)
Excellent! I'll marked this as resolved then. I'm not sure why that commit fixed the issue, as I didn't have it applied when I tested. Out of curiousity, what version/commit where you using when you first reported the bug?
i am constantly using master, but somehow had a feeling this is related to kconf_update, as this issue happens only with startkde (e.g. using a clean account with just KDE vars exported + starting e.g. lxqt produces correct behaviour) what i wonder, is there actually API misuse in kde4breeze? ([breeze.git]/misc/kde4breeze/src/main.cpp) i'm seeing a lot of group.sync(), which to me it seems it copies the values from systemwide kdeglobals? or i am interpreting incorrectly?
Repoening due to bug #343583, to track the KConfig related aspect. It appears that having KConfigs pointing directly at kglobalconfig, and using KConfigGroup::copyTo on a standard KConfig appears to cause this issue. Specifically, kcm_lookandfeel can reliably trigger this, apparently due to the foreach loop in krdb.cpp:679.
I'm seeing this on a Fedora 21 system with Plasma 5.2.0 as well - every font and theme settings line in ~/.config/kdeglobals ends up repeated, once the defaults and once my own settings, so in effect the settings don't stick and I get defaults.
With http://quickgit.kde.org/?p=plasma-desktop.git&a=commit&h=1c56fb2195511f4a2e5ff6e94d70dafedb11657e http://quickgit.kde.org/?p=plasma-desktop.git&a=commit&h=b2fc8174d5733fe3b051f839944870b4f51b8c52 http://quickgit.kde.org/?p=breeze.git&a=commit&h=7272e6914ef9b756bbbeb132b63a4e39a79f11e9 i'm no longer seeing the described problem (which doesn't mean bug is gone, just appears the triggers for it are fixed - for now)
I can't select another webbrowser than firefox on OpenSuSE because /etc/xdg/kdeglobals says BrowserApplication=firefox. The use of SimpleConfig when saving means that writeEntry() with an empty QString does nothing, because KConfig doesn't see that there is a more-global value to override explicitly.
commit 27ebf75bd4 should fix this for good, thanks Hrvoje