Bug 271600 - Dolphin does not find any result with "search for content" while neopmuk is enabled
Summary: Dolphin does not find any result with "search for content" while neopmuk is e...
Status: RESOLVED DUPLICATE of bug 318442
Alias: None
Product: dolphin
Classification: Applications
Component: search (show other bugs)
Version: 16.12.2
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: Dolphin Bug Assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-04-24 10:36 UTC by S. Burmeister
Modified: 2013-05-12 09:06 UTC (History)
8 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description S. Burmeister 2011-04-24 10:36:20 UTC
Version:           unspecified (using KDE 4.6.2) 
OS:                Linux

I searched for "smart" in .kde4/share/config with "from here" and "search for content". It showed 0 results. Then I disabled nepomuk and it showed 9 results.

.kde4 is not activated for indexing.

Query from nepomuksearchrc: query_9_timestamp=2011,4,24,10,32,44
query_9_url=nepomuksearch:/Suchergebnisse%20von%20%E2%80%9Esmart%E2%80%9C?encodedquery=%3C%3Fxml%20version%3D%221.0%22%3F%3E%3Cfilequery%20queryFiles%3D%22true%22%20queryFolders%3D%22true%22%20limit%3D%220%22%20offset%3D%220%22%20fullTextScoring%3D%22false%22%20fullTextScoringOrder%3D%22desc%22%20flags%3D%22%22%3E%3Cfolder%20url%3D%22file%3A%2F%2F%2Fhome%2Frabauke%2F.kde4%2Fshare%2Fconfig%22%20include%3D%22true%22%20recursive%3D%22true%22%2F%3E%3Cand%3E%3Cliteral%20datatype%3D%22http%3A%2F%2Fwww.w3.org%2F2001%2FXMLSchema%23string%22%3Esmart%3C%2Fliteral%3E%3C%2Fand%3E%3C%2Ffilequery%3E%0A

Reproducible: Didn't try
Comment 1 schmirrwurst 2011-05-16 19:40:13 UTC
I experience the same problem, nepomuk and strigi only find filenames, even if the button content is pressed, and there are definitly files with the content searched....
Comment 2 Stefan Vater 2011-10-07 12:03:55 UTC
Hi, I can confirm this bug with KDE 4.7.2 and OpenSUSE 11.4 (x86_64). I think, this makes nepomuk rather unusable from a users point of view. So why is it indexing all the time, when I cannot search something in the index? I think this is a very severe bug.

If anyone can help me "enabling" searching with nepomuk I would be very grateful!

BTW, for the bug hunters: bug 280428 might be a duplicate of this bug?!

