The KDE development team is working hard on the KDE 4 platform. KDE 4 will include many exciting new technologies which will greatly enhance the functionality of KDE. One of these new technologies is Decibel. We would like to give you an idea of what Decibel is all about.

In putting this article together, the KDE promotional community was able to get most of the information from the lead developer of Decibel, Tobias Hunger. Tobias lives in Germany and studied Computer Engineering at the University of Kaiserslautern. Upon graduating, he found a job as a consultant for a small company specializing in systems management. Currently, he is employed as a software developer for basysKom GmbH.

This article is part one of a four part series about Decibel. In part one, we would like to provide a general overview of Decibel. Part two will define several terms related to Decibel. Benefits for developers will be covered in part three. Finally, part four will discuss benefits for users.

People use their computers to communicate with others. Usually, they want to communicate as close to real-time as possible. Email, instant messaging, and Voice over IP (VoIP), are some of the different ways people communicate using their computers. Each of these has its strengths and weaknesses. Ironically, each of these means of communication do not talk very well with other means of communication.

This is where Decibel comes in. Decibel is a service, not an application. The goal of Decibel is to create a bridge between different communication technologies. Decibel will make it easy to integrate real-time communication technologies into applications, Tobias says. Decibel provides a central storage place for settings of real-time communications. This will allow one communication application (say, email) to talk to another communication application (say, instant messaging) without having to learn a new language.

However, Decibel is not going to become yet another isolated box dealing only with communication. There are at least two ways Decibel will be able to connect to technologies and applications not normally associated with communication. Because Decibel allows programs in general to talk to each other in a more streamlined manner, programs that are not related to communication can also take advantage of this technology. For instance, document editors (such as word processors or graphics editors) could use this technology to allow better collaborative editing.

Also, Decibel is being developed to integrate with other KDE technologies. For instance, Phonon is a KDE technology that deals with integrating multimedia programs and services. It is possible for Decibel to work with Phonon in situations such as encoding and decoding voice data during a VoIP conversation.

In part two of this series on Decibel, we will define some terms to help further enhance your understanding of Decibel. In the final two sections, we describe potential benefits for both users and developers, and provide information on how to get involved with the Decibel project. The goals of the Decibel team are wide-ranging and forward-thinking. They have done an excellent job of specifying their vision. However, they are still in the beginning stages of reaching their goals. Much work needs to be done. The Decibel team would appreciate any help they can get.

Comments

Telepathy is pretty much a FD.org standard, and Decibel is an implementation (I think Telepathy also includes a simple reference implementation as well, like Tango is a spec for naming icons, but it theres also the Tango icon theme which is an implementation of the specification (Oxygen will follow the Tango naming spec, IIRC several of the people working on Oxygen also worked on Tango).

Some commenters are concerned that Decibel will result in bloat and the forced integration of unwanted apps. I'd like to clear that doubt up.

The distinguishing factor between bad and good integration is the degree of coupling.

The MSN integration mentioned above is an example of tight coupling. Tight coupling is good when you want to get something done quickly and flexibility be damned, but doesn't leave you many choices afterward.

The coupling which Decibel offers, like KIMProxy before it in KDE 3, is loose coupling. In this model no component is bound to a particular other component. Decibel defines interfaces, that allow any component that implements that interface to be replaced with any other component.

For example, with KIMProxy we were able to integrate Kopete and KAddressbook to show contact status in KAddressbook. However this was no tight coupling. As other applications implemented the KIMProxy interface, these could be used instead, for example, substitute Licq or Konversation for Kopete as the sources of contacts' online status. This is loose coupling, and this is what Decibel provides.

Too complicated and time consuming for beginners! And why should someone who uses Ubuntu only use Gnome apps because of better look and feel? It's a big limitation if a user shall not use KDE applications in Ubuntu or vice versa...

Integration of both DE's is the most important thing. Portland project is a very good step in the right direction. But KDE and Gnome should use same things for storing configuration (like gconf or sth. else) etc.

All power to standards, it's going to help us. Most new tech from KDE4 is not existant in Gnome. But that's only a matter of time I guess.

But can't we agree that "beginners" are best off using only one desktop and its integrated applications anyway? I personally hate the idea of letting "beginners" mess around with OpenOffice, FireFox and and rest-desktop.

With KDE 4.1 and KOffice 2.1 at latest, I would assume there will no reason at all anymore, to use anything from the other desktop. Sure Gnumeric will still be better than KSpread maybe, but why care? I personally use only KDE applications nowadays. Konqueror, KWrite, Krita, Kate, Eric3 (ok, at least QT), KDevelop, Digikam, Kmail, Kontact, Konsole, Amarok, etc...

And that's because I find consistency of higher value than most everything. There is Firefox and OpenOffice for situations where my KDE environment currently is not sufficient for reasons outside KDE's responsibility, external broken formats, so I am very happy.

I am very confident a "beginner" can be very happy with pure KDE 3.5.6 and applications already. For the next round, I would be certain.

Greetings,
Kay

PS: I would also sell all shared on Gnome, if there were any. Ah, gone those Novell shares ;)

