Bug 166481

Created attachment 26097 [details]
Menu under kde3

Created attachment 26099 [details]
Menu under kde4

in kickoff, we put the folders first, and no, there aren't separators.

the entries set to be first should appear at the top though; right now i think we just alphabetize everything.

can you attach your modified /etc/xdg/menus/applications.menu so that we might have something to test with? thanks.

Created attachment 26107 [details]
xdg file from Mandriva

Created attachment 26108 [details]
xdg file from Mandriva

please use the second one 

i think that at list classical menu should follow xdg menu file as kde3 did

the classic menu and kickoff share the same data-model what means, we could either;
1) introduce a sortproxymodel for kickoff to have the sorting done for kickoff but not for the classic menu or
2) kickoff and the classic menu just don't sort by themself but follow the specs here.

1) would probably be easier but also somewhat illogical imho since kmenuedit does not only allow to change the order (which has then no effect in kickoff) but also kmenuedit does not sort the items like kickoff does what is imho even more confusing.
2) would also need to touch the current logic we have within kickoff to show the description only if the prev/next item has the same name + imho to have it auto-sorted is a quit useful thing cause it does allow faster seek n' find of an item.

since kmenuedit does not only allow to change the order => DOES allow

i think the only  way is to follow .menu files if existing as we done before. For more coherency i think that classical menu and Kickoff should follow XDG spec by default.

Created attachment 26653 [details]
patch that *may* fix it

Attached patch just
1) disables sorting for the app-menu and
2) extends the itemdelegate to don't depend on the sorting to determinate if
the title is unique and therefore it's needed to display the subtitle or not.

I fear the way how 2) is done is far from optimal since it means that we need
to loop through all items for each item what sounds like a good way to slow
down large menus :-/ Anyway, it's the first try to progress a bit :)

@Nicolas: does that work for you?

re 2)
probably it would be better to have that logic in the model and just provide a "isUniqueTitle" role that delegate is able to ask for?

i just tested and it didn't change at all the menu behaviour, this is still on the same order

Created attachment 26676 [details]
second try

Now the patch does 1:1 the same thing we did in KDE3's service_mnu.cpp. But it
seems it doesn't have the expected effect here (though it may the case I did
something wrong on my testcases). I fear the prob is more down the stack within
kdelibs kservice/ksycoca-impl :-/

this is a lot better.

On Office section it respect the .menu file but on :

Tools-> System Tools  we asked for a special placement thanks to the menu file and this is not respected.

In plus can we have some separators when this is asked on the menu file ?


Btw  thanks a lot for this begining of the fix :)

Created attachment 26706 [details]
better

updated patch that addresses the performance-prob with large menus named in
comment #11. Else no new functionality.

Created attachment 26707 [details]
typo--

rather stupid typo (time to catch some sleep ;)

this is normal that there is no more a patch against workspace/libs/plasma/delegate.cpp ?

y, it's correct. I just moved the changed logic in delegate to the model itself like "announced" in comment #12 ;)

this is better on i586 but on x86_64 this doesn't work at all.
btw we still miss separators and on my i586 xdg is only respected on the first section of the menu but on subsection this is not

ping for this important regression in menus

"this is better on i586 but on x86_64 this doesn't work at all."

erm, but there's no platform specific code in Sebastian's patch whatsoever.

"we still miss separators"

sure, that's a TODO in there.

"is only respected on the first section of the menu but on subsection this is not"

subsection, meaning submenus? e.g. the second level of menus?

the patch doesn't even apply to trunk anymore. i'm currently working on that.



as a side commentary, i think that providing manual ordering of items in this fashion is about as sensible as allowing the user to say "i'd like this item at pixel 100, and that one at pixel 110". it's quite frankly stupid. unfortunately, in typical xdg fashion, i don't think much real design thought went into it and it was just "hey, people should be able to order the menu" without asking "why?" or "what are they really trying to achieve?" or "how might this interact with other valid features?" ... nope, just slap-dash design-then-code.

i realize that we "have" to support it now at this point, but it's so very dissapointing to have such legacy dragging on things. as a heads up: if/when we get around to providing an improvement interace to applications, i do not expect we will care much for the xdg spec in designing it.

this is, however, precisely the kind of work that takes out all the joy of working on "desktop linux". "yay, more drudge work for a design i don't agree with made by people i don't feel were properly equipped to make such a design for a use case i'll probably never personally care about."

SVN commit 907746 by aseigo:

listen to the menu files as per the xdg spec for these things.
based on a patch by Sebastian Sauer.
BUG:166481


 M  +102 -56   applicationmodel.cpp  
 M  +7 -1      applicationmodel.h  


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

SVN commit 907750 by aseigo:

backport of fix for bug 166481
CCBUG:166481


 M  +102 -56   applicationmodel.cpp  
 M  +7 -1      applicationmodel.h  


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