Cinnamon: Cinnamon menu "enhanced / simple / basic" search

[ghost]

Add an option for basic search.
If I type "ter" the result should not display "character map" or "sound converter" but only "terminal" for example

[gauravjuvekar]

Yes it should.
Some people can press the super key and start typing really fast so by the time the menu opens, only the latter part of the characters get inserted in the box like "rminal".
Matching this string to Terminal is useful.

[ghost]

Ok but like I said it can be good to let the user choose by adding an option.

[gauravjuvekar]

Actually, there should be an option to change the order of the list from alphabetical to most used/recently used, etc

[ghost]

I think the applets need more improvement. In Gnome 3, when I type "Files", I get Nautilus or Nemo. In Cinnamon, the first choice is Bless Hex Editor, Dropbox, Easytag, and THEN Nemo and Nautilus. Also, typing "nautilus" or "nemo" doesn't show in the search.

[ghost]

I agree with you we should be able to search a program by its name too.

[gauravjuvekar]

@Chowlz That happens because the list is alphabetical so Audacity having "Record and edit audio _files_" in the description comes before "Files" which is the title for Nautilus and nemo. Changing their description to something like "Nautilus/Nemo file browser" would list them when typing nautilus or nemo.

I agree that search should be enhanced a lot with more configuration options.

[spectas]

A listing based on how recent a program was used, would be good.
But at least, the search function should privilege the actual program's name instead of its description!

E.g.: When typing "pan", which is the actual name of the program, as used in the terminal, too, the menu shows "Brightness and Lock", "Color", and so on, and the 11th result is "Newreader Pan".
When I have a program and I type its complete name, it should definitely be the number 1 result..
Greetings!

[Lusito]

1628 will help getting better results. It does not take recent applications into account, but it does a better search score ordering.

[ghost]

I added to Configurable Menu some methods to sort search result.
https://github.com/lestcape/Configurable-Menu/archive/master.zip

