Overwriting default menu entry locations

[Friedrich W. H. Kossebau]

Am Dienstag, 13. Januar 2009, um 20:44 Uhr, schrieb Friedrich W. H. Kossebau:
> Am Dienstag, 13. Januar 2009, um 20:24 Uhr, schrieb David Faure:
> > On Sunday 11 January 2009, Friedrich W. H. Kossebau wrote:
> > > Result: The action appears currently twice, in the menu "Go", as
> > > defined in ui_standards.rc, and in the menu "Document", as defined by
> > > kateui.rc.
> >
> > That's unrelated to the rest of this thread, it's how xmlgui merging
> > works... kateui.rc should define a Go menu with noMerge="1" to overwrite
> > the default Go menu from ui_standards.rc
>
> There is no Go menu in kateui.rc. And just
>   <Menu name="go" noMerge="1">
>   </Menu>
> doesn't seem to do it, creates an unnamed empty menu, as expected. So how
> do you think this can be solved, then?
>
> Would it be a good idea to write out a warning if there is a redefined
> location (if a merge blocker was forgotten)? The minute this email came in
> I just had started to have myself a look to solve this- So I am in the mood
> to find the place for such a warning :)

Hm, looks to me like is not a simple fix:
In KXMLGUIBuilder a merge blocker only works on the top level and menu level, 
and the checks for globally defined (findMatchingElement()) are only done on 
the same level in the same subtree, so the same name in two different 
subtrees will not be found.
A check in all parallel subtrees might be too expensive (due to being part of 
the program startup).
For XMLGUIFactory a check for doublettes also seems to come with too high 
costs.
Right?

So redefining the location of a default action into another menu than the 
default one is not supported, currently. Good, or no good?

A workaround for Kate might be to rename the action identifiers with some Kate 
specific ones. But I feel this smells a little... also breaks user configured 
toolbars from 4.{1.0}...

Cheers
Friedrich
-- 
Okteta - KDE 4 Hex Editor - http://utils.kde.org/projects/okteta