Monthly Archives: April 2006

KDE vs GNOME?

There was a post today at osnews.com about someone who thinks that he understands the whole situation of the “battle” between KDE and GNOME, and that this battle is now over. This is all just dumb, from the top to the bottom, and I want to explain why – through writing about it I hopefully can avoid that I explode in front of so much rubbish.

First: there is no battle

Some users fight each other in stupid flamewars, but hey, show me one thing where you do not find these kind of people. Besides that, the developers normally have a very friendly relationship and work together quite a lot: they share code, use programs of the other DE, talk about solutions, offer to make their programs desktop agnostic, and so on.
The project themselves are also coordinating their efforts, freedesktop.org and tango are very good examples for this. They sit together when they have to address important issues where Linux still have major disadvantanges (printing for example), and so on.

So: there is no war. There is no battle. There is cooperation. Sure, there is also friendly competition, but have you never competed with a friend and kept the friendship afterwards?
Whoever sees this situation as a battle is a dumb moron. So is the author of the article.

Second: no one cares about desktop environments

No one but some dumb morons and stupid flamewar-loving users is interested in the “which DE”-question. No one. Especially not independent software vendors (ISVs), they do not care, they don’t want to care, and they don’t have to because it is completly uninteresting for them. This is something everyone should have learned after the meeting in Portland which lead to the launch of the Portland Project.
The meeting was intended to get all fractions of the Linux desktop together with ISVs adn to discuss the problems. It turned out that the main questions ISVs are confrontated are completly independent form the question of which desktop environment you are using – and that these questions have to be answered by all Linux DEs in the same way!

To get a feeling of what I’m writing you should have a look at the task page of the project which describes the short, mid and long term tasks of the project. The tasks are pretty practical, and far away from any theoretical discussion about GUIs, DEs or licenses: How do I call the default Web browser? How do I call the standard file open dialog? How do I add a menu entry? How do I send an e-mail? How do I get teh default application for task xyz? How can I register to become a standard handler for mimetype xyz? And so on…
The list is long, but also very interesting. It shows that there is still a lot work to do until the normal ISV is able to port his application to linux without beeing an expert in twenty different linux distributions. It also gives a good idea why there are not to many ISVs which have started yet.

But in all these tasks and also in the reports and news about this meeting and the project you never read anything about any ISV who wanted to clear the DE-question. Why should they?

Third: conclusion

There is still a lot work to do in the desktop environment world in Linux – but the work is to provide the main tasks a application wants to do independent from the DE – like the function to call an opening dialog. That has to be implemented in a way that under GNOME the GNOME file dialog opens, and under KDE the KDE file dialog opens. The same is true for all the other “interacting” dialogs, functions and probably also for the font system and the theme/skin drawing system.
That will not be to easy, but with KDE 4 we will have the opportunity to implement it in KDE, and GNOME will be at KDEs side to implement it also asap. Read again: they will do it both side by side, not against each other.

And if you ever wrote something about any kind of war: just delete the article, or even better, replace it with something explaining the situation clear and explicit. And stop talking about wars.

In other cases you just will be the next target of some weird, late midnight “such-a-dumb-writer”-post ;-)

Phonon, Gstreamer and ALSA

Yesterday we had the release of the Phonon homepage. That brought up some news in different online media which reported over that fact, and among other’s there were an article on the german pro-linux.de.

In the discussion about this article it became clear pretty soon that there are two things which bother the users about Phonon:
* first: some of them do not know how Phonon differs from ALSA or for what you need it
* second: some users complain that KDE does not simply take GStremaer as default

Here is an explanation about these topics, together with some general things on how Sound under Linux works. The video-part is not really addressed, although I sometimes talk about “multimedia”, if you have comments how to extend it, feel free to post them.

First, there is the hardware – different sound cards, different sound hardware, and therefore different hardware drivers which are needed. To avoid the problem of implementing each driver for each piece of hardware into every program we need to abstract the hardware drivers into one kind of “standard driver” which can be accessed by all other programs. This abstraction layer can than implement all other hardware drivers and can talk to the hardware.
This abstracted hardware can accept all audio streams and commands which would go directly to the hardware in other cases. To keep it easy the audio streams are only accepted as raw audio data streams. The abstraction layer should not nbe bothered with the different types of music formats.
This task is done by OSS or by ALSA where ALSA is the standard for Linux and OSS is still used in Unix versions like BSD. The advantage of ALSA is in this case that it can not only accept one audio raw data stream, but several, and mix them together. So different applications can talk to ALSA and send them streams at the same time.