• Name (it's the standar way in cinnamon menu).
• Relevance (it's the way implemented by Lusito in Menu Plus http://cinnamon-spices.linuxmint.com/applets/view/129)
• Usage and Name (sort by the usage of the app first and then use the Name to sort)
• Usage and Relevance (sort by the usage of the app first and then use the Relevance to sort)

Please note:

• Relevance: It's more less the number of occurrences of the pattern in the string description, name and identifier in the App.
• Relevance criterial it's also is sorted by Name, when the real relevance have the same value.
• Usage: It's not a global usage, it's only a local usage, only when the app it's initialized inside the menu. Global App usage was removed from Cinnamon here:
  https://github.com/linuxmint/Cinnamon/commit/51caa96c2e41b1c4019dce05828effc2e0ab919e

[ghost]

It's been over 2 years since I report this issue.
Can we now do something to add this feature please. As an option if needed.

If one type the first letters of a program name it really should be displayed first.

[ghost]

@Paviluf you are not the only one that request this. Please see:
https://github.com/linuxmint/Cinnamon/issues/2518
find the comment of @mtwebster on the issue, and you will see why cinnamon devs don't want to implement this feature and also see:
https://github.com/linuxmint/Cinnamon/issues/3644
The time is not the reason, and when more thing will be added to the cinnamon this will be more slowly and more difficult to implement.

Have a good day.

[ghost]

Thank you for the infos. However like you say I'm not the only one that request this because this behavior is logical. Almost other menus I tried works "correctly" without any performance problem so it is feasible.

Maybe an option to only display the softs who begging with the first typed letters is really simple and quick to implement, without speed problem.

I think a lots of peoples who knows their system don't need this "fuzzy" search and prefer to display the right softs with only a few typed letters. So a little option can be a good compromise don't you think ?

[ghost]

@Paviluf, What is good to me or not, is not representative to the cinnamon devs aims. I'm not a cinnamon dev, so I don't know. On general, what i see is that Cinnamon devs always want to maintain the thing more simple, to be easy understand and maintain (so this involve a continually support for a long period of time, and an easy way to update cinnamon, to any change). I can not see this as a wrong decision or an a final decision. If there are a linux desktop with the ability of extend the functionality easy, this desktop is Cinnamon, so why pretend change the Cinnamon way? Is not better create a new different solution for what you want to have?

Right now Configurable Menu have several ways to handle the search, you can use it on several cinnamon versions if you want to have an specific behavior on the menu. Also there are more menus, and you can request thing.

[leigh123linux]

@Paviluf

Instead of complaining that two years has elapsed you could have learnt to code in that time and done it yourself!!

[ghost]

Why are you saying that ? I proposed a little and logical feature. I nicely ask again 2 years later, so I thing I'm not really annoying.

Some people are weird sometimes...

[anandrkris]

@leigh123linux We can't expect all cinnamon users to become developers. :wink: All of us are not blessed (personally i could never find the time or motivation) with the ability to code :smile:

@Paviluf - Certainly, Cinnamon Menu needs improvement. Hoping that it will feature in the upcoming release.

[ghost]

It is still true that there is no better thing done otherwise than by oneself.

[Hubro]

This is probably the stupidest search applet in all of Linux... There is no excuse not to improve it.

[mtwebster]

Thanks for your declaration, but if you actually read the issue and discussions, there was a fairly solid excuse not to change it at the time.

The only thing lacking now is someone to change it, but it has to be done in such a way as not to compromise speed, as discussed. It can be done such that the impact of having a 'good' search will not affect conventional menu navigation, and I won't accept less than that.

[Hubro]

A good start would be to build a simple index of the desktop items that gets rebuilt every time a desktop file directory (like /usr/share/applications) is modified. You could then implement several search/sort algorithms that users could pick from in the settings.

Perhaps you could even make it hackable? Let users supply a .js file containing a function like:

function searchIndex(searchText, index) {
    // Returns a subset of index
}

That would be awesome.

[ghost]

@Hubro, short history: The clutter components are not thread safe, thats is the cause of the lag, because to perform a reorganization of the items, will be necessary rebuild all items structure in a one thread over javascript. What currently happen is that items are not reorganized internally in a new layout. They only perform a visibility change, what is probably, the most faster thing that you can do it. What you recommended, is also (more less), implemented over c (please see the cmenu implementation). I'm disagree with @mtwebster of only one thing and he was who help me to see the fact. There are a vectorbox in the menu that is pretty slow and can be replaced by mathematics, this performance improved is just what is needed to gain the cpu clock time and then implement the menu reorganization more faster.

[davidgasquez]

Any news on this issue?

[Feuerfuchs]

You guys might want to take a look at this fork of the menu which implements fuzzy search: https://cinnamon-spices.linuxmint.com/applets/view/258
https://github.com/nooulaif/cinnamon-sane-menu

[davidgasquez]

Awesome @Feuerfuchs! Thanks for pointing us this awesome applet. I'm wondering if this change will be merged in the original menu in a near future. :thought_balloon:

[mainmachine]

The sane menu replacement is fantastic!

But as per @lestcape's comments, would this incur noticeable lag under the right conditions? i.e. a dozen more desktop/ menu entries?

[Feuerfuchs]

As far as I can tell, the Sane Menu applet removes all application actors and re-inserts them in sorted order. It's not ideal, but modifications are minimal, it has absolutely no impact on regular navigation, and so far, I haven't experienced worse search performance than with the stock menu.

Here's a diff which shows all modifications the developer made: https://gist.github.com/Feuerfuchs/b04120bdbc99789e0cc9a41c3654ce53
I used this version of the Cinnamon menu for the comparison as that seems to be the version the developer based his applet on.

[ghost]

The lag depend of the number of apps that you have in your menu. The lag really occurs, but this not mean that can not be done a better search order... it's a thing of user preferences in my opinion... For several people a good search order it's not important as the best performance, for others it's.

[ghost]

The cinnamons devs want to add a search provider to the menu (that is a nice feature), but this will add a lot of items to the menu. If we keep a good search order (adding and removing actors) we can incur in a noticeable lag of the menu using the search provider? I think the answer of the question it's clear...

[Feuerfuchs]

Some thoughts about how we could improve the performance:

What I did in my GPaste (a clipboard manager) applet is to add a fixed number of items. Those items can be assigned a clipboard entry any time, so if the user for example searches for a certain entry, there are no actor removals and re-insertions whatsoever.

We could do this with the menu if we define an upper limit for the number of items that can be shown. For example: Number of installed applications + 30 per search provider.
We could determine this upper limit when the applet is loaded (and refresh it if an application is installed or a search provider registered), add this number of menu items to the application box, and then we could make them display either applications, places, recent items, or search results.

[ghost]

@Feuerfuchs yes of course, but how many providers you have in gpaste? In any case and with all improve, this is not a simple desition... For example, take on account what could happen if while is preformed a response for all providers, the user type another character and then another.

You will see how will be really difficult the text input, the cinnamon main thread will be saturated and the desktop could not react.

[Feuerfuchs]

My idea eliminates the problem of having to insert/remove actors all the time — no matter how the search feature or anything works, this should result in a nice performance gain.

[ghost]

Well @Feuerfuchs, what you say will not eliminate the problem of having to remove/insert actors all the time, just will be limited to a number of actors for each providers. Sorry if i understand wrong.

[Feuerfuchs]

@lestcape: Ah, I see, let me try to re-explain:

My idea is to insert a limited number of menu items _only when_ the applet is loaded. For this to work, we need a reasonable upper limit of how many items are displayed — it's not like the user would want to scroll through millions of items anyway.

These menu items are designed to work with any type of content: Application, recent file/folder, search result. The type and assigned data can be set whenever we want, so if we want to sort the applications, we just have to iterate all actors, change the assigned data, and we're good – no remove/insert action required.

In terms of code, it could look like this:
(please don't point out errors, it's just an example to show the mechanics)

let sortedSearchResults = someSearchMagic(pattern); // contains applications, recent items, search provider results
let index = 0;
for (let len = sortedSearchResults.length; index < len; ++index) {
    // Index exceeds the upper limit, we must stop here
    if (index > upperLimit) {
        break;
    }

    let result = sortedSearchResults[index];
    menuItems[index].setData(result.type, result.data);
    // result.type could be a constant such as MenuItemType.APPLICATION, MenuItemType.RECENT, etc.
    // result.data could be the app object if the type is MenuItemType.APPLICATION, etc.

    // If the menu item was previously hidden, make it visible again
    if (!menuItems[index].visible) {
        menuItems[index].show();
    }
}

// Excessive menu items have to be hidden
for (; index <= upperLimit; ++index) {
    menuItems[index].hide();
}

If we only display all applications, imagine the sortedSearchResults array would instead be a allApplications array. If we only display recent items, it would instead be a recentItems array.
As I said, that would eliminate a lot of remove_actor/add_actor calls and allows us to sort the menu items freely.

I hope that helps!

[ghost]

@Feuerfuchs Yes, i have the same idea of you, please see my preload cache of items:
https://github.com/lestcape/Configurable-Menu/blob/master/configurableMenu%40lestcape/pakagesManager.js#L323

Anyway, your explanation it's not complete, because you missing something...

1- Clutter have a paint cache, so it's not the same the first time that you show an item than when you show again an item... The first time it's the worse if we speak about performance.

2- Clutter will not create a cache if items are not in the stage and are also visible, so, your preloaded will only have sense before the first time that you show the items.

3- You will need to show the items on the initialization, also if they are not uses (i.e.: Perform the preloaded).

4- Unfortunate Clutter lose the cache when he considers that it's not on use (i.e. when he want), so what you do in the initialization, will lost.

5- Users will not open the menu constantly, so the case of the first time will be performed in practice always.

There are more things involved, but well this is just enough to get down our good theory. :)

[NikoKrause]

Idea:
Leaving the search procedure as it is right now.
But using fuzzy search to get the best result and hovering that button in the appsFoundList, instead of rearranging the buttons in the appsFoundList.

[andrebrait]

Sorry for necrobumping the issue, but... The best desktop search I know is KDE Plasma's. It works very fast, can search both names, descriptions and file contents and (again) it's fast. Is it possible to use the same mechanism? Is it desirable?

[ghost]

@andrebrait of course not. Kde don't use Clutter or java script bindings and also have not only one thread to do all things.

[andrebrait]

@lestcape I wasn't referring to the mechanism as in literally using the methods KDE uses. I was referring to using algorithms similar to the ones KDE uses. I don't know what kind of search algorithm they use, but it works damn well. Implementing it in Cinnamon might not be impossible and easier than coming up with our own solution from the ground up.

Btw, Cinnamon can only use one thread?

[ghost]

@andrebrait feel free to fork the menu and do what you want and convinced for your self... The problem it's not the algorithm, for a simple task like that we don't need a complex algorithm. For your last question yes.

[andrebrait]

@lestcape I don't know if it was what you intended, but this last comment didn't sound very... friendly...

I don't want to fork it and do whatever I want with it. If I wanted to do that, I would just have forked it. I wanted to contribute with ideas to the existing project (and maybe with some code later, but yeah, no point in coding something that people haven't agreed upon).

