Sorry, the subject title may be a little provocative. I must apologize if it looks like I'm only focusing on the negative aspects.

I'm a happy user of KDE since 2005. I slowly learned how to appreciate this desktop environment, its consistency and the quality of some apps like Amarok, Digikam, K3b or may other.
I try co contribute the best as I can by raising bugs, helping on forums.

That's why I felt implicated in KDE4 move. There were lots of promises in the introductions of the new "pillars":

• Plasma
• Decibel
• Phonon
• Solid
• Nepomuk
• Akonadi
• ...

Now I say that I'm a little frustrated by KDE and the KDE software ? I'll try to explain that.

KDE SC 4 is a matter of promises: KDE is a cutting edge desktop, using innovative technology and concepts. I like that.
To me, the drawback is that in the beginning it delivers incomplete and buggy software based on incomplete and buggy technologies. Then foundations get more stable, resulting in software that gets better and better.
With KDE SC 4, apps were starting from a low level and improvements came slowly (to me).

Well, now we are under KDE SC 4.5, we reached a mature KDE SC 4 series.
And even looking behind at all the amount of work that has been done to implement these new technologies in KDE, I still expect more:

• Nepomuk is still not there and about KDE PIM and move to Akonadi, I fear that there will be lots of regression and that we will have to wait for some time before having something usable and reliable.
• Solid has also some work on the table: when will we see an udev backend for Solid, to remove Hal dependency? The move has been done for Xorg.
• Phonon would gain in having its VLC backend, it seems to be on its way... (And Then I will be able to continue working on a video plasmoid, not working with current xine backend.)
• Decibel is dead, now the future of Kopete seems to be on Telepathy. Looks promising, but not for today.

