The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
Re: Tenor?
by aaa on Saturday 19/Aug/2006, @03:17
|
There's a 'strigi' desktop search project that seems to be advancing fast, but contextual linkage is more than full-text search. Actually a full-text index doesn't contain explicit contextual information of any kind, and it can only be used to infer textual resemblances.
What I mean is you can notice that two files contain similar words, but you can't, for instance, notice that they are usually edited simultaneously. (Which would be nice to know within 'Open...' stuff).
To answer your question, yes, contextual linkage in KDE 4 is dead, unless somebody can tell us more...
|
[
Reply To This | View ]
|
Re: Tenor?
by superstoned on Saturday 19/Aug/2006, @03:36
|
well, dead is a big word, there is still some thinking about it. but nothing concrete, no.
|
[
Reply To This | View ]
|
|
Re: Tenor?
by Anonymous on Saturday 19/Aug/2006, @03:20
|
Something like this for KDE4 will come. But I would bet not for KDE 4.0.
|
[
Reply To This | View ]
|
Re: Tenor?
by MM on Saturday 19/Aug/2006, @04:05
|
All that I found with Google is that Tenor "Chief Architect" Scott Wheeler is leaving SAP Linux Labs...
|
[
Reply To This | View ]
|
Re: Tenor?
by MM on Saturday 19/Aug/2006, @05:53
|
Didn't knew about that. On the other hand its still the only information that looks relevant. The official kde.org site does not give any hint on the status of neither Kat, nor Tenor; the latest information I found is dated 2005. SVN activity is at a low level (latest update 4 month ago).
IMHO, the fact that Scott leaves a Linux related job in favor of a more multimedia related one (whatever this means in detail), _may_ be more relevant than it looks at a first glance. In his blog he wrote: "KDE has slipped to the background of late and like many aging ... F/OSS hackers I'm left wondering if that's a real transformation -- a shift in priorities -- or simply a phase that will be revisited once life settles down a bit..." (http://www.kdedevelopers.org/blog/72, 06/29/2006), even if it just means that instead of Tenor he prevers to work on Phonon (http://www.kdedevelopers.org/node/2007) or something else any time in the near future.
Maybe this is the time to look for some assistance for Scott?
|
[
Reply To This | View ]
|
Re: Tenor?
by Scott Wheeler on Monday 21/Aug/2006, @08:56
|
I suppose I can drop in some details here:
Daniel was correct that SAP never significantly supported my personal KDE related projects. (There were however a few times that there were features or fixes that SAP needed inside of KDE that I was allowed to work on, but we're talking about maybe one week of KDE work per year.)
At my current job I'm doing cross-platform pro-audio stuff, which also has nothing to do with KDE, but for the moment I rather enjoy.
Sponsorship for my KDE work has never been something that I've sought. KDE is one of my hobbies and I'm fine with it staying that way. (Not to mention that I have to have normal full-time employment to remain in Germany where I've been for several years.)
So, then what's with Tenor?
Like I said above, KDE is my hobby. Sometimes I feel like working on it, sometimes I don't. (My life has also been really busy in the last few months, but really it's more of a matter of motivation than time.) When I don't feel like working on it, I don't. It's really that simple.
The desire to work on Tenor for me comes in waves. A couple months back I spent a few weeks hacking on it again. I haven't touched it since then.
So, will Tenor be in KDE 4?
Maybe. Really it depends on if and when I feel like hacking on it or if someone else decides to pick it up and run with it. Think of it as a surprise. ;-)
One thing that some people who ask me about this find interesting is this graph:
http://developer.kde.org/~wheeler/images/taglib-development.png
That, aside from being my first (and likely only) time to play with the Perl bindings for Qt, was the number of changes going into TagLib before I moved it into KDE's CVS. Every line is about a month (30 days). The main difference between how I've hacked on TagLib vs. Tenor is just that I kept very quiet about TagLib before I was ready to release. That's been my modus oparandi for most of what I have developed. (For instance, I was already using JuK as my day-to-day player before anyone else knew it existed.)
However, just from a searching perspective, I'm pretty excited about Strigi. I've talked a bit with the developers and almost all of the work that they're doing is orthogonal to the interesting parts of Tenor and the design of Strigi impresses me more than Kat did (both from an API and information retrieval perspective). They've got multiple backends and building one that used the Tenor store would not be terribly difficult.
Hmm, I'll probably blog this as well since most of the activity on this article is from a couple days back. Hopefully this clears up some of the current Tenor ambiguity.
|
[
Reply To This | View ]
|
Re: Tenor?
by MM on Monday 21/Aug/2006, @11:55
|
Many thanks for your response. I'm really happy and delighted to read that Tenor is definitely not dead, as some people claim ;-)
One thing I am wondering about is, whether it is too early to change KDE apps to support Tenor, as soon as it is there.
I don't know if the API is already there, but even if not, it may be interresting to see what happens, if there's a DCOP (or DBUS) service that accepts notifications (e.g. from KMail saying that 'this' document has been 'sent' from 'xy' by 'email'), so everyone (may it be Tenor or any program else) is able to connect to that service for listening what happens on the K desktop.
E.g., someone may find that it would be a good thing if KDE apps would also send notifications on what documents they are now going to open, and which one they are going to close (and to utilize this in some kind of 'task menu', that shows currently open documents, instead of 'tasks').
I'm not sure if this is the way to go. Is DCOP/DBUS a viable solution for this kind of task? Or is a library better? Is it too early to create an API now or does it already exist?
However, thank you for answering, and for your work.
|
[
Reply To This | View ]
|
|
Re: Tenor?
by jayKayEss on Saturday 19/Aug/2006, @08:53
|
Seems like Tenor is not so important now that there's a decent KDE frontend to Beagle. I've been using it in SuSE and it's quite nice.
http://www.kdedevelopers.org/node/1820
|
[
Reply To This | View ]
|
Re: Tenor?
by aaa on Saturday 19/Aug/2006, @09:13
|
This is not the point at all. Beagle is a desktop search engine. Tenor is/was supposed to be a contextual linkage engine, see my previous post for the difference among the two.
|
[
Reply To This | View ]
|
Re: Tenor?
by hill on Saturday 19/Aug/2006, @12:01
|
Isn't that a file system job?
|
[
Reply To This | View ]
|
Re: Tenor?
by Aaron Krill on Saturday 19/Aug/2006, @14:58
|
Ok, its been a while since I've posted here, what the HECK is with that crazy anti-spam thing? Thats funny...
It isn't at the moment, but it should be. Unfortunately the three most used fileystsme (Ext3, XFS, and my favorite, ReiserFS) don't support this, and don't support plugins. Reiser4 does, but nobody uses it since it's not in the kernel yet.
But then someone would still have to write a plugin for Reiser4 to make it handle contextual linkage, which would majorly increase read/write time for the filesystem and also increase the filesystem's footprint.
For now its best left to userspace, where we can pick and choose what gets what kind of information.
|
[
Reply To This | View ]
|
Re: Tenor?
by Corbin on Saturday 19/Aug/2006, @16:44
|
No, Tenor was meant to be able to search in ways such as 'file John sent me' and be able to see all files that you received from 'John' (whether you got them via an email in KMail, or over IM in Kopete). Stuff like that beagle can't do without lots of help, because the programs (in this case, kmail and kopete) would need to include the functionality to say either in the extended attributes of the file, or tell some central DB that 'John sent this file'. The file system has no way to know which program created/modified the file, much less that it was John that sent the file to you.
So the difference:
With Beagle you search for stuff in the file (eg, contains the phrase "the dogs are weird!"), with Tenor you would search for stuff ABOUT the file(eg, "file I sent John" or "file I downloaded from svn.kde.org").
|
[
Reply To This | View ]
|
Re: Tenor?
by Derek R. on Sunday 20/Aug/2006, @02:15
|
Personally, I don't want to even touch that Mono thing. In Gnome camp they are desperate to use Mono because it's clear that GTK and C are not leading them anywhere, but KDE has already a very nice and not encumbered development framework. Beagle solves an interesting problem, but a pure KDE solution is still needed IMHO.
|
[
Reply To This | View ]
|
Re: Tenor?
by Mark Hannessen on Sunday 20/Aug/2006, @02:55
|
C is not THAT bad, and mono uses gtk# for it's gui.
the only real benifit i see is that this will give you a object orientated langauge.
|
[
Reply To This | View ]
|
|
Re: Tenor?
by idoric on Sunday 20/Aug/2006, @01:18
|
http://www.glscube.org/ is a good alternative, because it's real.
|
[
Reply To This | View ]
|
GLScube
by skierpage on Saturday 26/Aug/2006, @22:49
|
GLScube sounds good and appears more elaborate than Strigi, but as other posters note, the issue is getting the semantic details to the search subsystem automatically. If I save an attachment from an e-mail message, I want "the system" to set all the "Sent by John" and "Subject of original e-mail" metadata; there's no way I'm going to enter all that metadata myself every time I click Save.
Also: "glscubefs... is a user-level file system that encapsulates the features of GLSł in a traditional file system interface". Another day, another VFS!
Eventually there will have to be standard APIs for apps to provide metadata on save and other events.
|
[
Reply To This | View ]
|
Re: GLScube
by Milan on Monday 28/Aug/2006, @06:40
|
Re: Also: "glscubefs... is a user-level file system that encapsulates the features of GLSł in a traditional file system interface". Another day, another VFS!
What's wrong with that? It only allows application that doesn't use directly GLS3' interface to use search functionality in it's file open dialogs...
The GLS doesn't use Fuse for indexing files.
|
[
Reply To This | View ]
|
|
The Fine Print: The previous
comments are owned by whomever posted them.
( Reply )
|
|
![[KDE Dot News]](http://www.kde.org/dot/Images/kdedotnews.gif)
