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

List:       kde-multimedia
Subject:    Re: KDE4 MM,
From:       Scott Wheeler <wheeler () kde ! org>
Date:       2004-09-06 22:35:07
Message-ID: 200409070035.07806.wheeler () kde ! org
[Download RAW message or body]

On Monday 06 September 2004 23:40, Aaron J. Seigo wrote:
> 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. 

Well, actually I generally agree with you here and have tried to say so.  :-)

The initial summary again wasn't representative of my personal opinions, but 
an attempt to convey the more general opinions of the meetings.  Me mixing in 
my personal biases wouldn't have been very appropriate there.

We will have a default, and I would like to make that default a recommended 
(though not strictly required) part of our "platform".  I don't think this 
contradicts having the backends as being plugable, but more fits in line with 
what I said (during the conference on this list) about not having it 
configurable in the normal UI.

This would give us something to be able to say to third party (or internal) 
developers that "at least this will be available to you and we think it 
doesn't suck; other stuff might be too, but that's up to you."

But architecturally I don't think this has a big influence on the current 
development; it's more about how we present that development in the UI and 
the recommendations we make as a team.  While there was a general concensus 
(at aKademy) that the stuff currently going into kdelibs is sane, there was 
not a concensus on how "strong" our default should be and what sort of 
recommendations we should make to internal or external developers that need 
something beyond what's provided there.  I consider that an open question.

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