The new tech in KDE4 is indeed exciting, though much of it is built on top of freedesktop.org (and other free software) standards that GNOME has been very instrumental in building. Phonon, for example, is a high-level API that wraps lower-level APIs in a KDE friendly way; yet, it is not necessarily new tech in the sense that GNOME has access to the lower-level APIs, such as GStreamer, to which the GNOME developers contribute. Similarly, Solid wraps HAL, which is developed (in part) by GNOME developers. Decibel wraps Telepathy, which too is developed (in part) by GNOME developers. On the other hand, I'm not sure GNOME has anything like Sonnet or Plasma.

It seems to me that over the last several years, GNOME developers became disillusioned over developing new technologies under the GNOME umbrella because they feared that other groups, such as KDE and Mozilla, would not use the new technologies but develop their own equivalents. So, the GNOME developers began putting more and more energy in developing the technologies in independent places, such as freedesktop.org, where there was a better chance that KDE and others would use them and contribute to them.

These new technologies were often written in C, however, using GNOME-like coding conventions (and sometimes use GLib as well). So, it makes a lot of sense for KDE developers to wrap these APIs in a way that suits Qt/KDE conventions.

So, based on all of this, I think it's inaccurate to say that GNOME doesn't already have much of what's coming in KDE4: they're just using the technology directly from freedesktop.org and other places without wrapping the APIs. That said, the KDE4 technologies look very exciting, and it will be interesting to see how versatile the frameworks will be with the various back-end plug ins. Good luck to KDE4.

I don't think its because GNOME devs became "disillusioned", I think that Gnome and KDE had a bad fight in the beginning over QT licencing and over the last few years the devs _both_ groups have gotten over it and they are both working togeather.

Take this quote

"Decibel wraps Telepathy, which too is developed (in part) by GNOME developers."

True but what you don't mention is that KDE devs are also working in Freedesktop.org and probobly also worked on Telepathy. not "disillusioned" just working togeather.

> But can't we agree that "beginners" are best off using only one desktop and its integrated applications anyway? I personally hate the idea of letting "beginners" mess around with OpenOffice, FireFox and and rest-desktop.

This is what I meant with I do not want to restrict me in using software because of a toolkit which they use.

How shall I tell people they shouldn't use Gaim, Gimp, etc. under KDE? They are professional apps and not using them because working in KDE means not using great software.

That's why I think there must be a central configuration place: if you use KControl you should be able to set fonts, themes, colors for Gnome apps and vice versa. If there is a solution like that people are not forced in using only apps for Gnome OR KDE if they want to have a common look'n'feel.

I wouldn't underestimate the importance of look'n'feel for many people. Otherwise they ask rightly "why does Gaim look completely different than Konqueror" etc.

KDE and Gnome should even use common user interface guidelines and common keyboard shortcuts!! Why is settings dialog in Gnome apps under "Edit" and in KDE apps under "Settings" etc.? -> It's too confusing!

Interesting to mention Windows isn't consistent either with toolkits. Compare Borland / Delphi and .Net apps. Compare the menu's of Word, Visio, Visual Studio, Windows Explorer and Notepad. You can tell these applications are built with different toolkits.

The reason no one is annoyed by it is the consistent colors and fonts these applications all use. This makes a huge difference!

"This is what I meant with I do not want to restrict me in using software because of a toolkit which they use."

No one is restricting you but there are advantages of sticking to one, especially in the beginning.

