So, what's the deal with Tenor anyway?

Reposted from the Dot:

> Didn't knew about that. On the other hand its still the only information that looks relevant.
> The official 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.

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:

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.


thanx for the info. as Tenor is supposed to be one of the cornerstones of KDE4, but it's development seemed to be stopped, it was quite hard to know what to say about it, esp when doing a talk or speaking with ppl at events.

By superstoned at Mon, 08/21/2006 - 16:39

This is why hype is bad. I think KDE got to where it is (probably the most used DE on linux) because for the longest time there was a focus on just producing a damn fine product and letting that speak for itself, relying on word of mouth for marketing. Then the marketing movement started, and suddenly there was a lot of hoopla about the features of KDE4.

If you look back a year, there were a bunch of stories and pie in the sky musings about how amazing KDE4 was going to be with all these features (Tenor, plasma). This gets peoples' expectations way up when in reality, the features themselves might never even appear.

Instead of being pleasantly surprised when they see cool new features in KDE4, users will now be disappointed that it didn't live up to the hype. Raising a fuss about possible glitzy features is a Microsoft tactic, and while it may drive up stock price, is not good for user satisfaction. That kind of thing only works when you're the market leader. If you're the underdog, you have to compete on quality.

Raising awareness for existing features is a great thing to do, but getting people excited about features that are nowhere near done or even certain to ever exist is a big mistake.

So yeah, I'm not trying to bitch at Scott for not hacking on Tenor enough, that kind of thing is to be expected. I'm just saying, don't count your next generation "desktop linkage" engines before they actually exist.

By leos at Mon, 08/21/2006 - 22:48

    If you're the underdog, you have to compete on quality.

I personally have little marketing experience, but this sounds untrue even to me. Sure, you and I and probably more technical people that choose products after carefully selecting several alternatives will be disappointed. But Linux is no longer just for technical people, and its a trueism that most people choose on emotion. (and only come up with reasons after they made the decision)

KDE will fullfill quite a set of the stated expectations, and will look good. This marketing of goals will only make people turn their heads and listen, take KDE4 into consideration even before we finished the cool uberfeatures.
So, hyping KDE4 has certainly not been all air and whatnot, and therefore I am confident that your statement quoted above is false.

By Thomas Zander at Tue, 08/22/2006 - 10:06

Tenor and Strigi could certainly go well together. One good distinction to make is that Strigi is in the first place an index of data that can be retrieved from files. This means all information in Strigi is redundant. Also Strigi does not directly store relations between files as Tenor proposes. As Scott, says these models are orthogonal. They meet at the search interface where information from both systems can be used to do advanced searching and clever filtering of presented data.

For KDE4, it would be great to have an set of classes that uses available information for Tenor, Strigi or other systems to filter what the user sees in e.g. file dialogs.

For example, if a user wants to open a sound file, the file dialog should not show folders that do not contain sound files. This information is already availabe from Strigi at the moment. Just list all files with a sound mimetype. This is fast, because Strigi indexes. A Qt4 model for filtering this information should not be hard to implement. There are similar scenarios where information from Tenor would be useful for filtering.

By Jos van den Oever at Mon, 08/21/2006 - 17:49