On Wed, Dec 11, 2013 at 8:59 PM, Casian Andrei 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 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 allThemDevicesPlease(enum Type) = 0; /// virtual QList 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 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 _______________________________________________ kde-multimedia mailing list kde-multimedia@kde.org https://mail.kde.org/mailman/listinfo/kde-multimedia