What about using keywords instead, like Firefox allows it? For example, "gg:" would run a Google search on the rest of the string; "wk:" for Wikipédia, etc. (OK, maybe better for an extension...)

That's fine (if the designers say so), but it's quickly accelerating from "nifty thing" into "obscure feature".

If people actually use the buttons, then maybe just a quick re-tool of it would be enough: Don't select any opensearch buttons by default. I just had a hunch that nobody used it intentionally, so offered to take the sledgehammer approach instead (I still have that hunch).

Created attachment 208164 [details] [review]
search: Junk the OpenSearch system

The original design for the overview had buttons for searching for
Wikipedia and Google, but in practice this is a bad idea. The buttons
are the default activations, meaning that using the overview as a
fluent motion of launching something - "firefxo<Enter>", will launch
Google/Wikipedia.


Commit message needs work, but otherwise this is fine.

Review of attachment 208164 [details] [review]:

Quote from the new search design page[1]:
"When the web browser application does not return any results, a 'Search Web' entry should be displayed in its place. Selecting the entry passes the search term to the browser and initiates a search. "

So we still need it; we probably have to present it in a different way then we do now though.

1: https://live.gnome.org/GnomeShell/Design/Whiteboards/Search

(In reply to comment #4)
> Review of attachment 208164 [details] [review]:
> 
> Quote from the new search design page[1]:
> "When the web browser application does not return any results, a 'Search Web'
> entry should be displayed in its place. Selecting the entry passes the search
> term to the browser and initiates a search. "
> 
> So we still need it; we probably have to present it in a different way then we
> do now though.

I suspect that the easiest implementation would be to let epi return a "Search Web" entry if nothing else matches though.

That's still a typo catcher, so while we can junk this code in the Shell, I'm still not a big fan of it.

I would also prefer to restrict the scope of the Shell search: applications, files, contacts, etc.

Using an external search engine as fallback when we can not find what the user is looking for is not obvious, specially when (at least in 3.2) there is no indication that pressing Return will perform a web search.

This is an issue that would benefit from having some usage data.

Another example of the problems with the current situation:

 - Launch Overview
 - type '/usr/bin/gedit', Enter
 - web browser is launched
 - user gets a Wikipedia page: "The page "/usr/bin/gedit" does not exist..."

Now, this is probably two different bugs. One is that, as reported here, web searches are performed unexpectedly. This might be fixed by removing the OpenSearch system altogether, or by placing the search functionality in the overall search results instead of at the bottom.

The second bug is that the Overview does not recognize application paths.

(In reply to comment #8)
> The second bug is that the Overview does not recognize application paths.

I'm not convinced that it should.

(In reply to comment #9)
> (In reply to comment #8)
> > The second bug is that the Overview does not recognize application paths.
> 
> I'm not convinced that it should.

Then what should be the expected behavior when the user enters one?

Launching gedit is not the best example; I actually encountered this problem when I tried to run '/opt/eclipse/eclipse'.

(In reply to comment #10)
> (In reply to comment #9)
> > (In reply to comment #8)
> > > The second bug is that the Overview does not recognize application paths.
> > 
> > I'm not convinced that it should.
> 
> Then what should be the expected behavior when the user enters one?

The same as any invalid input. If you enter "potato", nothing will come up on my machine, which is the expected behavior. Do you want us to check for a specific path on every input?

If I enter "/usr/bin/g", should we show every binary that starts with that prefix? The fundamental law of realtime search filtering says "yes": entering new characters should not add more results -- every character entered excludes some set of results from a large pool. This is quickly turning into a large disk scan on either startup or every character.

Should we allow launching any file in this manner, or just executables? Either way, we'd have to check the executable bit to determine what to do -- another disk hit.

> Launching gedit is not the best example; I actually encountered this problem
> when I tried to run '/opt/eclipse/eclipse'.

That's what the Alt+F2 Run dialog is for.

(In reply to comment #11)

The outcome of entering "potato" and pressing Enter is https://en.wikipedia.org/wiki/Potato here.

All that I am saying is that when entering a full, valid path and pressing Enter, https://en.wikipedia.org/wiki/Special:Search?search=%2Fusr%2Fbin%2Fgedit is very far from the desired or expected outcome.

Maybe a solution would be to recognize those special cases, so IF you enter a full path AND the application exists AND there is no other valid match, THEN we launch the desired executable.

But that is a different issue from the present bug (admittedly, made worse by launching a web search instead of telling the user that the given text could not be found).

(In reply to comment #12)
> All that I am saying is that when entering a full, valid path and pressing
> Enter, https://en.wikipedia.org/wiki/Special:Search?search=%2Fusr%2Fbin%2Fgedit
> is very far from the desired or expected outcome.

Unless you paste the path, you won't enter a full, valid path all at once - you will start with '/'; would you then expect that to match every single file in the system?

(In reply to comment #13)
> 
> Unless you paste the path, you won't enter a full, valid path all at once - you
> will start with '/'; would you then expect that to match every single file in
> the system?

No, in this particular case I think that it would be fine to handle exact matches without autocompleting.

The Alt-F2 dialog already has some of this functionality; for instance, "/" opens Nautilus on the root folder, "/opt/eclipse/eclipse" launches the application, etc.

Created attachment 210635 [details] [review]
search: Junk the OpenSearch system

The original design for the overview had buttons for searching for
Wikipedia and Google, but in practice this is a bad idea. The buttons
are the default activations, meaning that using the overview as a
fluent motion of launching something - "firefxo<Enter>", will launch
Google/Wikipedia.



Rebased after search rework.

Created attachment 213620 [details] [review]
search: Junk the OpenSearch system

The original design for the overview had buttons for searching for
Wikipedia and Google, but in practice this is a bad idea. The buttons
are the default activations, meaning that using the overview as a
fluent motion of launching something - "firefxo<Enter>", will launch
Google/Wikipedia.

*** Bug 675914 has been marked as a duplicate of this bug. ***

*** Bug 668987 has been marked as a duplicate of this bug. ***

Created attachment 214982 [details] [review]
search: Junk the OpenSearch system

The original design for the overview had buttons for searching for
Wikipedia and Google, but in practice this is a bad idea. The buttons
are the default activations, meaning that using the overview as a
fluent motion of launching something - "firefxo<Enter>", will launch
Google/Wikipedia.



Remove the now unused shell_util_parse_search_provider

Attachment 214982 [details] pushed as ef4231b - search: Junk the OpenSearch system


I'm going to tentatively push this because Doshitan's patches rely on it. It's just code removal, so it shouldn't require any major review unless I missed something. I've been running on it for quite a long time, and have not encountered any issues. If it causes issues, we can always revert.