Why I'm I frustrated ? To me KDE SC 4 has an underused potential. And I don't want to wait for KDE SC 5 to enjoy it...
It is just that I felt that these new frameworks would really help and improve software development, but it looks like KDE is focusing too much efforts on KWin bling effects, with the side effects it can produce (see Open-Source GPU Drivers Causing Headaches In KDE 4.5: http://www.phoronix.com/scan.php?page=news_item&px=ODU3MA). Composite was working under 4.4. Disabled in 4.5. Only a side effect, I can live with that and I know it will be fixed soon.

Again, I don't want this topic to hide all the things I like in KDE. Just wanted to share my expectations.

PS: I'm also frustrated by Amarok ergonomics but it is another story ...

wazyk wrote:Well, now we are under KDE SC 4.5, we reached a mature KDE SC 4 series.
And even looking behind at all the amount of work that has been done to implement these new technologies in KDE, I still expect more:

We all do, which is why nobody has stopped working on these things but continues to put quite some efforts into making all those pillars work as intended.

wazyk wrote:Nepomuk is still not there and about KDE PIM and move to Akonadi, I fear that there will be lots of regression and that we will have to wait for some time before having something usable and reliable.

The Kontact suite has an extensive set of features so it is almost impossible to test all possible workflows.
However, the decision to not release as part of the KDE SC 4.5 as long as necessary is exactly addressing this concern. There will be a new beta on each of KDE's 4.5.x releases until the suite works for all workflows deployed by people participating in the testing.

wazyk wrote:Solid has also some work on the table: when will we see an udev backend for Solid, to remove Hal dependency?

This is ongoing work and the HAL backend is continuing to work until this is finished.
It is actually good to see that KDE's choice to provide an API with changable backends was dead on. Those people who ridiculed Solid as an unnecessary abstraction layer over HAL are hopefully eating their hats now

wazyk wrote:The move has been done for Xorg.

My uneducated guess would be that Xorg is only using a tiny fraction of the HAL interface compared to Solid.
If that's true it was most likely a lot less effort to port than creating a new Solid backend which reliably delivers the same feature set as the current one.

wazyk wrote:And I don't want to wait for KDE SC 5 to enjoy it...

You won't have to. Every feature release is getting us closer, nobody is leaning back and waiting for the transition to version 5 to happen.

wazyk wrote:It is just that I felt that these new frameworks would really help and improve software development, but it looks like KDE is focusing too much efforts on KWin bling effects, with the side effects it can produce

I find it hard to believe that there are so many more people working on KWin these days. Usually there are only a handful or so of developers working on effects. Compared to other teams like KDE PIM, Plasma, KDE EDU, KDE Games, KOffice and so on basically almost no one.

Can hardly call that "focusing too much".

Cheers,
_

Solid has also some work on the table: when will we see an udev backend for Solid, to remove Hal dependency? The move has been done for Xorg.

The real problem is that until very recently the various other u* stacks ( upower, udisks, etc which are also needed ) would not commit to API compatibility in any form, and broke it several times, breaking the Solid backends for them that were in development. As a result, their development was abandoned, it was simply not possible to continue developing them at that time.

Also, Solid needed some refactoring in the backend handling code to allow for multiple backends to be active at one time. As far as I know, this refactoring has now been completed.

With the recent release of QT 4.7 I discovered that Phonon will continue existing in QT but no more efforts will be put in it.
Decision has been taken to push their own QtMobility Multimedia Framework.

Announce here: http://labs.qt.nokia.com/2009/09/03/multimedia/
Explanations here: http://labs.qt.nokia.com/2009/09/09/multimedia-in-qt-whats-the-story/

This is sad but it seemed that many developers were frustrated by the limitation of the APIs offered by Phonon.

Now, what will be the impacts on KDE ?
After aRts, no chance for KDE with audio ...

wazyk wrote:With the recent release of QT 4.7 I discovered that Phonon will continue existing in QT but no more efforts will be put in it.
Decision has been taken to push their own QtMobility Multimedia Framework.

Anything in the announcement that would hint at that?

wazyk wrote:Announce here: http://labs.qt.nokia.com/2009/09/03/multimedia/
Explanations here: http://labs.qt.nokia.com/2009/09/09/multimedia-in-qt-whats-the-story/

Anything more recent?

These seem to be the two blogs of the Qt Mobility group which decided unilaterlly to create their own stuff without checking with the main office or desktop team.

wazyk wrote:This is sad but it seemed that many developers were frustrated by the limitation of the APIs offered by Phonon.

This is what they claimed to push their own implementation, but shortly later their own architecture already failed and they had to create an incompatible second version to cope with the limitations of their first one.

wazyk wrote:Now, what will be the impacts on KDE ?
After aRts, no chance for KDE with audio ...

It is unlikely that there will be any negative impact on KDE.

Applications which use Phonon for the multimedia needs will be able to keep using it. Phonon is continuously improved and extended so it might become even more widely used in the future.

Applications with needs beyond the scope of Phonon (e.g. video editing) are most likely using GStreamer right now. If they whill change to use multimedia API from Qt mobility is to be seen, but probably not likely if their current framework works.

Since you mentioned aRts, one important thing to remember about Phonon is that it is not an implementation of a multimedia framework, but rather a programming interface for dealing with audio and video data in a simple way without dealing with a specific manipulation framework in particular.

Like working with files on your harddisk independent of which file system you have formatted the parition with, e.g. applications don't care whether /home is ext3, Reiser or XFS.

Cheers,
_

anda_skoa wrote:Anything in the announcement that would hint at that?

My mistake: reading about QT 4.7 release on some French blog I discovered QtMultimedia and how it was planned to be included in QT 4.7.
But it seems that scope had changed to deliver it later as a module, if my understanding is right.

anda_skoa wrote:Anything more recent?

No... sorry. Articles seemed like a very official new direction to me. I wasn't aware of that before.

anda_skoa wrote:It is unlikely that there will be any negative impact on KDE.

I don't see negative impact on KDE neither. But it looks like the QT move can be interesting for KDE. If something not-so-different from Phonon but better arrives ...
I find it too bad that project like Kamoso cannot rely on Phonon but on libvlc. Not sure that Phonon VLC backend will allow webcam access in the end (i'm not aware of all Phonon APIs capabilities and restrictions regarding the offered backends).
Similarly, Plasma Media Center had to bypassing Phonon for some playing queue limitation.
Kaffeine is still using xine-lib instead of Phonon.

I like this design of a top API with pluggable backends. Phonon works great for me and hopefully there are many projects that use it, like Amarok.
But is there no hope for Phonon to evolve and offer a wider range of possibilities, like (some) QT dev guys are saying? Or is it a deep problem of conception that leads to the need for a new framework?

And back to Solid framework (discussed in some posts below), work is still going on to have a Solid transition to udisk and upower (http://lamarque-lvs.blogspot.com/2010/09/e-sata-and-solid.html). This is good news.

Some fresh news about solid backend migration: http://www.afiestas.org/one-step-closer-towards-a-kde-hal-free/