[patch] workaround customised toolbar reset

Leo Savernik l.savernik at aon.at
Tue Nov 6 19:00:51 GMT 2007

Am Dienstag, 6. November 2007 schrieb David Faure:
> > 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. 

This is BIC, this is not allowed. BC doesn't end at the C++-level.

> 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].

I had that idea, too. However, it needs more time to have it fixed and 
thoroughly tested. I'll keep it at the back of my mind.


More information about the kde-core-devel mailing list