Created attachment 185675 [details] The file causing the issue Steps to reproduce: 1. Put this file (also attached): [Desktop Entry] Type=Service ServiceTypes=KonqPopupMenu/Plugin MimeType=image/*; Actions=1A-Rcprs75;2B-Rcprs80;3C-Rcprs90;4D-RcprsCustom;5E-Rsize0300;6F-Rsize0600; Encoding=UTF-8 X-KDE-Submenu=Kim – Compress and Resize [Desktop Action 1A-Rcprs75] Name=Compress at 75 % Icon=application-x-compress Exec='/home/drew/.local/share/kio/servicemenus/kim6/bin/kim'_compress 75 %D %U [Desktop Action 2B-Rcprs80] Name=Compress at 80 % Icon=application-x-compress Exec='/home/drew/.local/share/kio/servicemenus/kim6/bin/kim'_compress 80 %D %U [Desktop Action 3C-Rcprs90] Name=Compress at 90 % Icon=application-x-compress Exec='/home/drew/.local/share/kio/servicemenus/kim6/bin/kim'_compress 90 %D %U [Desktop Action 4D-RcprsCustom] Name=Compress Custom... Icon=application-x-compress Exec='/home/drew/.local/share/kio/servicemenus/kim6/bin/kim'_compress `kdialog --inputbox "Compression rate:" 60` %D %U [Desktop Action 5E-Rsize0300] Name=Resize (300x0225 pixels) Icon=transform-scale Exec='/home/drew/.local/share/kio/servicemenus/kim6/bin/kim'_resize 300x300 %D %U [Desktop Action 6F-Rsize0600] Name=Resize (0600x0450 pixels) Icon=transform-scale Exec='/home/drew/.local/share/kio/servicemenus/kim6/bin/kim'_resize 600x600 %D %U into ~/.local/share/kio/servicemenus/ and right click an image. and go to the newly displayed submenu "Kim – Compress and Resize" What happens: "Resize (300x0225 pixels)" is displayed after "Resize 0600x0450 pixels" despite the action name ("6F-Rsize0600") being alphanumerically after "5E-Rsize0300". This is a regression, this does not happen in 5.27 I am on 6.4.5 and Fedora 42. Extensive discussion here: https://discuss.kde.org/t/how-are-service-menus-ordered/40444
Created attachment 185676 [details] Bad ordering This is a screenshot of the original desktop file, I shortened it for the purposes of the bug report.
Created attachment 185677 [details] Good ordering This is a screenshot of the original desktop file, I shortened it for the purposes of the bug report. Also not that when you right click the _.desktop_ file, the order is correct.
Code concerned is here https://invent.kde.org/frameworks/kio/-/blob/master/src/widgets/kfileitemactions.cpp?ref_type=heads#L196
And this is the bug that it arose from: https://bugs.kde.org/show_bug.cgi?id=466115 which reacted to https://invent.kde.org/frameworks/kio/-/commit/337853329c61c9cfe5e369acf65a8eca94e5e7fd ) which introduced sorting. I am not sure it is good design to sort alphabetically, or actually to sort in any way. I am not sure I understand or am convinced by the rationale given in the commit linked above. Menus in KDE are not sorted alphabetically at all, so why sort service menus? For my use case, sorting numbers inteligently would be good enough, but in general I would like to be able to set the order manually. I guess using https://doc.qt.io/qt-6/qcollator.html#details would do the job, the current implementation would also misorder Cad,Čad/Dad I think (should be sorted like that but Čad would come last, at least in Czech).
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kio/-/merge_requests/2025
Git commit fdb0546e6aa071c95392187cf300484d325156d9 by Méven Car, on behalf of Tomáš Hnyk. Committed on 21/10/2025 at 11:26. Pushed by meven into branch 'master'. kfileitems: Use internal name again for sorting Previously, KDesktopFileAction::name() was wrongly used to sort instead of KDesktopFileAction::actionsKey(). That meant service menus could not be ordered by their developers manually and weird situations like sorting actions named "Resize 300" after "Resize 2000". This regression was introduced when porting from KFileItemActinos to KDesktopFileAction in 0eb24754b5e3fb0025889bca1fca826f45961254 FIXED-IN: 6.20.0 M +1 -1 src/widgets/kfileitemactions.cpp https://invent.kde.org/frameworks/kio/-/commit/fdb0546e6aa071c95392187cf300484d325156d9