For performance reasons currently, we sort the entire list of applications just once, and merely filter out what should be shown/not shown in categories and search results. This saves the (expensive) trouble of shuffling actors around in their container (or creating them on the fly like we used to do.) We're currently re-evaluating how this is done, as obviously we'd like search to work as expected, but we also don't want a sluggish menu (a huge complaint in the past.)

If the evaluation result positive, i also request if it possible a regression for this commit
https://github.com/linuxmint/Cinnamon/commit/51caa96c2e41b1c4019dce05828effc2e0ab919e to be used in the menu.

I'm sorry I haven't kept up on this like I should have. While using Linux Mint 17.3, I've noticed this issue is still present. I completely understand and respect the desire to create a fast search menu with as relative results as possible, and appreciate all the Mint team is doing.

Is there any chance that this has been improved in Cinnamon for the Mint 18 release?

Otherwise, can I bump this request and ask for a more in-depth consideration?

Thanks, all.

I think the best option will be use the cinnamon search ability that is implemented but is not active. Probably, the menu can be merged then with this ability and then can be removed the internal search implementation of the menu. Instead of the internal search, could be used an implementation of the Cinnamon Search ability. In that way, the user can select the Cinnamon Search plugin that will be activated or deactivated, if he/she want use a faster search (with a not good order) or a more slow with probably a better order.

Both Search plugins can be implemented with the cinnamon code by default. The problem is the question of if the Cinnamon Search, will be enough faster to be activated and used inside Cinnamon. If a more specific search (the menu search), is a thing to be thinking, a general search will be more problematic.

I also came here to report this issue. In particular when there are many search results (> 30) the search feature becomes nigh unusable, despite typing in the exact program name.

I came here to report the same issue. For those who are interested in playing around with the search algorithm you can find it here written in JavaScript believe it or not.