I'm used to this kind of comment, but I would advise you to use a friendlier tone. Some people are sensitive to this sort of thing.

[ghost]

@andrebrait I don't known why you say this... I'm not your friend and I'm not need to demonstrate you anything. I will be really happy if you can find a good way to improve the menu, but thats will not be without write a code... As i see, i don't insulted you...or thats the case? Anyway, sorry if was in that way. But with others words: I think if you have a good idea, the best will be implement it and create a pull request, or you think that the best will be through ideas and wait for the works of others? As i see you sure can test it and you also know how the kde menu works. I'm not...

[andrebrait]

@lestcape I didn't mean like saying you love me, man. Hahaha. It was the "fork it and do what you want with it". This kind of thing drives people away and make they regard you in negative ways. I know you meant what you said, I didn't take it in any bad way. I'm just giving you an advice because I myself went through some bad situations because of not being 'nice'. Working with people unfortunately require that we sometimes dose our tones. You haven't insulted me in any way!

Like, the second part of this last answer was really nice (the "I think if you have a good idea, the best will be implement it and create a pull request" part). And of course I don't expect to throw ideas and that someone will implement and test them, but I won't start working on something that other people in the project think it's not viable. So, getting a positive "hm, this might work, man... can you code it?" answer first is important. Just as getting a negative like "this won't work, pal... sorry" is important too.

