Version: (using KDE KDE 3.4.0) Installed from: RedHat RPMs OS: Linux Upgrading from 3.2.2 to 3.3.3, and then from 3.3.3 to 3.4, I lost all my toolbar customizations, in KMail, Konqueror and KNode at least. All my other settings carried along just fine. Are toolbar settings treated differently somehow, or not portable across versions?
exactly. If the application changes it's config version, all old settings are discarded
*** Bug 99123 has been marked as a duplicate of this bug. ***
*** Bug 107264 has been marked as a duplicate of this bug. ***
Also see my note in Bug 107264 : The toolbar editor is still showing the old toolbar layout, while the toolbars are actually changed by the upgrade. Adding one icon to the toolbar, removing it again and pressing 'apply' restores the toolbar to the state before the upgrade. That really sounds like a bug. It seems like you think it's natural for an application upgrade to destroy the toolbar settings. I don't think it's natural at all, because the toolbar settings are stored locally in my own .kde dir. The application itself is upgraded, as well as it's global configuration files. But the toolbar settings are not touched by the upgrade so they should not need to change.
On Sunday 12 June 2005 16:53, Dik Takken wrote: > But the toolbar settings are not touched by the upgrade so they should not need to change. The upgrade ships a new XML file, which possibly provides new actions in both menus and toolbars; so we have to discard the local XML file (we only ship over the key shortcuts). Hmm. Maybe we need a separate version number for the toolbars and some code to copy the customized toolbars *if* the toolbars-version-number didn't change during an upgrade. Developers would have to remember to increase both numbers or only one number when they make a change, depending on whether the toolbars were changed too...
> The upgrade ships a new XML file, which possibly provides new actions in both menus and toolbars Yes of course, new actions will show themselves after the upgrade. I wouldn't expect anything else. > so we have to discard the local XML file (we only ship over the key shortcuts). Why discard the local XML file? My local XML files tell KDE not to show the Cut/Copy/Paste actions. Why do we need to discard that information after an upgrade? The only problem I see (but I'm no expert) is that the Cut/Copy/Paste actions could have been removed in the new version. In that case, the "Please don't show Cut/Copy/Paste" section in the XML file doesn't make sense anymore and can be ignored. Problem solved. Wait a minute... Maybe the toolbar XML files don't contain changes relative to the global toolbar config (Somehow I assumed they did), but a completely new toolbar description that overrules the global one. If that's how it works, I see the problem of upgrading them. I guess we need the local XML file to contain some sort of a blacklist of actions we don't want to see, not a customised copy of the global XML file.
*** Bug 109671 has been marked as a duplicate of this bug. ***
I also have that problem. For me it is basically WRONG that each release of KDE require reconfiguration of apps. When I upgrade local system I don't like having to explain each plain user why their configurations got lost when they run mail program. It is annoying and waste of time.
forgot to add system infos: Debian 'sid' KDE 3.5.0 from alioth (upgraded from 3.4.3/sid)
*** This bug has been confirmed by popular vote. ***
It'd be cool not to lose toolbar settings
I fixed this for KDE-4.0.x last year, but forgot to close this report. r733653 | dfaure | 2007-11-07 01:58:17 +0100 (Wed, 07 Nov 2007) Implement "keep the user's toolbars when the application's xmlgui file has been updated". kdelibs/kdeui/xmlgui/kxmlguiversionhandler.cpp