Bug 186382

Created attachment 31850 [details]
Screenshot showing problem

Created attachment 31851 [details]
Patch which seems to fix the problem

Applying this patch to akregator_shell.rc appears to fix the problem, the menu bar appears in the correct order (File - Edit - View - Go - Feed - Article - Settings - Help).  The added entry ("Foo" in this case) can be anything which is not already a valid XMLGUI tag.

Maybe this is a general XMLGUI problem with completely empty (shell) entries being ignored and additional (part) entries having nowhere to merge into?

A similar thing happens with Marble, the menu bar order is File - View - Help - Edit - Settings.  Suspect that this may be a general kdelibs problem, will investigate and reassign if necessary.

Add kuiviewer to the list. The menus order is the same as when XDG_DATA_DIRS is not correctly set.

The problem in kdelibs seems to be r912265 to kdeui/xmlgui/kxmlguiclient.cpp.
Reverting this to the original behaviour (return 'true' immediately and not go on to check for and delete empty nodes) makes Akregator and Marble display their menus correctly.  The revert is:

--- kxmlguiclient.cpp   (revision 956772)
+++ kxmlguiclient.cpp   (working copy)
@@ -300,7 +300,7 @@
     if ( additive.attribute(attrNoMerge) == attrOne ) // ### use toInt() instead? (Simon)
     {
         base.parentNode().replaceChild(additive, base);
-        base = additive;
+        return true;
     } else {
         // iterate over all elements in the container (of the global DOM tree)
         QDomNode n = base.firstChild();

Ouch. No good solution. Either we remove empty menus (like my patch does), or we assume that something is going to populate them later on (like akregator does) ... but we can't be sure the app is going to do that...

Sounds like empty menus should be removed at the qmenubar level rather than at the xml level, a bit like qt4's double-separator cleanup...
Maybe this can be done in finalizeGUI, if creating+removing menus doesn't have time to flicker.

But that, in turn, would break menus that are populated in aboutToShow()...

Hmm, Friedrich, can you remind me what was the use case for defining but removing empty menus?

David, IIRC the use case was that some programs (e.g. Kate) placed standard actions in non-standard containers. Which is not really supported, instead it results in the action being placed both in the standard and the new container, also if the standard container was not used, so making it used. You proposed to hack this by adding the standard container, but with a noMerge="1" and empty. So it could simply be removed at the end of the structure building.

Cmp. http://lists.kde.org/?l=kde-core-devel&m=123169742119409&w=2 ff.
There should be some more, but I did not find them in my rush.

I see. Thanks for refreshing my memory. So the solution is simple, reverting to the previous noMerge="1" behavior, and using deleted="true" for the use case you mention. I added deleted="true" on 2008-12-12 (r896151).

SVN commit 957645 by dfaure:

Revert r912265, whose idea was "let's always hide empty menus, so that noMerge=1 can be used to hide a standard menu".
But that was a bad idea; 186382 says some apps have empty menus filled in by parts, so we need to keep them around for proper ordering.
Instead, r896151 had the solution to the initial problem already: deleted="true".
BUG: 186382


 M  +16 -2     tests/kxmlgui_unittest.cpp  
 M  +1 -1      xmlgui/kxmlguiclient.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=957645