KDE4 MM, a view from usability and general applicaiton development

[Aaron J. Seigo]

Hi...

I've been following the discussion with regard to KDE's future multimedia 
choices with interest, as it's an important decision for our favourite 
desktop and project. That and I'll end up having to use whatever is decided 
upon.

Unfortunately, I don't agree 100% with anyone so far. Here's my input and 
rational for said input:

From a usability standpoint, having the user have to configure the sound 
system is a nightmare. We have unending issues with this today due to aRts 
being so painfully exposed in KControl and so easily broken due to various 
issues from device file settings to sound card contention to poor latency. 
Having multiple backends that the user has to contend with is just asking for 
trouble and is, from the viewpoint of people actually having to use this 
stuff, not a good idea. Please do not let the concept of a "hard choice" 
prevent us from making a "good choice" and picking one backend. In this I 
agree with Charles.

From the perspective of an application developer, a simplified API is a must. 
Non-multimedia specialist apps (e.g. media players, mixers, media content 
creation, etc) do not usually have media-savvy developers working on them. 
However, it would be very nice to be able to play and record sound (and even 
video) as easy as we load icons today. A kpart will not do since this 
functionality should be callable from any part of the application in any way 
the programmer sees fit. e.g. KPresenter should allow recording a sound track 
for slides, or KWord should allow audio notations, or simple games should 
have a simple way to play sounds. 

To whit, I remember when kbattleship first came out an the number of bugs, 
many of them crashes, that were fixed due to dealing with sounds. A "true" 
multimedia API was simply more than was needed and more than the developers 
were prepared for, resulting in trivial and unecessary bugs.

Having a simplified API available also protects general developers from 
disruption should there be future sound back-end modifications. Think of the 
work that will have to happen in kdegames for KDE4 to move away from aRts. 
Think of how that work would've been saved had we had a simplified MM API for 
these people to use.

In this I agree with Scott and the others.

However, some media apps, especially the sort we are currently missing in KDE 
(think Garage Band =) need access to a full-featured multimedia API. This API 
should be available for use and a simplified API that is provided on top does 
nothing to get in the way of that full-featured API. I think it's almost 
mandatory that this lower-level API Not Suck(tm), but it's really up to the 
pain thresholds of the "serious" multimedia developers and the willingness of 
those writing the backends (GStreamer, NMM, MAS, etc) to serve the needs of 
their users (developers). But there should be ONE and only ONE such official 
API. Why? Because this will concentrate testing (and 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. So in this case I tend to side more with Charles et al again.

I know I've repeated some of what others have said in my usual long-winded 
way. So let me recap and complete the redundancy:

 Please provide a simple API for apps to hook into for basic media needs.
  This allows developers to use a future-proofed MM library that doesn't
  require one to become a MM expert.
 Please do not put extra pressure on users by mandating multiple backends.
  Usability will suffer with multiple back-ends.
  Resource requirements will be higher with multiple back-ends.
 Please allow KDE to be coherent for 3rd party developers
  A single "full featured" API in addition to the "MM for sissies" API.
  Allows proper documentation and knowledge sharing.
  Will provide more focus on the chosen backend, resulting
   in quicker improvements, assuming active development.

Ok, I'm done harassing you.

p.s. I have no idea why I'm using my shift key in this email. Totally out of 
character. See what posting about MM does to a person? ;-)

-- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43