phonon5 and device management

[Harald Sitter]

On Wed, Dec 11, 2013 at 8:59 PM, Casian Andrei <skeletk13 at gmail.com> wrote:
> The old device management mechanisms from phonon4 look to be overly
> complicated for what phonon5 needs (things have changed from the times when
> phonon4 was developed).
>
> We need a more simplified design imo.
>
> Old functionality:
> - devices are generic objects (ObjectDescription)
> - device objects are passed around between the platform plugin and Phonon4
> and between the backend and Phonon4, so Phonon4 centralizes the available
> objects and gives them to the kcm, for example.

This is actually the most terrible thing. Phonon essentially is a
multimedia device manager and kind of got replaced by PulseAudio for
audio devices but not video so now we have this weird construct where
there's like 5k lines of code not being used ... ever ... unless you
have a webcam ... but since we don't have actual apps using that, it's
technically used, except not really.
And the fun thing is, right now on every platform but Linux we have
exactly one device which is a fake device representing the output
system (directsound, hal or whatever that stuff is called)....

> - generic objectDescriptionIndexes() in backend and platform plugin
> - generic objectDescriptionProperties() in backend and platform plugin
> - GlobalConfig was an important part of this

GlobalConfig was essentially the heart of it all. It was basically
compiling all possible devices of a type/category into one list
ordered by the device priority. So, GlobalConfig actually was the
application-side interface you'd use to list/change the device order.
Behind it would be
1) PulseAudio as primary device source
2) the PlaformPlugin as primary device source in case PA is not present
2-1) the Backend as supplementary device source in addition to the
PlatformPlugin or sole source in case the PlatformPlugins is not
present.

I can very much recommend reading that class for educational purposes
on what happens if you keep adding stuff without refactoring the
original :P

++++++++++++++++++++

> 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)

> - 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.

> 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.

[1] http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B

HS