Version: (using KDE Devel) Installed from: Compiled sources As new search engine become popular, the actuals command-line parameters of kpdf and text-editors become too restrictive. Just adding a --search option in command line the transition between search engine (my proposal is strigi) and the viewer/editor become seamless. I explain better, actually you search for the word "hydroeletric", and the search engines shows you that you have a document, generic.pdf, containing this word. If you open it you need then to hit ctrl+f, insert hydroponic and go to desired part. If instead the search engine could launch: #kpdf generic.pdf --search "hydroelectric" you would find yourself directly at the desired page (or at first instance, with search dialog open). This can be valid also for kwrite, kate, etc.etc.
whops, *insert hydroelectric and go to desired part. sorry
Kate supports --line <line> and --column <column> paramters to navigate to a location inside a document. I do not know if strigi has that information?
I don't think so, it just collects all the words of a document. Also it's supposed to get only first occurence of every word (for database space size....)in a document, so it would be really better to have the search dialog open and already "filled" (like what happens when you select a word and then hit ctrl+f .....)
Strigi does not know the line number of text files form the index. The GUI that you use for searching could look for the line number and start kate at the right position. However, since nearly every app has a search function, allowing a command-line parameter which passes the search terms is more versatile. You could run: okular --highlight 'kde' --highlight 'release' myfile.pdf On the search GUI side, we'd need a configuration file which knows about the various attributes that are supported by the different apps. Cheers, Jos
As KDE uses now completly other stuff for search, this is out of date ;)