--===============1669167722==
Content-Type: multipart/signed; boundary="nextPart1241004.BlUuElJUQ1";
	protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart1241004.BlUuElJUQ1
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Monday 06 September 2004 23:40, Aaron J. Seigo wrote:
> From a usability standpoint, having the user have to configure the sound
> system is a nightmare.

I agree.

> From the perspective of an application developer, a simplified API is a
> must.

I agree.

> e.g. KPresenter should allow recording a=20
> sound track for slides, or KWord should allow audio notations, or simple
> games should have a simple way to play sounds.

That's my objectives that I want to solve with the kdemm API.

> [...] need access to a full-featured multimedia API. [...]
> But there should be ONE and=20
> only ONE such official API. Why? Because this will concentrate testing (a=
nd
> therefore quality) of the chosen backend, it will create a shared body of
> knowledge that will be transferable between KDE MM apps and it will allow
> authoritative "KDE MM Development Documentation" to be written that 3rd
> party developers really do need.

Yes, you have a point here. But I wouldn't like the idea of a "official API=
",=20
at least not at this point. IMHO we should start to discuss this at the=20
earliest in 6 months from now.
What I would currently would be able to live with is a recomendation for a=
=20
full-featured API. But not something like official or unofficial. Especiall=
y=20
since the usage of mm frameworks are not mutually exclusive. Like you could=
=20
use one MM app using gst and one using nmm and one doing it all by itself a=
nd=20
then connect them in jack.
I believe the developer of the app should decide by looking at the features=
=20
and the available APIs (and bindings for the APIs) which one he wants to us=
e.

Tackling the point of overconfigurability. Yes I admit I want to have it al=
l=20
configurable. But I also don't want to put an extra burden on the average=20
user. So what I would think of is the following:
=2D continue the kdemm API
=2D create reasonable defaults and if really needed create a few configurat=
ion=20
options for the user (hopefully we don't need any)
=2D Create an app for full access to the whole power of the kdemm API and=20
underlying frameworks. This would serve the geeks with the power they want.=
=20
The reason I want to work on KDE MM is to have KDE not in my way when worki=
ng=20
with MM on Linux but rather to integrate as smoothly as possible.

=2D-=20
C'ya
        Matthias
________________________________________________________
Matthias Kretz (Germany)                          <><
http://Vir.homeip.net/
MatthiasKretz@gmx.net, kretz@kde.org,
Matthias.Kretz@urz.uni-heidelberg.de

--nextPart1241004.BlUuElJUQ1
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBBPY4Myg4WnCj6OIoRAnULAKDqO1TO9EICjRLinFBlZn4o2A79iwCcDi7a
nAO9qiIJj3SFFuNnYlMP30Q=
=ZFk6
-----END PGP SIGNATURE-----

--nextPart1241004.BlUuElJUQ1--

--===============1669167722==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
kde-multimedia mailing list
kde-multimedia@kde.org
https://mail.kde.org/mailman/listinfo/kde-multimedia

--===============1669167722==--