Request for moving kdelibs/arts/knotify outside the arts directory

[Ralf Habacker]

Am Mittwoch, 1. Juni 2005 00:30 schrieb Matthias Kretz:
> Hi,
> 
> 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 
implementations. 
 
> 
> 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 
kdelibs.
> 
> 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 ? 

Ralf