[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-multimedia
Subject:    Re: aRts vs JACK
From:       Neil Stevens <neil () qualityassistant ! com>
Date:       2003-02-24 15:56:27
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday February 24, 2003 07:15, Stefan Westerfeld wrote:
>    Hi!
>
> On Mon, Feb 24, 2003 at 06:29:39AM -0800, Neil Stevens wrote:
> > On Monday February 24, 2003 05:17, Stefan Westerfeld wrote:
> > > Adding CSL support to KDE right now seems to me the right thing to
> > > do. It does not disturb people using aRts (because things will
> > > continue to function exactly as they do now), but it helps people
> > > not using aRts. And doesn't cost much to do it.
> >
> > That's fine, add CSL as an add-on.  But as long as CSL is glib-tied,
> > it's not the answer to KDE's needs.
>
> There is still some confusion, I think.
>
> * CSL = common sound layer
>
> Is a simple plain C API. You give it an audio stream. It plays it. You
> ask it for an audio stream. It gives it to you. It does not have _any_
> dependancies.
>
> * BSE/SFK = bedevilled sound engine / synthesis fusion kit
>
> Is an aRts-like synthesis and effects thing using glib, currently
> exclusively used in BEAST. I do not recommend adding it to KDE at this
> point in time. If MCOP/SFI can be merged at some point in time remains
> to be seen. This however would most certainly mean a glib dependancy for
> the merged result.
>
> If this is inacceptable for aRts for some reason (it may for whatever
> reason not be my right to decide what is right for aRts and what not,
> even although I have written a lot of code in aRts), then aRts will have
> to remain without glib dependancy, and presumably without sane C
> language binding.
>
> Strategically however deciding against glib for aRts in the future this
> means that if you're a C coder (and there are a lot of these out there),
> aRts will not be for you, which means loosing potential
> contributors/users.

Well, I'm already seeing complaints  about just a glib *dependency*, but 
that's not what I mean.  I'll try to be more clear:  KDE apps shoudln't 
have to use a glib API, and KDE developers shoudln't have to use glib to 
write new extensions to the KDE-chosen media system.

> If you look at Arts::Thread, Arts::Dispatcher, arts/gsl/gslglib* you
> will see that aRts is duplicating quite some glib functionality even
> today. At some point however, using glib, or alternatively, using Qt
> might be cheaper than duplicating everything.
>
> Currently I however refuse to consider depending aRts on a GUI toolkit,
> whereas glib would only be a moderately sized C portability library. In
> fact, I would even think that depending Qt on glib would be a very wise
> decision interoperability wise, because it would open a much easier path
> towards in-process coexistence of GNOME and KDE code snippets.

In theory, glib is not a GUI toolkit, no. But in practice, glib is a 
foundation of the GNOME system, and is not used in KDE.  This puts KDE 
developers at a severe disadvantage if the KDE media system makes you use 
it.

But maybe I am confused.  I hope you'll set me straight.  Coudl you put up 
a webpage explaining just what CSL is?  All I can find on the aRts page 
are announcements of CSL, and a few slides saying GNOME should use aRts. 
:-)
- -- 
Neil Stevens - neil@qualityassistant.com
"Distinctions by race are so evil, so arbitrary and insidious that a
state bound to defend the equal protection of the laws must not allow
them in any public sphere." -- Thurgood Marshall
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+WkCrf7mnligQOmERAvr6AJkBDP9PUZ5uwH9Vc1qf/poMWCg2qgCghQAo
wnKiS2KESlKJyFYDz1lPzVE=
=1y7R
-----END PGP SIGNATURE-----

_______________________________________________
kde-multimedia mailing list
kde-multimedia@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-multimedia
[prev in list] [next in list] [prev in thread] [next in thread]