phonon5 and device management

[Casian Andrei]

Thanks for elaborating.

2013/12/12 Harald Sitter <sitter.harald at gmail.com>

> On Wed, Dec 11, 2013 at 8:59 PM, Casian Andrei <skeletk13 at gmail.com>
> wrote:
>
> > Proposed functionality for Phonon5:
> > - each device type with it's own class (derived from DeviceDescription)
>
> sign
>
> > - only the backend gives devices
>
> pretty much sign (understand: backend now incorporates functionality
> of GlobalConfig)
>
> > - no more platform plugin
>
> agreed for devices; actual removal is blocked by other stuff we need a
> solution for (KIO streams)
>
Perhaps we could change from "platform plugin" to "streaming plugin" and
create a thing called phonon-kio.

>
> > - no more generic objectDescriptionIndexes/Properties()
> > - methods like QList<AudioOutputDevice> audioOutputDevices() for passing
>
> Does anyone have a problem with this? because from a ABI POV there is
> actual use to the generic interfaces. In that, adding another type
> does not mandate interface changes. and since they were actually
> implementing an int command pattern they still had somewhat viable
> typing.
>
> Imagine if you will the following functions on the backendinterface,
> one is generic the other not:
>
> virtual QList<AbstractDevice> allThemDevicesPlease(enum Type) = 0;
> ///
> virtual QList<AudioDevice> allThemAudioDevicesPlease() = 0;
>
> Say we need to introduce a TeleporterDevice now. With the generic
> function the backend interface does not need to change. We only need
> to add a new enum entry and implement the case handling in the
> backend.
> With the specific function approach we now need a completely new
> function for TeleporterDevices and since all interfaces are a virtual
> non-leaf class we'd break vtable compatibility [1]. So we would
> actually have to introduce
>
> class BackendInterface2 : public BackendInterface {
> public: virtual QList<TeleporterDevice> allThemTelePorterDevicesPlease() =
> 0;
> };
>
> I am reasonable certain binary compatibility was the primary
> motivation behind all int-command functions in phonon4
> (BackendInterface, AddonInterface). Which is an understandable notion
> when one has seen how much work it is to actually create a new
> interface in phonon4 (also see thread 'phonon 5 backends, interfaces
> and their compatibility'). What with it's foward, backward, sideways,
> multi-dimensional compatibility.
>
> So, if we all understand the requirement of having to introduce a new
> Class+Interface version and are ok with that then I am all for more
> specific functions.
>
We can keep a generic method for being safe in the unlikely event of
TeleporterDevice, like
QList<ObjectDescription*> objectDescriptions(Type)
and maybe some
inline QList<TeleporterDevice>teleporterDevices()
{
 QList<TeleporterDevice> r;
 foreach(td in objectDescriptions(TeleporterType)
  r << *td;
 return r;
}
Will this work in case the teleporter device is invented?

>
> > Pulse stuff should be handled by the backend, I guess.
> ^
> Code for pulsesupport abilities would still need to be in libphonon,
> otherwise we run into duplication. And I think we still need to figure
> out what exactly we expect from pulse and how it ties into the rest of
> the world before making decisions about where pulse should be handled.
>
I have no clue on this now.

>
> [1]
> http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B
>
> HS
> _______________________________________________
> kde-multimedia mailing list
> kde-multimedia at kde.org
> https://mail.kde.org/mailman/listinfo/kde-multimedia
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-multimedia/attachments/20131214/fa04a6d1/attachment.htm>
-------------- next part --------------
_______________________________________________
kde-multimedia mailing list
kde-multimedia at kde.org
https://mail.kde.org/mailman/listinfo/kde-multimedia