Some time ago, I dropped Google Desktop search, and went with Nepomuk, largely because it allowed me easily to search in a specific area of my filesystem, and thus severely constrain false hits. I am quite pleased with this tool, in comparison with Google's. I'm now wanting to be able to do more than simple single-term (or tag) searches.
However, I have been unable to find any documentation in the installed Kubuntu Help facility (or whatever it's called). Nothing. Very odd.
Online, I did find some good material:
* http://userbase.kde.org/Nepomuk - this has some very good information - really tells what this is, what is it trying to do, how to deal with problems, AND it appears to be frequently updated. It give the impression of a very active project.
* http://strigi.sourceforge.net/ [didn't work when I tried it - "the page is being remade" - I was referred to pages which either didn't exist or were useless]
* "detailed KDE Nepomuk Manual (February 6, 2012)" - http://kdenepomukmanual.wordpress.com/ - this has a lot of information, puts things in context well, and is housed in a WordPress blog, so it will hopefully be around a while.
* "KDE Linux Desktop Search with Strigi and Nepomuk":http://voices.yahoo.com/kde-linux-de...k-7339846.html - gives some information the resource above does not, and so is also worth consulting.
Now we get to the crux of my problem: I want to be able to use logical operators, as one customarily does with "advanced" searches. There is, it appears, NO information about this anywhere in the universe, except in my own notes, which derive from my experiments this evening. It occurs to me that others might profit from my sharing this:
* Nepomuk desktop search is accessed primarily in Dolphin - do this with "Ctrl+F". If you want the search results to tell you WHERE the found item is (duh) - which is really important when searching a directory tree segment containing multiple subdirectories and files, before invoking Nepomuk request display of "path" by clicking Dolphin's window column line (it typically contains "name", "size", and "date", by default), then click "other" in the modal window that appears, then "path" (it took me months to figure this out!).
* Basics:
** The search target can be either the filename or its contents; there are buttons in the search interface to specifiy which.
** The unit of search results is the file. Location IN the file is NOT returned.
** Search in a directory tree goes INTO all subdirectories.
** What is searched for is the character string(s) you give the search engine. There is a wildcard operator, but it is often unnecessary: "up" "so*" and "*up" all return all instances of "soup".
* Search results can be filtered -
** If Dolphin's "startup" settings has "show filter bar" clicked, entering a string in the text entry field will cause display of only those file names containing that string.
** Clicking the green "+" to the right of the search term entry field (visible after pressing Ctrl+F) allows access to additional filters - file type, date, ratings.
* Advanced search IS possible -
** Text operators and, or, not are the ones I have verified - caps do not matter. Use of such operators appears to slow the search; this matters mostly in content searches, as opposed to filename searches.
** Examples (using a directory containing text files each containing different recipes): "bread not nuts" gives me all files (recipes) in which the word bread appears and nuts does not, which eliminates my banana bread recipe, for example. And is the default operator and need not be specified; e.g. "chocolate nuts" gets me both my chocolate pumpkin bread and my chocolate cookies (because both contain "nuts"), and "chocolate or nuts" gets my recipes in which either or both appear.
** Two warnings
*** *Not* is tricky. "*not* {whatever}" appears to cause infinite looping, but {A} not {B} gives all A's which do not also contain B.
*** Do not use parentheses - these appear to cause infinite looping, sadly.
The best way to get a feel for all this is to test it out on a directory or directory tree containing a limited number of text files. Nepomuk can do much more than text files, but why not learn simplest materials.
Any comments, ammendations, etcs., would be welcome.
However, I have been unable to find any documentation in the installed Kubuntu Help facility (or whatever it's called). Nothing. Very odd.
Online, I did find some good material:
* http://userbase.kde.org/Nepomuk - this has some very good information - really tells what this is, what is it trying to do, how to deal with problems, AND it appears to be frequently updated. It give the impression of a very active project.
* http://strigi.sourceforge.net/ [didn't work when I tried it - "the page is being remade" - I was referred to pages which either didn't exist or were useless]
* "detailed KDE Nepomuk Manual (February 6, 2012)" - http://kdenepomukmanual.wordpress.com/ - this has a lot of information, puts things in context well, and is housed in a WordPress blog, so it will hopefully be around a while.
* "KDE Linux Desktop Search with Strigi and Nepomuk":http://voices.yahoo.com/kde-linux-de...k-7339846.html - gives some information the resource above does not, and so is also worth consulting.
Now we get to the crux of my problem: I want to be able to use logical operators, as one customarily does with "advanced" searches. There is, it appears, NO information about this anywhere in the universe, except in my own notes, which derive from my experiments this evening. It occurs to me that others might profit from my sharing this:
* Nepomuk desktop search is accessed primarily in Dolphin - do this with "Ctrl+F". If you want the search results to tell you WHERE the found item is (duh) - which is really important when searching a directory tree segment containing multiple subdirectories and files, before invoking Nepomuk request display of "path" by clicking Dolphin's window column line (it typically contains "name", "size", and "date", by default), then click "other" in the modal window that appears, then "path" (it took me months to figure this out!).
* Basics:
** The search target can be either the filename or its contents; there are buttons in the search interface to specifiy which.
** The unit of search results is the file. Location IN the file is NOT returned.
** Search in a directory tree goes INTO all subdirectories.
** What is searched for is the character string(s) you give the search engine. There is a wildcard operator, but it is often unnecessary: "up" "so*" and "*up" all return all instances of "soup".
* Search results can be filtered -
** If Dolphin's "startup" settings has "show filter bar" clicked, entering a string in the text entry field will cause display of only those file names containing that string.
** Clicking the green "+" to the right of the search term entry field (visible after pressing Ctrl+F) allows access to additional filters - file type, date, ratings.
* Advanced search IS possible -
** Text operators and, or, not are the ones I have verified - caps do not matter. Use of such operators appears to slow the search; this matters mostly in content searches, as opposed to filename searches.
** Examples (using a directory containing text files each containing different recipes): "bread not nuts" gives me all files (recipes) in which the word bread appears and nuts does not, which eliminates my banana bread recipe, for example. And is the default operator and need not be specified; e.g. "chocolate nuts" gets me both my chocolate pumpkin bread and my chocolate cookies (because both contain "nuts"), and "chocolate or nuts" gets my recipes in which either or both appear.
** Two warnings
*** *Not* is tricky. "*not* {whatever}" appears to cause infinite looping, but {A} not {B} gives all A's which do not also contain B.
*** Do not use parentheses - these appear to cause infinite looping, sadly.
The best way to get a feel for all this is to test it out on a directory or directory tree containing a limited number of text files. Nepomuk can do much more than text files, but why not learn simplest materials.
Any comments, ammendations, etcs., would be welcome.
) I don't have to compile it, which I don't know how to do anyway. This is simply NOT usable as is. That's just dumb. All that work, and it can't make it across the finish line to the actual user. (Sigh - nerdism strikes yet again...)
Comment