On LinuxPlanet, Kurt Pfeifle explains details about Tenor, a framework that will facilitate new ways to locate and otherwise manage content. Learn about the background of Tenor, what differentiates it from "desktop search tools" and why this new approach is needed in a world of ever growing disk space. Additionally, the article provides some insights from Scott Wheeler, one of Tenor's authors and primary designers.
Dot Categories:
Comments
It is actually, and honestly a very annoying/good thing (depending on what I want to do, which I don't expect KDE to be able to telepathically figure out) with my config is that it does show up as the opened tar file over ftp or http. (It's something I forget which under file types, show in embedded viewer as default I believe.)
And tar, gzip, bzip all already are piped through eachother. The tar kio-slave only handles uncompressed tar files (As of at least KDE 2.x, as I last recall looking. I doubt it would have changed), and the appropriate gzip/bzip kio-slave is used automatically.
Ie, tar://home/user/example.tar.gz is really tar://gzip://home/user/example.tar.gz (or something like that)
Here's my proposal: stack the protocols at the beginning, using the username part of the standard URL format as the file path for the archive. I think this could be implemented with no changes to the KIO framework, all the work would be done in the new IOSlaves.
A simple one: open a zip file on an HTTP server.
zip:/@http://server/file
Open a bzip2 compressed tar file on an HTTP server
tar:/@bzip2:@http://server/file
A complex example: open a particular file in a passworded rar file through fish://.
rar:/rardir/rarfile:rarpass@fish://user:pass@server/file.
Though I have lot of respect for both Scott and Aaron and their capabilities to pull this off, I think this article is mis-timed and full of vaporware. I am sure it will be delivered with all (maybe more) or most of the promised functionality, we have some of the best people. The article has 5 pages three of which are just a waste of space, and the last two pages offer so little information about the technology itself.
The only new bit I got was that we have a formal name for "klink" and its called "Tenor." Rest was just a rehash of existing information that Scott has been talking about last few months.
I would wait till the ideas take shape, fuzzies become clear, and we have some code to show. Till then, lets not raise the hopes of others. KDE is not known for pushing vaporware.
Since when is talking about upcoming KDE technologies 'vaporware'? KDE 4 is of major interest to people here on the dot including some of the new and kool ideas planned. When Aaron writes on his blog about the Appeal project some of his talk comes off sounding almost like hyperbole, but I have confidence in his and other kde devs abilities. Granted nothing is concrete yet in the project, but calling it vaporware is a bit of a stretch, since it is quite clear it is in the idea stage. Vaporware is implied complete code.
Blogging about something like this is the perfect way to get the idea out, not on the high profile "dot." I did not object to the idea just the way it was pushed. Thank you.
You're flogging a dead horse here. This is something KDE doesn't do enough of in terms of talking about the projects and ideas they want to undertake and letting people know what's happening. Tenor is a bit more than just vapourware now, as you'd have understood if you'd read the article. What about WinFS or Hula? Neither of those actually work. At least no one is in any doubt as to what's going on here, and that these are people formulating solid ideas amd it says as much in the article. No, I don't think it's misleading.
If you have accusations of promoting vapourware then you should be complaining about that to the people who've consistently done that for about five/six years.
## KDE is not known for pushing vaporware. ##
----
KDE however is also known for being vastly inferior to Gnome so far. On the "marketing" side of things, not technology-wise....
This article (and some more I saw over the last months), and Aaron's blogs and postings here start to change this.
Aaron's hints also made me feel comfortable about the non-existance of any "vaporware" danger regarding Tenor.
So what's wrong with The Bible having adviced us "Do Good Things and Talk about Them!" ??
I guess both you and the guy above missed my point. Sigh...
Oh you're point? What was that, because I think it has been addressed adequately?
"Though I have lot of respect for both Scott and Aaron and their capabilities to pull this off, I think this article is mis-timed and full of vaporware."
Hyping the stuff KDE people are thinking and talking about a bit more doesn't hurt. It's something KDE actually hasn't done enough of. If you want consistent hype and vapourware constantly then you should be looking elsewhere ;).
It shows that KDE has thoughts on these matters and really wants to work towards them. Saying nothing too much does KDE some damage, as everyone thinks "Well, what on Earth are KDE doing?". Consequently, many people think the sun shines out of Beagle's rear, when it really does nothing special whatsoever - even if it does exist.
> I think this article is mis-timed and full of vaporware.
well, we aren't sharing things much publicly to date because we've been going through various revisions and research to get something we're comfortable with showing. it's not as far away as it may seem however. e.g. this isn't something you're going to wait 6 months to see, for instance, let alone for KDE4.
> I would wait till the ideas take shape,
we've been working on that since last summer.
> fuzzies become clear,
they're getting pretty darn clear to us by this point.
> and we have some code to show
indeed, and it's on it's way. one of our challenges is that as we get this ready for people to use, we need application developers aware of it and ready to poke at it and play with it. so we're trying to prep the development community a bit for its arrival as a "ready to abuse API". =)
and as people have become aware of it, they become excited (e.g. Kurt, in this case) and want to tell others about it. that's cool. people get excited and wish to share.
When searching for a document in Konqueror or KFind, they both list the documents matching the search criteria.
If a "search text" is given, that the document must contain, Konqueror again only displays the documents it finds, and KFind additionally displays the first occurrence of the "search text". They both do not show all occurrencies of the "search text".
One has to open each document, one by one, by clicking it, and if a specific document is larger than a view lines, it is faster to use the applications built-in search functionality, entering again the "search text".
For now, I can think of 2 solutions to this "problem":
1. Change KDE applications so they e.g. accept a parameter --find 'search text' parameter and then automatically open the search dialog which has the 'search text' already set according to the parameter. The user can then click "Find" to find the first occurrence of the search text (instead of entering the "search text" some dozen times).
2. Change the KParts so they are able to provide buttons for searching in both directions, and maybe highlight all occurrencies of 'search text'. (Has Google a patent on this? :-))
Both, the changed applications, and the changed KParts, would somehow need to be "marked" as "text finders" (this does not make much sense for KPaint for example).
Well, pasting the "search text" may do the trick as well :-)
What do you think?
Sorry for my bad english.
Like http://lists.kde.org/?l=kde-devel&m=111324648032583&w=2 ?
The text of files will be extracted with plugins, which also annotate the extract text with structural information. This can be used by both the search tool ("'blah' found in chapter 5") and by the viewer to open the document at the corresponding position.
Using only the search string might break if the text extracted by kfind and the text found with the viewer doesn't match 100%. kfind must also be aware of the supported search options of the viewer (case sensitive, wildcards..).
Well, this is really an implementation issue.
They show only the first line, because this way they can stop searching the file after the first match. And kfind provides only one listviewitem per found file, so only one matching line can be shown.
I also already thought about suggestion 1)
Alex
This sounds really cool - makes it hard to wait for KDE4 :D
Keep up the great work everyone!
Tenor will be revolutionary and seems to be an amazing technology, but it won't be ready for at least a year.
How about until then, the KDE team at least includes KIO-LOCATE into KDE 3.5?
I hope for kio_locate in 3.5 too. (I compiled it on my own and use it daily).
The main reason it could not go into 3.4 proper was that its author wasn't in favor. He said he had no time (exams) for a few months to maintain it properly, but he'd do it from early summer.
Hope this materializes...
Armin Straub, the author, has just asked for the inclusion in KDE.
It'll go in after the move to SVN. IIUC into extragear.
See http://lists.kde.org/?l=kde-devel&m=111328905108759&w=2
The concept of Tenor sounds realy nice.
I hope Tenor will make it possible to search with wildcards and operators, one thing I am missing in most of Desktop-Search-Engines.