<div dir="ltr"><br><div class="gmail_extra">Thanks for elaborating.<br></div><div class="gmail_extra"><br><div class="gmail_quote">2013/12/12 Harald Sitter <span dir="ltr"><<a href="mailto:sitter.harald@gmail.com" target="_blank">sitter.harald@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Wed, Dec 11, 2013 at 8:59 PM, Casian Andrei <<a href="mailto:skeletk13@gmail.com">skeletk13@gmail.com</a>> wrote:<br>
<br>
> Proposed functionality for Phonon5:<br>
> - each device type with it's own class (derived from DeviceDescription)<br>
<br>
</div>sign<br>
<div class="im"><br>
> - only the backend gives devices<br>
<br>
</div>pretty much sign (understand: backend now incorporates functionality<br>
of GlobalConfig)<br>
<div class="im"><br>
> - no more platform plugin<br>
<br>
</div>agreed for devices; actual removal is blocked by other stuff we need a<br>
solution for (KIO streams)<br></blockquote><div>Perhaps we could change from "platform plugin" to "streaming plugin" and create a thing called phonon-kio.<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im"><br>
> - no more generic objectDescriptionIndexes/Properties()<br>
> - methods like QList<AudioOutputDevice> audioOutputDevices() for passing<br>
<br>
</div>Does anyone have a problem with this? because from a ABI POV there is<br>
actual use to the generic interfaces. In that, adding another type<br>
does not mandate interface changes. and since they were actually<br>
implementing an int command pattern they still had somewhat viable<br>
typing.<br>
<br>
Imagine if you will the following functions on the backendinterface,<br>
one is generic the other not:<br>
<br>
virtual QList<AbstractDevice> allThemDevicesPlease(enum Type) = 0;<br>
///<br>
virtual QList<AudioDevice> allThemAudioDevicesPlease() = 0;<br>
<br>
Say we need to introduce a TeleporterDevice now. With the generic<br>
function the backend interface does not need to change. We only need<br>
to add a new enum entry and implement the case handling in the<br>
backend.<br>
With the specific function approach we now need a completely new<br>
function for TeleporterDevices and since all interfaces are a virtual<br>
non-leaf class we'd break vtable compatibility [1]. So we would<br>
actually have to introduce<br>
<br>
class BackendInterface2 : public BackendInterface {<br>
public: virtual QList<TeleporterDevice> allThemTelePorterDevicesPlease() = 0;<br>
};<br>
<br>
I am reasonable certain binary compatibility was the primary<br>
motivation behind all int-command functions in phonon4<br>
(BackendInterface, AddonInterface). Which is an understandable notion<br>
when one has seen how much work it is to actually create a new<br>
interface in phonon4 (also see thread 'phonon 5 backends, interfaces<br>
and their compatibility'). What with it's foward, backward, sideways,<br>
multi-dimensional compatibility.<br>
<br>
So, if we all understand the requirement of having to introduce a new<br>
Class+Interface version and are ok with that then I am all for more<br>
specific functions.<br></blockquote><div>We can keep a generic method for being safe in the unlikely event of TeleporterDevice, like<br></div><div>QList<ObjectDescription*> objectDescriptions(Type)<br></div><div>and maybe some<br>
</div><div>inline QList<TeleporterDevice>teleporterDevices()<br>{<br></div><div> QList<TeleporterDevice> r;<br></div><div> foreach(td in objectDescriptions(TeleporterType)<br></div><div>  r << *td;<br></div>
<div> return r;<br></div><div>}<br></div><div>Will this work in case the teleporter device is invented?<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> Pulse stuff should be handled by the backend, I guess.<br>
</div>^<br>
Code for pulsesupport abilities would still need to be in libphonon,<br>
otherwise we run into duplication. And I think we still need to figure<br>
out what exactly we expect from pulse and how it ties into the rest of<br>
the world before making decisions about where pulse should be handled.<br></blockquote><div>I have no clue on this now.<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
[1] <a href="http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B" target="_blank">http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B</a><br>
<br>
HS<br>
_______________________________________________<br>
kde-multimedia mailing list<br>
<a href="mailto:kde-multimedia@kde.org">kde-multimedia@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/kde-multimedia" target="_blank">https://mail.kde.org/mailman/listinfo/kde-multimedia</a><br>
</blockquote></div><br></div></div>