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

List:       kde-multimedia
Subject:    Re: Phonon 4.2 and integration for Qt 4.5
From:       Matthias Kretz <kretz () kde ! org>
Date:       2008-06-11 5:50:38
Message-ID: 200806110750.44015.kretz () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Wednesday 11 June 2008, Michael Pyne wrote:
> On Tuesday 10 June 2008, Matthias Kretz wrote:
> > On Tuesday 10 June 2008, Thierry Bastian wrote:
> > > First, the change in AudioOutputInterface breaks source compat for
> > > apparently no really good reason. Adding the setOutputDevice with the
> > > parameter being an objectDescription doesn't really bring much over a
> > > int since the backend is in complete control of that int.
> >
> > That's true for all the devices listed by the backend. But starting with
> > Phonon 4.2 the platform plugin may list devices. And those the backend
> > knows nothing about. But through the properties of ObjectDescription it
> > gets all the info it needs. Currently this is not documented good enough.
> > And for frontend users it should stay hidden. But Backend developers need
> > those properties documented... I already implemented it (at least for
> > ALSA) for the GStreamer backend.
> >
> > And this is then probably the biggest feature for libphonon 4.2 since it
> > means that now Phonon-GStreamer integrates into KDE as good as
> > Phonon-Xine does.
> >
> > *snip*
> >
> > Note that binary and behaviour compatibility is kept. Only recompilation
> > of the backend against the new interface shows that a new function needs
> > to be implemented.
>
> I know that phonon isn't in kdelibs anymore... but would this break KDE
> software written when Phonon 4.1 was current?  i.e. would applications be
> able to compile against the new Phonon?

No, applications are not affected. Only backends.

> If so I have no objection (but then I don't see how it isn't source
> compatible either).

Phonon 4.2 adds a new pure virtual function for the backend AudioOutput. 
Through some Q_INTERFACE magic that doesn't break binary compatibility, but 
on recompilation it complains that it cannot instantiate an object of 
abstract type AudioOutput...

> But we shouldn't cause KDE programs that used to be 
> valid to fail to compile, even if it is actually binary compatible.  I
> absolutely hate when other libraries have done this to me in a minor rev.
>
> Besides, doesn't Trolltech have to maintain source compatibility for Qt?  I
> don't see how they could include a Phonon change that breaks source
> compatibility...

If Phonon were not to make the new virtual functions pure it becomes a lot 
harder for Backend developers to see where new functions need to be 
implemented for a new version of Phonon. If you have better suggestions how 
to handle this let me know.

-- 
________________________________________________________
Matthias Kretz (Germany)                            <><
http://Vir.homelinux.org/
MatthiasKretz@gmx.net, kretz@kde.org,
Matthias.Kretz@urz.uni-heidelberg.de

["signature.asc" (application/pgp-signature)]

_______________________________________________
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]