the right home for Phonon

[Matthias Kretz]

On Thursday 29 May 2008, David Faure wrote:
> On Friday 16 May 2008, Alex Merry wrote:
> > On Thursday 15 May 2008 20:17:38 Alexander Neundorf wrote:
> > > On Thursday 15 May 2008, Matthias Kretz wrote:
> > > > Open questions:
> > > > a) should kdelibs 4.1 contain libphonon or should it depend on an
> > > > external libphonon?
> > >
> > > I'd say that kdelibs should depend on libphonon from kdesupport. May
> > > bring more users for phonon.
> >
> > Either way, we have the same issue with possible clashes between the Qt-
> > release of libphonon and the KDE-release of libphonon, right?
> >
> > I think kdelibs just has to say "we need libphonon at least version x",
> > but not care if it came with Qt or was built separately.
> >
> > The issue is only if we want to depend on a version of libphonon that is
> > more recent than the version shipped with the Qt version we depend on.
>
> Yes. This seems to be the case right now, in fact.
> kdebase does not compile with qt-copy-trunk's phonon, it seems to require
> some more recent version of phonon (4.2, I'm told)
>
> [ 14%] Building CXX object
> runtime/phonon/kcm/CMakeFiles/kcm_phonon.dir/globalconfig.o
> /d/kde/src/trunk/kdebase/runtime/phonon/kcm/globalconfig.cpp: In member
> function 'QList<int>
> Phonon::GlobalConfig::audioOutputDeviceListFor(Phonon::Category,
> Phonon::GlobalConfig::HideAdvancedDevicesOverride) const':
> /d/kde/src/trunk/kdebase/runtime/phonon/kcm/globalconfig.cpp:137: error:
> 'class Phonon::PlatformPlugin' has no member named
> 'objectDescriptionIndexes'
>
> Is this intended?
> If yes, then we -really- need a configure check that checks that the right
> version of phonon was found (and that points to branches/phonon/4.2 --
> nobody can guess that if he's not told on irc...)

Yes, this new API in phonon 4.2 will make phonon-gstreamer integrate better. 
I'll look into the version check unless someone beats me to it.

And I'm still not fully happy with phonon trunk in kdesupport and the release 
branches in branches/phonon. Because many KDE developers will just install 
kdesupport and not test the code in branches/phonon which is going to be 
released. The only idea to improve that situation would be to again use a 
dedicated phonon module and use svn:externals to link either a release branch 
or trunk to kdesupport... but I don't know if an external really is an 
improvement.

-- 
________________________________________________________
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/20080529/3a37edaa/attachment.sig>