In this week's KDE Commit-Digest: KViewShell gets support for PostScript files. Work begins on Akonadi (the new KDE PIM data storage backend) and amaroK 2.0, with further optimisations to the stable amaroK version. kttsd (the kde-accessibility text-to-speech system) is ported to Phonon. KDELibs is now fully ported to D-BUS. Aesthetic improvements to KSysGuard.
Dot Categories:
Comments
Why are we reinventing the wheel yet again?
KViewShell is a mature application -- something that takes more than just a Summer to accomplish.
I can see possible advantages to adding PS and PDF viewing to KViewShell, but why start over?
we will have TWO "not so universal" viewers in KDE4, or 4 if you count kfax and kchm? I'm not being negative, just trying to understand when "application cleanup" idea went down the toilet.
No, it just means that nothing is decided yet....
Do the Phonon refactorings mean that it will be able to manipulate multiple backends at once?
Why would you want that?
To allow crossfading or other kinds of simultaneous playback of different media (which can be handled by different backends)
I still don't see the point in using multiple backends?
and simultaneous playback is already possible if you are using a decent sound card, or with alsa's dmix.
I mean this: http://bugs.kde.org/show_bug.cgi?id=127308
Ah that one :)
But there are some problems with that:
The outpunt from the backends won't be mixed, so if phonon directs different streams to different backends simultaniously, they will collide with each other (unless you have a sound card that does the mixing for you), and backends will complain that the audio device is not ready.
And something else: lets say you have a playlist in amaroK containing mp3, ogg and wmv files, and for each file format you have configured phonon to use a different backend.
Playing that list would mean that phonon should switch backends every time another audio format is loaded in amaroK.
That would create a lot of overhead on the system, causing large gaps between the songs..
> they will collide with each other (unless you have a sound card that does the mixing for you)
Even if they all output to ALSA? Doesn't dmix solve that for everybody? (except the OSS apps)
> That would create a lot of overhead on the system, causing large gaps between the songs..
This is why I was asking. If Phonon is now meant to allow apps to queue tracks for playback, then a specific engine can be preloaded when it's track is nearing, so that it's already available when needed, and no gap is caused. (I assume)
Right now I use aRts for general stuff in /dev/dsp, and I configured Xine to ouput /dev/dsp1 to get sound in my usb headphones (which I use to play music and movies without anoying my flatmates).
Strange, but KDE is not on the D-BUS users list.
So? That page is a Wiki, you can fix it.
Technically, we weren't a D-BUS user until a few hours ago.
Are you sure that's technically correct? I thought KDE was a (optional) D-BUS user since KDE 3.4 (or was it 3.3?). Using D-BUS for it's HAL support, in handling mounting of media and such. More or less equaling Gnomes usage of D-BUS.