Bare in mind that the is used for both the order in which to list applications in categories and the order to which applications for searches. As we can see it simply checks the name, id, keywords etc to see if there is an exact match with whats in the search bar in the order in which the application list is stored. And from here it appears they are stored alphabetically (which I guess I should've noticed before looking at this.)

I would like to have an Most Recently Used sorting personally. The application usage app that @lestcape pointed out seems promising as well.

Whats occurs is that apps are sorted alphabetically always. This is because if you need to change the order, you will need to remove and insert actors. This procedure have a big cost, because cinnamon use an intensive GL. So, the reason of not re-sort the apps is only because of this.

There are at less 2 difference approach to sort elements. One is when element (the actor) are constructed from a generic box and another when the elements are constructed from an standard St.BoxLayout. Both have inconvenients and benefices. In my opinion will be useful make a comparative of this 2 algorithms, but i think the most faster will be the generic container, because can be optimized to only render the visible view port of the items container.

Cinnamon used currently an standard St.BoxLayout as a container (https://github.com/itzexor/Cinnamon/blob/a9e8a60d5c376a985dbc0ab141143c8ca1422947/js/ui/popupMenu.js#L1589). Also i think there are a bug some where in the GL compositor probably, because if you provide all layout structure and show the container at ones, this take more time than show one item and then another...

Currently, cinnamon show the first items one by one, and the another’s outside the view port at once.

I any case, i think that need to be a serious work, to provide a faster solution, not just a simple patch, but i think that currently both way can be implemented without lost much performance, more than that was lost and for all cinnamon components with the implementation of hidpi.

In my opinion, the problem could be noticed after activated the search providers...

@lestcape I see. I did end up trying to patch the _listApplications function to sort in a different manner and it had no effect, before I realized that these icons were being pre-loaded and the _listApplications was only acting as a filter for which of the preloaded icons would display.

It's unfortunate that it's expensive to reorder the actors, but I guess you could relate this to the web-development world as "reordering elements will require a reloading of the DOM. If possible, just set the DOM elements to hidden using CSS and then set them to visible when you need them".

I might be able to take a look into seeing if I could try using a generic box to remove and insert the actors, but I doesn't appear to be as trivial as it first sounds since the rest of the code seems to be written with the assumption that everything is loaded and sorted already. Let's see how bad it really is, and then go from there.

In my opinion, the problem could be noticed after activated the search providers...

Yup, I think you are right. But let's get a benchmark maybe first to see.

There is another option however that might be reasonable. We could leave the order in which programs are listed but we could place the selection to an element we think best fits the description.

For instance, when I was first trying to rewrite the search algorithm, I essential did a fuzzy finder that used a regex of something like: given "abcd" search, apply regex /a.*?b.*?c.*?d/i to all applications then sort by

1. First sort by which results have the most compact match: ie: abcd should be above abccccccd.
2. Next sort by which matches occur in least index, ie: kk abcd should be above wwwwwwwww abcd.

Eitherway, let's say we continue with the sorting we have now, using indexOf. We can select the item whose indexOf is the smallest number, so then users can simply hit enter once they have finished their search to open up kk abcd instead of cccc abcd since that is alphabetically first.

This could resolve problems like #4327 and we could also only display the top 10 (from indexOf) to solve problems like:

I also came here to report this issue. In particular when there are many search results (> 30) the search feature becomes nigh unusable, despite typing in the exact program name.

If we combine this technique with an implementation that perhaps presorts the applications by Most Recently Used instead of Alphabetically (or by using the Application Usage program you mentioned above), we might be able to get some decent results without any performance impact at all. But I will confess that may make it more difficult to manually "search" for applications by browsing through the categories manually.

@cbreeden Well, this is an implementation with a generic container:
https://github.com/lestcape/Configurable-Menu/blob/master/configurableMenu%40lestcape/configurableMenus.js#L5332

This is an implementation with standard container:
https://github.com/lestcape/Configurable-Menu/blob/master/configurableMenu%40lestcape/configurableMenus.js#L4760

They are part of Configurable Menu (https://cinnamon-spices.linuxmint.com/applets/view/171). In past, Configurable Menu was implemented to sort and re-sort apps in different ways, adding and removing actors and using different algorithms and combination of algorithms... The problem was that in Configurable Menu was reused a large set of Cinnamon classes while we create another large set of new classes. So, a small change in Cinnamon was for Configurable Menu a big problem and a lot of work to do. I have no time to live with all Cinnamon updates and as a result, Configurable Menu is complete broken.

Another result is that I need to stop my test, because i have not time.

Both implementation are not finished yet.

What i see is that, the generic implementation is several time more faster than the other, if i filter the icons inside the view port, but then when you tray to scroll down the scroll is more slow...

Need to be a middle, probably if we take a timeout and then load the another items. The problem is, when user open the menu to search instantaneously, in the last case we fail and the search occurs pretty slow.

Another point related with performance, that could be improved, is the fact that the popup menus of the items are also added to the container on the initialization. This is wrong for the performance point of view, because they are not visible until you perform a right click, and is only a complication for the compositor. The alternative is insert the actor only when the right click is performed and remove it when a left click occurs.

Anyway, the most problematic thing on the cinnamon menu performance is the vector box: https://github.com/linuxmint/Cinnamon/blob/master/files/usr/share/cinnamon/applets/menu%40cinnamon.org/applet.js#L1613

@cbreeden "If possible, just set the DOM elements to hidden using CSS and then set them to visible when you need them": This is what occurs right now.

You can not pre-sort apps in anyway in the initialization, because you don't know the search pattern in the begin... So, any statically order, will be only good for some patterns and wrong for others. You only can provide a good search when you know the pattern and this is only known on search (where you need to remove and insert actors for re-orders its).

You only can provide a good search when you know the pattern and this is only known on search

Yeah, the only idea I had for that was presorting all the applications based on MRU, but that may not be desirable for when you are simply "browsing" applications in the menu categories. I agree, it's kind of a nasty trick and probably best to avoid.

This issue is still present in the default Cinnamon menu in Mint 18 x64 w/ Cinnamon 3.0.7. Even searching for "screenshot", using the entire string I just wrote in quotes, brings up the "Backgrounds" menu item, first. Searching for "record" (like for accessing RecordMyDesktop) brings up Audacity first.

This bug was labeled a feature request, but I really don't think I'm requesting another feature; rather, I'm reporting that the feature doesn't work as myself, and probably many other users, expect. GNOME Shell's search results are almost spot-on. Is there any way Cinnamon's menu could bring up relevant results like gnome-shell?

related to (maybe even duplicate of) #1220 and #1320

There is an applet, which uses a different search function:
https://cinnamon-spices.linuxmint.com/applets/view/258

This is quite a serious issue, as the menu is such an important way users interact with the system. The "Menu Key, followed by three letters of the app's name" is such a common and convenient way of launching things that I'd say it's quite critical to the user experience to have it work as expected.

I'm in this bug because I just accidentally launched digikam instead of power management because digikam's slogan is "manage your photographs like a professional with the power of open source"! Honestly until this bug is fixed properly, the menu should at least hide results which only match the description if there are also matches by name. This would require no sorting.

Note that the applet workaround seems to be broken in current Cinnamon versions. It's also worth reiterating that GNOME's menu does this very well indeed, and as far as I know they also use a similar architecture with Javascript and all that kind of nonsense? Perhaps it would be worth looking into their methodology for sorting. They manage to search apps, files, available software and probably more in a reasonable time - it's a very powerful and convenient system.

@fish-face i agree with you... Can be implemented the cinnamon menu like it's implemented the gnome menu. I know how it's implemented and it's possible do that... The problem will be that we will lost the possibility to realize a normal scroll inside the applications... Gnome menu just load the icons that are currently visible, and load anothers when you change the view. This is why could be relative faster... This involved a complete change of the menu functionalities. Will be this acceptable? I don't know...

Testing in Mint 18.1 on Cinnamon 3.2.7, and this bug is still definitely present in the applications menu. Search terms continue to not be relevant to the user's search entry. I whole-heartedly agree with @fish-face , it's surprising in an age of "press the super key and type three letters to get to your app" that Linux Mint, the herald of user-friendly open-source operating systems, has this issue in their primary desktop.

Guys... I posted this bug originally in 2015. It's been over two years, now... ...

Can't we at LEAST make a policy that: "if the sequence of letters typed in the search field aren't part of the application name, then they AREN'T listed first"? I can't imagine the code would have to be tweaked that much to make this particular change, yeah? For example: typing in "disp" to get to display settings WON'T list "Colors" first. Rather, it'll display the "Display" settings first, because the "Disp" in "Display" matches the search letters.

Came here to +1 this. I never want dropbox when I type files, but it's always the first result.... The solution posted by @jessedubord sounds like the most intuitive way to do this.

Two other related issues which have been open for 5 years:

1220

1320

@JosephMcc sorry for the double, I just find it frustrating. I'm looking at the code right now too see is _maybe_ I can help.
I know JS and a tiny bit of Python, no C.
Might this be possible without knowing C? Where could I start looking?

The menu applet is in /usr/share/cinnamon/applets/[email protected]

Okay I found the heart where it probably can be fixed:
https://github.com/linuxmint/Cinnamon/blob/master/files/usr/share/cinnamon/applets/menu%40cinnamon.org/applet.js#L3238

Can somebody point me to some documentation. A place where I can ask some questions to some regular contributors? A slack or whatnot.
I doubt anybody want me to ask every minor question in a github ticket..

You can use #linuxmint-dev on IRC. Just be patient since it can take some time to get responses on occasion.

The best way to access current documentation for Cinnamon or any of the gnome libraries is with the devhelp application. Just be sure you have the relevant -doc packages installed.

@JosephMcc Thanks I'll take a look on IRC.
I understand I might seem a tad impatient. But I hope you understand that I get frustrated with the menu. Find out it's a five year old issue and get more frustrated. Then get excited when I find out I might be able to fix it. And now I'm pretty sure I can fix it with a few days work of coding.
Too bad I don't have a few days to spare this month.

@janw-oostendorp, appreciate the comments. I'm a novice novice coder at at best, with limited experience in C++ and C# -- I'd contribute more to the solution if I could. I'm sure the Mint dev team (hopefully) would welcome any patches to fix or improve issues with Cinnamon... Cheers.

So, finally I tried out Cinnamon and it is awesome, except for the menu search which unfortunately is a complete show stopper for me in this state. So I had a look at the code and changed it to my needs in this way:
First search applications only by their name (and only at word boundaries). If any applications were found this way, return them and do not search in keywords, descriptions etc. However, if nothing was found, do the old search.
I do understand that this does change the current logic, but IMHO it stays as close to what we have now.

Please have a look at the change I made. It's working perfectly for me, maybe it can be made optional. In any case, feel free to discuss.

Cheers, Curly060 =;->

If encouraging people new to Linux to use Cinnamon/Mint/Debian is a goal, this kind of thing might just drive them away. I speak as someone that just switched from Mac to Debian+Cinnamon a few days back, and found this so frustrating that I nearly switched back, before taking the time to look around and fine the Sane Menu applet that gets the job done for now. The Mac workflow (admittedly partially because their window switching and management is so bad) involves this step very frequently: press Ctrl+Space to bring up Spotlight/Dash, and then type a letter or two to launch the app.

Just saw the commit from @clefebvre and @Curly060 regarding implementation of an improve search method. This is awesome news! Thank you both! :)

Wondering if this will be available in Mint 18.3, or can we expect it in Mint 19?

It's in Cinnamon 3.6, means Mint 18.3

Awesome, thanks for the info' @NikoKrause.

After testing the recent commits in 18.3, I can confirm that the search now behaves as expected: search results containing the search term now show first/only! Glad to see this much-needed improvement alive and working. I'm considering this issue as resolved, and am closing the issue.

Thanks to @clefebvre, @Curly060, and the Mint team for your work!

@jessedubord @clefebvre @NikoKrause as per #7364 this limiting of results if a match is found in the application name seems like a "bug" to some users. I just had another user coming from 14.04 to 18.04 complain today that he can't find "Synaptic Package Manager" when typing "install" because "Gdebi Package Installer" is the ONLY result returned.

Sounds to me like it should be configurable then.

@Ferroin, search configurations can always be a good thing, IMO.
@rik-shaw, if I remember right, the new search code implemented as a fix behaves in the following way: it shows results containing the search term in the title _first_, and then shows all of the other results. It doesn't omit any of the results that showed up before the change -- rather, it just doesn't list them, first. I think @Curly060 can confirm this, though.

@jessedubord no I think the behavior now is that IF a search term is found in an Application NAME then it will NOT continue to include results that are hits based on description or keyword. This is what @Curly060 's patch changed. This can be confirmed by searching for "install" and Synaptic (with a description of "Install, remove, and upgrade packages") will NOT be found (IF you have "Gdebi Package Installer" installed). However, if there are NO HITS on Application NAME, then description and keywords are searched. In the same example of Synaptic, if you search for "remove" it will show (since no application that I have installed has the name "remove" in it). It would be good if you could confirm this.

What you suggest would be a good option, to put the results matching NAME at the top, with items matching keyword or description below. That may possibly be the "original method"? Maybe not.... it is just a matter of not sorting all final results alphabetically, but rather sorting the Application NAME results, followed by sorting the Keywords+Description results

Looking back through this thread, there are concerns that sorting the list is intensive and not wanted to be done more than possible. I think the only way around this would be to keep track of HOW the item was included in the list (some tag like "primary" or "secondary"). Then you sort all the "primary" hits (app name both friendly name and real name.... nemo AND files) first, then sort all the "secondary" hits second. A divider line between the 2 sets would be icing on the cake!!! @mtwebster does this idea sound too complicated? I think it would really address this issue once and for all!

The original method showed all results, but sorted things alphabetically by application name instead of sorting ones with the match being in the name (as opposed to keywords or description) first, which is what prompted this issue in the first place (because typing in 'files' and getting 'Audacity' as the first result makes zero practical sense).

I think having things work as @jessedubord describes would be a reasonable default, but I personally would still like to be able to select the current behavior of only searching names because what is being proposed is liable to be _slow_ because it will (probably, not certain about this) need multiple sorting passes.

@Ferroin yes understood: I re-edited my comment to suggest a "2 pass only" sorting (results would need to be tagged "primary" or "secondary" as they are found).

My change indeed introduced a breaking change in the search logic: Search in application names only at word boundaries first. If that finds anything, do not search any further (that's the breaking change) but return the result. If it did not find anything, do the old search.
I knew my change would break the old logic, but I found "my" way much more sensible than the old way, plus it was IMHO a good compromise. My patch was by no means perfect.
Of course what you guys propose now would have been much more sensible (show both results, maybe with a divider), but unfortunately this is technically not possible with the current implementation because everything in the menu is pre-built and pre-sorted. The search only hides those elements that are not in the search result.
And that seems to be a whole lot more complicated to change that. This also seems to be an performance issue (adding/removing elements on the fly etc.). That's why there was no progress at all in this issue.
So basically, we are back to square one:
The way how the menu is being built needs to be refactored completely - and that is unfortunately way out of my skillset.

@Curly060 Short term though, adding some way to select between the old logic and the new logic seems to be a reasonable option. If/when the menu gets redone so that it can prioritize search results with the terms in the name at word-boundaries, that could then be added as a third option for how to search (because even then both the old style search and the current new style should be easy to implement).

I need to re-open this issue. Now, in Cinnamon 4.0.9 in Mint 19.1, the search behavior is the same as it was before: search results aren't pulling up apps that share the same name as the search string, first. For example, searching "file" doesn't bring up "Files" first to be listed and highlighted. Similarly, searching "moni" (for system monitor) brings up "Display" first, not "System Monitor". Even typing "system" in the search lists Files, Font Selection, and Fonts in the result list before anything that actually contains the word "system" in it.

As state before, the expected behavior for most users (and most user-friendly, imo) would be for the search results so list the apps who share in the same name as the search string, first, then the more "in the same ballpark" search results.

Screenshot examples:

I have the same problem, and it looks to me like search looks into apps' names as well as _descriptions_, but does not sort them by app first, description second, but alphabetically by app name.

When I search for "web" to open WebStorm, all the other apps search turns up have "web" embedded in their descriptions ("webcam", "world wide web"); unfortunately for me, WebStorm is the last in that alphabetical list of applications.

ETA: After checking which version I'm running, I guess _my_ problem is that this fix/improvement was never applicable to it in the first place... (Cinnamon 3.2.7 on Debian stretch) _sigh_

The way application search works in Cinnamon is so unintuitive. It's hard to overstate how important this is, because hitting the superkey, typing the beginning of an app's name, and hitting enter is how many Linux users are used to launching their programs. If I try this in Cinnamon it's all too easy to get the wrong program opening. For example if I type "file" and hit enter, I am greeted with Audacity instead of Files as I'd expect. I really like most of what Cinnamon has to offer but this problem is close to being a dealbreaker for me.

This issue is still present, unfortunately, in Cinnamon 4.2.4.

I'll also add my hat in the ring. This is still present today.

It seems to be matching the description instead of the application name. None of the listings have steam in the name, only in the description and command line.

For me the worst part is that it now doesn't use the executable names anymore. While my system is set to german I tend to open programs based on their english description, e.g. calculator instead of rechner, or calendar instead of kalender. This used to work in previous versions but since about one version ago it stopped working and it is a mayor PITA to learn the (sometimes ridiculous) translations.

I concur with the opinions of other reporters about the importance of getting this feature working properly. When I search for "Update" I would like to have menu options that don't contain the search term to be displayed last, and not like this:

As an extra feature request, it would be nice to sort the has-search-term-in-name-results even further: first showing the ones that have the search term at the beginning of their name. Meaning that when searching for "Update", "Update Manager" and "Update Monitor Position" would come before "JDownloader 2 Update & Rescue" and "Ukuu Kernel Update Utility".

Linux Mint 20 with Cinnamon 4.6.7.

I want to open Visual Studio Code. Appearantly, that is a bad name to search for in Cinnnamon, as it starts with a "V".

Searching for "code":

Alright then. Maybe searching for "visu" will do the trick?

:-/

After reading the history of this issue, I came to the conclusion that renaming the menu item "Visual Studio Code" to "Code Visual Studio" would be the easiest way.

Pro tip for app developers: Start your application names with a letter that comes alphabetically first, so Linux Mint users can efficiently search for them! :disappointed:

yeah this still needs to be fixed in the menu, renaming it doesn't fix it and is way to much of a hassle compared to just fixing the underlining issue with the menu ¯\_(ツ)_/¯

Fixed by https://github.com/linuxmint/cinnamon/commit/a6738bd306180b4e2e668c90c1d7d5d6c0578906