[patch] workaround customised toolbar reset

[David Faure]

On Monday 05 November 2007, Leo Savernik wrote:
> Am Montag, 5. November 2007 schrieb David Faure:
> > > I'm reposting the workaround patch to make user changes to toolbars
> > > stick. It's temporary but way better than the current situation.
> >
> > Better? Really?
> > This would mean that any new menu item in a kde application will not appear
> > to the users anymore. I strongly object to this patch.
> 
> The current implementation annihilates users' efforts -> dataloss. Dataloss 
> bugs are severe by definition.
> 
> However, not spotting new menu items is actually no problem at all. You don't 
> know about them therefore you cannot miss them -> no perceived defect.

I really disagree. Imagine if some app developers replaces a menu item
with two equivalent ones, with different names. Like file_new being splitted into
file_new_message and file_new_event. The code will not create the file_new action
anymore, but the two new ones instead. If the user has a local rc file with INT_MAX
as the version number, then that file will be used, which specifies file_new.
But this action doesn't exist anymore => a menu item will disappear!
Now who's talking about "data loss"?

Forcing the use of an old rc file is NOT a solution. At least fix the code so that the user
toolbar gets copied into the new rc file when merging, but really the menus have to
come from the app rc file, since otherwise they won't match the actions [and unlike
with toolbars, the user has no way to fix that].

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).