Request for moving kdelibs/arts/knotify outside the arts directory
ralf.habacker at freenet.de
Wed Jun 1 13:39:47 BST 2005
Am Mittwoch, 1. Juni 2005 00:30 schrieb Matthias Kretz:
> I guess you are talking about KDE4 and not KDE 3.5?
I'm talking about KDE 3.x because the cygwin port I'm working uses
recent KDE 3.4. I need the requested changes, at least moving knotify,
disabling the arts stuff and setup initial KAudioplayer windows support to
complete the port and let it be compilable from svn.
> Anyway, the plan (my plan - and what we discussed on aKademy 04) is to have
a new Multimedia API for KDE4. So, yes, knotify will need to be moved out of
> the arts dir and all the remaining aRts code can be removed. All multimedia
> (audio/video) API should go into the new kdemm libs. If you are interested
> in helping let me know and we can coordinate our efforts.
> Would you be interested in implementing the multimedia API with native
Windows code (I guess you'd be using DirectX)?
I'm the maintainer of the kde on cygwin port and my work is to get the port
initial running out of the box, so that other developer may be attracted to
continue and finish this work. I fear I haven't enough knowledge and time to
implement the whole multimedia api. :-(
I have some requirements about the api (for example used by libkonq and kde
games) and are able to implement it mostly (we have an running audio playing
QSound implementation using the windows multimedia api based on the winmm
shared library, but this will probably only a subset of the required stuff.
BTW: I'm wondering why KDE does not use QSound like it uses many other QT
classes at least as option or enhance QSound to support more than one sound
system. This would be more straightforward adn require duplicate
> On Wednesday 01 June 2005 00:02, Ralf Habacker wrote:
> > Because this relates also with the KDE 4 plan to use KAudioplayer with
> > akode http://edu.kde.org/development/port2kde4.php, for my opinion is
would be nice to have knotify outside from the arts dir directly into
> I've never heard of this plan before...
> > Beside the basic movement of knotify, an additional topic is where to put
> > the native sound support.
> Into the backend implementation for kdemm.
> > Currently there are two different implementation, one in knotify using the
> > arts api and one in KAudioplayer using the dcop/mcop bridge.
> The dcop/mcop bridge was never used AFAIK. KAudioPlayer uses knotify.
.., which communicate with knotify over dcop, knotify uses mcop to communicate
with arts. I recognized under cygwin noticable latencies because unix domain
sockets are emulated with tcp sockets. For this reason I removed arts and
implemented an initial native support for windows in KAudioplayer, which is
used by Knotify.
Because the windows multimedia api only support wave files directly I had
implemented the usage of additional command line player like madplay for mp3,
ogg123 for ogg format and a self written player kwaveplay supporting wave
formats. This is very initial support, but it works for me additional for the
ported kde games too.
The general problem I have with the recent implementation is that for my
opinion Knotify should use KAudioplayer and not Kaudioplayer Knotify, because
knotify is a higher abstraction. It provides system nofitication services for
which KAudioplayer is one of the possible output channels. Does other share
the sight of view ?
More information about the kde-core-devel