Phonon backends, was Re: Goals? How are we doing?

[Matthias Kretz]

On Monday 05 May 2008, Thiago Macieira wrote:
> Matthias Kretz wrote:
> >On Monday 05 May 2008, Sebastian Kuegler wrote:
> >> On Monday 05 May 2008 16:46:48 Allen Winter wrote:
> >> > Here's a list of our goals for 4.1.
> >> > Please provide a status update, if you can:
> >> >
> >> > - GStreamer, Quicktime, DirectShow9 Phonon backends
> >>
> >> This is something seems not solved yet. From re-reading related
> >> discussions, I gather that the release strategy of Phonon looks like
> >> Matthias describes:
> >>
> >> On Saturday 29 March 2008 11:36:41 Matthias Kretz wrote:
> >> > On releases:
> >> > - libphonon gets released with KDE and Qt. KDE 4.0 shipped libphonon
> >> > 4.0, Qt 4.4 will ship libphonon 4.1, KDE 4.1 will ship libphonon 4.2
> >> > - phonon-xine will only get released with KDE
> >> > - phonon-gstreamer get's released with Qt, but I will look into
> >> > whether we want to release phonon-gstreamer with KDE 4.1, too
> >> > - phonon-qt/ds will only get released with Qt unless some
> >> > KDE-Windows/Mac developer wants to do something there
> >>
> >> Last signs on core-devel said that the phonon backends in kdereview
> >> required a newer Qt version than qt-copy at that point in time. I
> >> assume that as soon as 4.4 hits qt-copy that is solved (or maybe it
> >> even is already, status?). So those backends could then go with
> >> libphonon 4.2 into ...
> >>
> >> The question is wether we want to release the backends in kdebase or
> >> in extragear?
> >>
> >> The QuickTime7 backend won't build outside Qt, so we won't release it
> >> (and it probably doesn't make much sense to do so anyway). The
> >> question is how much sense it makes to have our own releases for those
> >> backends as well. It would be worth it when we want to add features
> >> and require them, and Qt cannot be updated in the meantime. Not sure
> >> about the DS9 backend.
> >>
> >> In any case, those backends have been in kdereview forever, which
> >> isn't good.
> >
> >I'd like to move the gstreamer backend out of kdereview and into either
> >kdemultimedia or kdebase for KDE 4.1.
>
> Do you intend to have a copy in KDE/kdeXXX or the mainline development?
>
> From the TT side of things, the mainline can be anywhere, as long as
> there's no freeze when TT developers are working on development.

It seems I'll need a copy since otherwise there'd be a freeze on the code 
until the release of 4.1.

> >After 4.1, I think phonon and its backends will have to release
> > independently of KDE.
> >
> >The GStreamer backend for 4.1 has an important difference to the one in
> > Qt4.4: It integrates correctly into the device preference settings -
> > just like the phonon xine backend does already.
> >
> >I don't want to move any of the other backends as I don't work on those
> > and can't test them. As I don't know of any KDE people working on them
> > or anybody interested in getting them into a KDE 4.1 release I see no
> > point in moving them to a KDE module. They just need some open
> > repository until Phonon has found its right place.
>
> I also wonder about the upcoming backends. By the end of the year, we'll
> hopefully also have:
>
>  - VLC
>  - MPlayer
>  - the Qt/Mac-Cocoa port one

Yes, so I really need a solution for the Phonon repository soon. You suggested 
git last time. Would you, or somebody else, be willing to help me get all the 
Phonon history imported into a git tree?
But I think that svn will also do fine if Phonon doesn't get released with 
both Qt and KDE anymore. Then I'd create a separate Phonon module where 
libphonon and all backends that are currently in svn would move to. Or should 
there be two modules: 1. without KDE deps, 2. with KDE deps? The separation 
could be necessary since kdelibs depends on libphonon...

-- 
________________________________________________________
Matthias Kretz (Germany)                            <><
http://Vir.homelinux.org/
MatthiasKretz at gmx.net, kretz at kde.org,
Matthias.Kretz at urz.uni-heidelberg.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080505/47375f53/attachment.sig>