Regards, Stefan
Comment 3 Sebastian Trueg 2011-10-07 12:23:13 UTC
(In reply to comment #0)
> I searched for "smart" in .kde4/share/config with "from here" and "search for
> content". It showed 0 results. Then I disabled nepomuk and it showed 9 results.
> 
> .kde4 is not activated for indexing.

I am confused. How do you expect Nepomuk to find anything in ~/.kde if it is not enabled for indexing?
Comment 4 Sebastian Trueg 2011-10-07 12:23:30 UTC
(In reply to comment #1)
> I experience the same problem, nepomuk and strigi only find filenames, even if
> the button content is pressed, and there are definitly files with the content
> searched....

I need some examples please.
Comment 5 S. Burmeister 2011-10-07 13:06:17 UTC
(In reply to comment #3)
> I am confused. How do you expect Nepomuk to find anything in ~/.kde if it is
> not enabled for indexing?

Using dolphin the user gets the same search UI for the use cases of nepomuk being enabled or disabled and for the user cases of searching in a folder that is indexed or not indexed. So from a user's point of view there is not difference between all of these use cases.

The content is found if nepomuk is disabled. Enabling nepomuk makes the search not find the content. Do you see what's broken? Enabling nepomuk finds less rather than more.

I expect to find the same content with nepomuk that I can find without plus some extra. This means that if I search within a folder that is not part of nepomuk's index the result must not be that nothing is found but that the search is handled as if nepomuk was disabled – which it is in fact for that folder. Or to put it another way – nepomuk should not hinder the "simple" search to find content but get out of the way if it cannot provide any results.

Currently enabling nepomuk hides the content of files.

The UI does not state "nepomuk cannot search the content of this folder because the folder is not indexed" but it displays "0 results" which is obviously wrong.
Comment 6 Peter Penz 2011-10-07 13:20:24 UTC
Dolphin should fallback to the filenamesearch:/ protocol for folders that are not indexed by Nepomuk. The most easy way to see whether the fallback is used is to check the state of the "Search Panel" (F12): If it is inactive the fallback is used.

This might be an issue in the Dolphin code... I've tested the fallback of course but probably there might be an issue with hidden folders.

@Sebastian: Sadly I currently don't have the time for checking this, as I'm very busy to reach feature-parity for the new view-engine. Please feel free to reassign it back to Dolphin.
Comment 7 Sebastian Trueg 2011-10-07 13:44:45 UTC
Reassigning to Dolphin as this is a GUI problem.
Comment 8 S. Burmeister 2011-10-07 14:05:53 UTC
(In reply to comment #6)
> Dolphin should fallback to the filenamesearch:/ protocol for folders that are
> not indexed by Nepomuk. The most easy way to see whether the fallback is used
> is to check the state of the "Search Panel" (F12): If it is inactive the
> fallback is used.

Isn't this broken by design since it will hide results from not indexed folders if the search is started in an indexed folder?

Example:

~ (indexed)
~/folder 1 (not indexed)
~/folder 2 (indexed)

Starting a search for content "from here" or "everywhere" in ~ would trigger the nepomuk search because it is indexed. But nepomuk would not find any content from within folder 1, since it is not indexed.

Disabling nepomuk would result in finding content in all of these folders.

So if one enables nepomuk there is no choice but to let it index everything because otherwise it will hide all content not accessible via nepomuk. I thought that nepomuk should add information rather than restrict it to its index.

The UI states "from here" which includes all sub-folders (example above) and "everywhere" it should rather state

starting from an indexed folder: "all indexed folders from here" and "all indexed folders"

starting from a not indexed folder "from here" and "everywhere within home"
Comment 9 Stefan Vater 2011-10-07 18:34:32 UTC
Sorry. I did not read the initial post correctly. But in my case, even files in indexed folders (like plain ascii text files) are not found. E.g.: I search "Potsdam" with "from here" and "content" checked. There are several text files in the folder with this word in there. But the search results in "No elements found". The folder is indexed and nepomuk/strigi is enabled. When I disable nepomuk and restart Dolphin, the files are found.

Can I check by another program if this is just a problem of dolphin, e.g., from the command line? 

But maybe, there is just something something misconfigured on my system...
Comment 10 Sebastian Trueg 2011-10-11 09:27:58 UTC
(In reply to comment #9)
> Sorry. I did not read the initial post correctly. But in my case, even files in
> indexed folders (like plain ascii text files) are not found. E.g.: I search
> "Potsdam" with "from here" and "content" checked. There are several text files
> in the folder with this word in there. But the search results in "No elements
> found". The folder is indexed and nepomuk/strigi is enabled. When I disable
> nepomuk and restart Dolphin, the files are found.
> 
> Can I check by another program if this is just a problem of dolphin, e.g., from
> the command line? 
> 
> But maybe, there is just something something misconfigured on my system...

This is fixed already. The fix is in 4.7.3 and I urged packagers to provide updates for their 4.7.2 packages. Hopefully you will get an updated package soon.
Comment 11 Sebastian Trueg 2011-10-11 09:29:25 UTC
(In reply to comment #8)
> Isn't this broken by design since it will hide results from not indexed folders
> if the search is started in an indexed folder?

As far as Nepomuk is concerned: folders which you do not index you never want to search. That is the whole point of it. Otherwise there would be no configuration (actually something I like to have some day).
Comment 12 S. Burmeister 2011-10-11 11:41:08 UTC
(In reply to comment #11)
> As far as Nepomuk is concerned: folders which you do not index you never want
> to search. That is the whole point of it. Otherwise there would be no
> configuration (actually something I like to have some day).

Well, that assumption is simply wrong. Searching does not equal indexing. While it might not make sense to index some source tree, finding content in it via a search does make sense. Indexing only makes sense to get more info out of files than plain text content/filename and if one wants a higher speed.

So what's the justification to assume that searching for filename/content in folders not indexed is assumed to be unwanted? Because this basically means that you have to index everything if you want the basic functionality that you got for free before nepomuk, i.e. the plain text/filename search.
Comment 13 Sebastian Trueg 2011-10-11 11:49:44 UTC
(In reply to comment #12)
> (In reply to comment #11)
> > As far as Nepomuk is concerned: folders which you do not index you never want
> > to search. That is the whole point of it. Otherwise there would be no
> > configuration (actually something I like to have some day).
> 
> Well, that assumption is simply wrong. Searching does not equal indexing. While
> it might not make sense to index some source tree, finding content in it via a
> search does make sense. Indexing only makes sense to get more info out of files
> than plain text content/filename and if one wants a higher speed.
> 
> So what's the justification to assume that searching for filename/content in
> folders not indexed is assumed to be unwanted? Because this basically means
> that you have to index everything if you want the basic functionality that you
> got for free before nepomuk, i.e. the plain text/filename search.

Well, I said "as far as Nepomuk is concerned". I did not say anything about non-Nepomuk searches which I do not work on.
Comment 14 Sebastian Trueg 2011-10-11 11:51:27 UTC
(In reply to comment #12)
> So what's the justification to assume that searching for filename/content in
> folders not indexed is assumed to be unwanted? Because this basically means
> that you have to index everything if you want the basic functionality that you
> got for free before nepomuk, i.e. the plain text/filename search.

And also this is exactly what I said: from a Nepomuk perspective indexing everything is the only correct solution. Everything else it a hack. I know that there are many users out there that do not want all files to be indexed yet. Still, that is how it should be from a technical point of view.
Comment 15 Peter Penz 2011-10-11 12:25:35 UTC
I understand Sven's point of view as a user, but from a technical point of view Sebastian is right: The current approach using the filenamesearch:/-protocol as fallback is a compromise (I would not call it a hack ;-)) that works for I'd say for quite a lot [1] usecases but in the end the only sane solution is to use Nepomuk for searching (or disable Nepomuk indexing completely and live with the limitations of the "traditional" search-approach).

Technically it would be no big problem to do both kind of searchs in parallel for one search-query and merge the results, but the problem is that you not only will get the benefits of each approach but also the drawbacks: In case of the filenamesearch:/-protocol this would meant that it might take ages until it is finished.

[1] As you say the fallback does not work for folders where folder A is indexed and folder A/B is not (nothing from B will be searched then as only the nepomuksearch:/ will be used), but solving this would mean launching both kind of searchs in parallel. The next question is what to do with the Nepomuk-dependent Search Panel in this case? Disable it as soon as at least one sub-folder is not indexed? This will result in additional bug-reports like "I've removed B on purpose from indexing as I don't want results from there, why do you disable the Search Panel?"

To summarize the current behavior of Dolphin is:
- As soon as a search is done from a folder that is indexed the Search Panel gets enabled and only the nepomuksearch:/ is used. This means if the user has turned off indexing for some subfolders no search-results will be shown.

- As soon as a search is done from a folder that is not indexed the Search Panel gets disabled and filenamesearch:/ is used. Even if sub-folders are indexed nepomuksearch:/ won't be used.

On other systems like Windows or OS-X this issue is a no-brainer as there is no fallback at all and everything gets indexed.
Comment 16 S. Burmeister 2011-10-11 20:04:13 UTC
Until nepomuk behaves and does not slow down other apps like kmail2 or the performance in general I'm afraid that it cannot claim to be as other searches on other OSs. In fact it is far behind compared to others because it supposedly does not want to be asearch – yet it replaces a search…

But you are right, it's the users choice and it should be communicated that enabling nepomuk cripples the basic content/filename search.
Comment 17 S. Burmeister 2011-10-19 10:48:45 UTC
One question in advance:

Does dolphin use the nepomuksearch if the folder is indexed but nepomuk's indexing is disabled? I.e. do I have to either disable all of nepomuk, including tagging etc. or delete nepomuk-strigi's index in order to avoid its broken search results?

(In reply to comment #15)
> [1] As you say the fallback does not work for folders where folder A is indexed
> and folder A/B is not (nothing from B will be searched then as only the
> nepomuksearch:/ will be used), but solving this would mean launching both kind
> of searchs in parallel.

At least when nepomuk returns 0 results this cannot be seen as a reliable result. Thus the simple search should be started or the user at least be offered a button to start it with the hint that nepomuk will only find results in indexed folders.

> On other systems like Windows or OS-X this issue is a no-brainer as there is no
> fallback at all and everything gets indexed.

Until nepomuk supplies the performance and features of a desktop-search, i.e. what the state-of-the-art desktop searches provide, including usable results list which do not simply list filenames, the user should be able to pick what search to use and not be forced to use nepomuk either nowhere or everywhere.

In the simplest way this would be an option in dolphin: "enable nepomuk search". 

Remember – I assume that dolphin is a file manager, a file manager and a file manager and its search thus a file search. I might be wrong with this assumption and dolphin wants to be a tag or content manager primarily and thus its search focusing on content or tags.

AFAIR nepomuk does not want to be a desktop search and thus does not focus on the features one would expect off a desktop search, e.g. result lists etc. This also means that it should not be used as a desktop search until it does provide state of the art performance and features compared to current desktop searches.

So IMHO dolphin should stick to a simple file search by default because it is a file manager – no matter whether there is some fancy tagging or indexing available. Anything else should be optional and disabled by default.

If nepomuk is one day capable of acting as desktop search, regarding performance, cpu usage, hdd usage, features etc. it could be integrated into file management by default.

Until then there should be an easy way to keep it out of dolphin's file functionality which includes searching for file names and file content.
Comment 18 Adrián Chaves (Gallaecio) 2012-09-23 06:31:51 UTC
- If you use “From Here” to search in a non-indexed folder, Dolphin should fallback to standard search.

- If you use “From Here” to search in an indexed folder with visible — include hidden folders only when the user has the “View hidden files” feature enabled for the current folder — non-indexed subfolders, Dolphin should provide a message stating that some subfolders are not indexed and the search won’t work for them, and then provide an action to change to the standard search, and maybe also an action to access the configuration for the indexed folders (System Settings -> Desktop Search -> Desktop Query -> Customize index folders…).

Would those be the right requirements? Am I missing something?
Comment 19 trionghost 2012-10-31 22:03:57 UTC
Now I can say one thing - search function in dolphin is completely useless if nepomuk is enabled, because:
- It's show only indexed files
= No folders
= No unindexed places
= No files that was, for example, just downloaded
= No hidden files
What's needed:
Option to search in hidden
Option to switch to normal search (without nepomuk)
Comment 20 Yassine SAKOUM 2013-02-09 17:47:53 UTC
(In reply to comment #19)
> What's needed:
> Option to search in hidden
> Option to switch to normal search (without nepomuk)

I completely agree with you there's no way to search in dolphin when nepomuk is enabled, this bug is really annoying me.
We need new options to control the search inside dolphin.
Comment 21 Frank Reininghaus 2013-05-12 09:06:36 UTC
I only found this bug report now - was not assigned to dolphin-bugs-null until now.

If I understand correctly, this report is about Dolphin not finding anything in non-indexed subfolders of indexed folders. This is the same as bug 318442.

*** This bug has been marked as a duplicate of bug 318442 ***