KDE4 MM, a view from usability and general applicaiton development

[Matthias Kretz]

On Tuesday 07 September 2004 01:40, Charles Samuels wrote:
> I believe that the advantages of this framework abstraction are outweighed
> by the fact that we'll still be stuck with its problems, basically until we
> can have BIC again.  With a single API, we can make any changes we want,
> including supporting gstreamer or nmm codecs in the future (once again, the
> way xine does to arts now).

With "a single API" you mean using e.g. only the API provided by NMM and 
nothing on top of it?

> Right, that's the primary reason I think basically the reason we shouldn't
> use it.  It's against the whole KDE/Qt API style.

What is against the "style"? That our kdemm API is not complete?

> > I've been working with the assumption that application developers would
> > know what they needed generally speaking and that those that need the
> > additional stuff wouldn't use the simple API.  You seem to disagree here.
> > I'm not sure that we can't work out something in the present API to
> > compromise on this issue.  What do you specifically see as missing?
>
> I'm not sure that's possible, as we cannot predict the future.  We also
> cannot add features to the API all the time as we need it (without BIC),
> and allowing somehow an interface into the underlying component, as I see
> it, would be an extraordinary ugly bit in the API.  And additionally each
> program would need to have to make independent interfaces for all the
> backends (at best), and at worst, only one, and then the abstraction
> wouldn't really be an abstraction, just a weak frontend that results in a
> lot of typecasting.

I'm not sure we have the same objective for a KDE MM API. What should a KDE MM 
API do in your opinion (I still have not understood if you want to have a KDE 
API for MM or not)?

> > For my needs the API 
> > in kdelibs is plenty.
>
> Well, optimally yes, and you make a point, but again... you cannot predict
> the future.

Why would he need to? He wants to have simple mm playback now, no more. So for 
now the kdemm API is enough. This decision doesn't stop him from using 
something else later.

> Right now, immediately, it does appear that Noatun is the only app in cvs.
> But I do imagine KDE getting more applications in the future, like, maybe a
> Garage Band tool like Aaron said.  Obviously I'm not saying that I'm going
> to write it, I'm saying these things may happen, and we should make the API
> correct for that situation.

So now you want to have a KDE API that does it all?

Sorry, but I have not been able to see what you want to have for KDE 4. A lot 
of my arguments with you had been guesswork at what you want and what you 
don't want (or rather think is good or isn't). I really don't want to force 
my ideas on KDE, I want to have the best MM solution for KDE 4 that we can 
get/create. And I believe you have something to say there as well, I'm just 
unable to understand what you think we should do.

-- 
C'ya
        Matthias
________________________________________________________
Matthias Kretz (Germany)                          <><
http://Vir.homeip.net/
MatthiasKretz at gmx.net, kretz at kde.org,
Matthias.Kretz at urz.uni-heidelberg.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-multimedia/attachments/20040907/f5262289/attachment.sig>
-------------- next part --------------
_______________________________________________
kde-multimedia mailing list
kde-multimedia at kde.org
https://mail.kde.org/mailman/listinfo/kde-multimedia