"How shall I tell people they shouldn't use Gaim, Gimp, etc. under KDE? They are professional apps and not using them because working in KDE means not using great software."

Don't, tell them to try Kopete and Krita, if they prefer Gaim, despite its lack of intergration, then let them.

"That's why I think there must be a central configuration place: if you use KControl you should be able to set fonts, themes, colors for Gnome apps and vice versa. If there is a solution like that people are not forced in using only apps for Gnome OR KDE if they want to have a common look'n'feel"

A common look and feal is a lot more than just Kcontrol, I havn't used Gnome but I'd be suprised if it didn't have a very diffrent menu structure from KDE. There is also things like the save file dialoge, there is one standard and very good one for KDE. There is probobly a standard Gnome one. They're both diffrent.

Of course if you just want to do the basics just download a Gnome theme with an identical KDE counterpart and install both.

I may be unique, but I like to switch around between Gnome and KDE from time to time. (That's not the unique part - I know others do that) But while I'm in each, I only use apps from that environment as much as possible.

What I'd like to see is a central place to keep settings, confs, etc. For example, I should be able to easily access my bookmarks in both Konq and Firefox. I should be able to read my mail in Kmail or Thunderbird without having to download the same messages twice.

Why do through this hassle? The author of this thread metioned on reason - visual consistency. It really adds a lot when I have to spend hours in front of the cpu at work and home. But there's also integration! When I'm in Kopete and click a URL it launches Konq (or should - if it doesn't) so I'd like to be able to access my bookmarks. Or email contact in Kopete should launch Kmail with all my settings from Thunderbird.

Perhaps via freedesktop we can do something like this. There will be some settings specific to each program and those can be in .program_name, but the common files could be in .messaging, .internet, etc

I think that software should be about inteligent features not "inteligent" decisions. what I mean is that I don't want kopete to start kmail, but I love the smile in kmail as a notify for a user being online in icq/msn/jabber. a common communication history would be even more avesome. if a user is offline in icq maybe I would like to send her a email, but it shouldn't be automatic, a nice little icon for voip/mail would be more than enogh. the first step should be to find out patterns of user behavior, then provide actions that are likely for the use case.

From my point of view, the whole thing goes to the right direction but not the whole way. Lets make a diffrent approach for application integration. I will call it "aspect oriented applications" (nothing to do with the Java thing). Instead of making the applications integrate theirselfs we should make document integration. In my environment a lot of small business companies have a lot of documents such as word excel access emails and a lot of other information. But the informations about its relation together is "stored" only in the brains of the employes. Who nows that the document Offer-2006-10-12-ProductA.swx has something to do with the email "Thanks of the Offer" replayed at 2006-10-20 sent to mr. Smith. And the spreadsheet "Caluculation-2006-10-11.swx" is the calulation for that offer. So, only the employe who was working on that business process knows the relation between all this informations. So if we want make a better application integration, we should find a efficient way to link all these informations together in a assotiative way such as a human does it. So lets think about a small and easy szenario: In the above case it whould be nice to have a central address store for all desktop and business apps. Attached at this address store a workflow engine should link all workflows (such as the above calulation, offer, acceptance of this offer etc) together with the address records of the customers, partners and supplirs etc. This is just one szenario, there might several others for developer companies, it integrators, universities and a lot more, but all have together that the assotiation of all those documents and informations can be stored in a defined and standard way. And at the end (as I hope so) we will no more work with files on a fileshare (nfs or smb or something else) we will rater have "documents" which are stored in assotiative database by which each of the attached workers (employes etc) can refind all infos to a worklow a other worker has made without having to use such helper programs as beagle or other search engines. All informations are pre se stored in a refindable way.

I've read it. But is the same as a wrote above. It goes one step ahead but not the whole way. It isn't about meta data it is about the whole relation between the document data itself. I my vision the "My Computer" or "Arbeitsplatz" (in german) doesn't show files and mount points anymore. It rater will be a database frontend to search and create new document regardless which applications is used to create it.
It seems to go the same way as the most of the opensource projects goes, first everybody implements its own way, which brings a lot of diffrent approaches to solve the same problem, and after some time all of them see that a standardized concept will be better and after that a central workgroup makes this standardization.