That goes for my software too. Sometimes people request enhancements and stuff and I usually discuss with them the reasons and benefits and even some of the implementation if they happen to be developers themselves. Sometimes I ask if they can provide the implementation. Sometimes I like the idea and decide to do it myself.

[ghost]

@andrebrait I'm not a native speaker, as you can see... So please, try to read my comment the best as you can... I think your idea will not work as we are talking about different programming technologies, but also i don' t know anything about the kde menu, so there are a possibility that something could be better and if this possibility have a good chance for you, that will be good. I will take care of not speak on your comments any more... Like you say some people are sensitive to some sort of thing... Good look waiting for a response of someone here... It's not normal that this type of comments will have a response. Read all comments here and you will take an idea of what i say.

[andrebrait]

@lestcape I see. I'm not a native speaker as well. Please don't hesitate in commenting in stuff I say. I won't go into unrelated things anymore.

I'll be looking into how KDE runs its search and check if there's any part of it that can be used to improve Cinnamon's.

[janw-me]

It saddens me to see that this issue has been open for 5 years. And a bunch of related like requests also going nowhere. :(

[JosephMcc]

Lets keep this in one place: https://github.com/linuxmint/Cinnamon/issues/4053

[minemax-ua]

I hate this new option as well. It's so annoying...

[M4rc3lv]

I find it hard to find my apps using the search field in the menu. For instance: I know I have a labeling app so I type _label_ in the search field: no results. When I type _gla_ it finds _glabels_. If I could only remember the first letter of every app then it works. For me a partial text search would be nice so that _labels_ would also find _gLabels_.

[NikoKrause]

@M4rc3lv The search has been recently improved a lot by @mtwebster. The results are no more alphabetically ordered, instead they are reordered by best matches. The new changes will make it into Mint 20.1. If you are using Mint 20 or Mint 19.3 and don't want to wait, you can try the CinnVIIStarkMenu applet. I have backported the enhanced search feature there.

[M4rc3lv]

Wow, this is great. There are so many options to setup this menu. It really is made with ease of use in mind.