--nextPart4827109.FG17Nu1WDa Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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=20 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 sugges= ted=20 git last time. Would you, or somebody else, be willing to help me get all t= he=20 Phonon history imported into a git tree? But I think that svn will also do fine if Phonon doesn't get released with= =20 both Qt and KDE anymore. Then I'd create a separate Phonon module where=20 libphonon and all backends that are currently in svn would move to. Or shou= ld=20 there be two modules: 1. without KDE deps, 2. with KDE deps? The separation= =20 could be necessary since kdelibs depends on libphonon... =2D-=20 ________________________________________________________ Matthias Kretz (Germany) <>< http://Vir.homelinux.org/ MatthiasKretz@gmx.net, kretz@kde.org, Matthias.Kretz@urz.uni-heidelberg.de --nextPart4827109.FG17Nu1WDa Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBIH2zWyg4WnCj6OIoRAkftAJ93GxcQ5RLMv1XiyXEcr2mx48n5JACfVaL+ AZ9yEJP/sPdc39Z3RAjGluQ= =lcaG -----END PGP SIGNATURE----- --nextPart4827109.FG17Nu1WDa--