But, as I said, ALSA does only take raw data streams. Why? Well, imagine the amount of different audio data formats, the way how they could be handled (stream, file, etc.) and so on: MP3, OGG, WAV, ACC, WMA, RMA, etc. ALSA was designed as an hardware abstraction, and to keep a project living and developing it makes sense to not put all problems into one solution. Keep it simple, you might call it. There are enough problems you have to fight with when you are designing a hardware abstraction layer.

So we come to the second step: the multimedia framework. This framework is the part which can understand all the different media formats like the one’s above mentioned. Therefore several people state it should be able to handle some kind of plugins to provide an easy way of integrating new file formats.
Common multimedia frameworks are GStreamer, NMM, Xine, Helix and also the old aRts from KDE 3. Since OSS is not able to mix multiple sound streams some of these frameworks can overtake this job and therefore are also called soundserver. One of the reasons aRts was very popular in the beginning was that it addressed this problem very well.

The next step now is the third – the wrapper. Imagine you are programming in a specific framework like the KDE framework: you are using your normal programming language (here c++), you are using APIs which you are used to (qt/KDE APIs), and you are just used to the style and the way of how it works in this environment and how problems are addressed, etc.
Then it makes pretty much sense to provide oyu with a convenient set of APIs and your favoured language if I want you to implement a new general feautre.
This feature is now multimedia, or more specific, sound. You have to implement some kind of multimedia framework into your program – but this is most likely not written especially for your desktop environment with APIs in the way you are used to, but it is written with it’s own APIs, in it’s own way to address different problems, and probably even written in it’s own programming language.
That is exactly the situation we have with GStreamer and KDE!
So there is the need to program a wrapper which provide the KDE developers which something they are used to – and here we have it: Phonon. That task is done by it. Phonon provides the APIs the KDE people can easily integrate into their programs and can take usage of without learning to much new stuff. Keep it simple, developers, after all, are also just human beings.
So you need to have this wrapper, no matter if you want to tightly integrate GStreamer and nothing else into KDE or not.

Before we have a close look at this last sentence, we just talk about the fourth and last step of the architecture of sound inside Linux: the applications. These should integrate something to send their sound to as easy as possible.
If you are a KDE-used developer, you should use the APIs which are provided by KDE, so in future which are provided by Phonon. If you are a developer of professional audio software you should directly integrate ALSA support into your application, probably with an option to switch to OSS (although I do not think that a professional sound application would be satisfied with OSS).
Gnome developers will certainly implement GStreamer at the moment, but who knows what the future will come up with? NMM looks very, very promising, and even Helix seems to come up with some interesting stuff in the near future.

But back to Phonon – I already explained why we have to have Phonon, no matter if we integrate GStreamer as tight as possible or not. And now have a look at the history of KDE: KDE already thought once they have found the holy grail with aRts, and it was very painful to learn that it wasn’t. Additionally even today GStreamer is not supported by everyone, there are enough people who prefer Xine, aRts or Helix, and the distributors also have somehting to say. And do not forget that it is possible that something new step up suddenly and provide an astonishing new multimedia framework with functions every user have never dared to dream of.
Another thought is binary incompatibility: even if GStremaer will be the preferred solution for the next years, GStreamer will develop also. And there will probably a point where they brake the binary compatibility between two versions. With Phonon that wouldn’t be just a small correction (well, a new Phonon-backend probably), but nothing to worry about. The same is true for all other backends.
With these thoughts in background and the fact that there had to be a wrapper in all cases the developers decided to make this extra effort to be able to switch between the different solutions. It is also a nice way to keep some downwards compatibility with KDE 3 since there is also the ability to support aRts with Phonon.
It just keeps KDE flexbile and still gives the opportunity to support GStreamer as the main solution.

So, if you think GStreamer is the best ever: well, don’t complain, GStreamer can be fully integrated into KDE, and can be the default backend. You would like to add now that it makes sense to support only one backend since there are different funcitons in different backends, and you cannot support them all, or you cannot provide function x with backend y and the other way around to the application developers and therefore you can only provide limited functions of each backend and cannot use the full abilities of the backends. That’s right in theorie, but in practise Phonon and most multimedia frameworks are aiming at the same target: the normal user. And the normal user does only have limited needs. As mentioned above: if you want to program a high professional audio application, nothing stands in your way – but you should as close to the hardware as you could, therefore you shouldn’t use a multimedia framework but should work directly with ALSA.

So far, I hope that I cleared some questions and calmed down some stir. Spread the word/a link to this post, and show that Phonon is not as bad as several people think – the opposite will hopefully be the case :-)

