Bug 186382 - order of menu bar entries is wrong
Summary: order of menu bar entries is wrong
Status: RESOLVED FIXED
Alias: None
Product: kdelibs
Classification: Unclassified
Component: kdeui (show other bugs)
Version: SVN
Platform: Compiled Sources Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: David Faure
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-03-06 20:00 UTC by Jonathan Marten
Modified: 2009-04-22 18:21 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Screenshot showing problem (3.82 KB, image/png)
2009-03-06 20:03 UTC, Jonathan Marten
Details
Patch which seems to fix the problem (536 bytes, patch)
2009-03-06 20:08 UTC, Jonathan Marten
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jonathan Marten 2009-03-06 20:00:40 UTC
Version:           1.4.50 (using Devel)
OS:                Linux
Installed from:    Compiled sources

Running akregator standalone (i.e. not within Kontact), the order of the menu bar entries is incorrect.  See attached screenshot.

Running from current trunk (up-to-date as of today), with no user *rc files present in ~/.kde/share/apps/akregator.
Comment 1 Jonathan Marten 2009-03-06 20:03:34 UTC
Created attachment 31850 [details]
Screenshot showing problem
Comment 2 Jonathan Marten 2009-03-06 20:08:44 UTC
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?
Comment 3 Jonathan Marten 2009-04-21 18:02:52 UTC
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.
Comment 4 Christophe Giboudeaux 2009-04-21 18:22:29 UTC
Add kuiviewer to the list. The menus order is the same as when XDG_DATA_DIRS is not correctly set.
Comment 5 Jonathan Marten 2009-04-21 19:36:11 UTC
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();
Comment 6 David Faure 2009-04-21 19:58:55 UTC
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?
Comment 7 Friedrich W. H. Kossebau 2009-04-21 21:52:10 UTC
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.
Comment 8 David Faure 2009-04-22 14:43:20 UTC
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).
Comment 9 David Faure 2009-04-22 18:21:37 UTC
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