Phonon Homepage officially online!

When you read the dot than you alredy know it: the Phonon homepage is officially online!
Matthias’s (aka Vir) has posted a short blog note about it, but the article on the dot itself has some more information.

Although the homepage haven’t changed such small comments like

I intended to get the website ready long ago, but I am exceedingly bad at writing the necessary text… I find it so much easier to write the code for Phonon.

are very nice to read since it means that he does a lot at the moment with providing the needed stuff for phonon. I’m really curious about these new technics. Phonon is one of the topics of KDE4 where I really have the feeling that there is steadily ongoing development.
And I’m really curious about the technique of setting different volume levels to different application groups (like turn down the volume of group “music player” when there is an event in group “VoIP”, or such).

If you are interested why there is the need for Phonon and why for example gstremaer is not just integrated, check this post which explains several questions. There is also a link to an interesting discussion on vir’s blog about this general topic.

Hopefully they will some video or screenshots soon after the LinuxTag to get an idea how it will look like and how well it will behave :)

Apache is leader in SSL services

Some weeks thago e community was shocked by the Web Server Survey, April 2006: Apache dropped by almost 6 % in favour of Microsoft’s IIS. Although it was exposed that this was mainly due to one large shift of the web hoster GoDaddy (who had to explain this step in several tech-media afterwards and even donated quite a lot of money to OpenSSH) everyone had uncomfortable thought’s and feelings about this – was this the end of the long apache era? Did that mean that IIS would finally catch up in the near future instead of suffering and dying somewhen?

Well, I still can’t predict the future, but I can read news – and the newest news (nice words) from netcraft, this time about who leads the rank of SSL Servers, looks very nice. Especially if you have a closer look at the graphics in detail: Microsoft’s share is shrinking for years now, while Apache increases it’s share from year to year almost with a constant growth. And this effect is not only once or temporary, but a steadily development everywhere in the world. In fact, the survey explains that now other countries like Germany and Japan now try to catch up with the USA, and that these favour Apache more than US companies. Nice development :)

Search and tags in KDE4

There are some interesting posts on the planet KDE dealing with searching in KDE 4 at the moment.

First there is a note of Roberto Cappuccio about the current state of kat. The text does not unveil new information about the current state but shows a quote of Linus Torvalds dealing with the fact that you should never start with something great, but that you should always start with something you can do adn reach. And that other developers will not jump on the train when it is still waiting at the station, they will jump on it when it got some speed and looks interesting enough, which means in that case that other developers will join your project first after you have already done somehting useful.
The post closes with the invitation to join the irc channel and join the project.
I’m not entirely sure what Roberto wants to point out with this quote; it sounds a little bit like the kat-project was started as a very big attempt which never fulfilled the expectations. That can be true in the way that there didn’t happen too much in the last weeks and months, but on the other hand the old kat version, 0.6.4, was kind of usable and was shipped with Mandriva by default afaik.
Probably this will stir up a little dust around this project, probably some other’s will have a look at the current state, hopefully we will see a new version soon :)

The next interesting post, or better, a short discussion about, is dealing with the topic of the future, and that it is written in tags. I couldn’t agree more since almost all new applications and programs I used were using tags and similar category systems to sort and overview data – hey, I even changed my blog system for that (and other) reason (s) :)
The writer of the post writes about some day-problems with KDE, in this case that digikam and kimdaba do not use the same tag database, which forced him to write his own script to transfer this data. In the comments you will soon find a comment about a “Database Abstraction Layer” which will probably used in KDE4.
While his explanations (which favour kexidb as the solution) are pretty interesting and make hope that we finally get something similar in KDE4, there feels something bad with it: it sounded too much like a “KDE-only” solution, and I don’t like that.
First, I personally want to have the ability to switch between the desktops as I want – although I do not really need it at the moment the option should be there – the gap between KDE and gnome would grow much bigger through something like that, and it would force users to choose one de once, and never really use the other one again – and that’s in the times of Portland, freedesktop.org and Tango!

Talking about gnome, there is a project already developing to tag everything everywhere – I do not really know how well it is integrated yet, but I think we will see a finally working and well integrated version in fall 2006 latest. The project is called leaftag and there is already a version working together with the taskbar search applet. That’s pretty close to what I would like to see in teh future on my desktop of my choice.
This version, by the way, is GObject based – it looks to me like that could be used in KDE 4 also as long as we get some kind of qt/KDE backend for it. I’m not a real programmer so I’m not sure about that, but one main aim about tagging should be to have it cross-desktop!

So, go to your preferred desktop solution, and tell them they should cooperate ;-)