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

List:       kde-multimedia
Subject:    phonon 5 backends, interfaces and their compatibility
From:       Harald Sitter <sitter () kde ! org>
Date:       2013-05-27 14:26:03
Message-ID: CAEc+18HF__pQU719HUMx9G4Y2eXpAFko37u-2KYkmw7CR+BzZQ () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


in my attempt to slay all macros in phonon's source I have come to a halt
with a very elemental question that I think we should agree on as a
community.

right now (in theory) you can build phonon-vlc 0.1 against phonon 4.6
because former retains old interface defintions and constantly everywhere
tries to use old interfaces whenever casting to the present interface is
not working.

to illustrate this quickly:

class iInterface1 {
void play() = 0;
}

class iInterface2 : public iInterface1 {
void pause() = 0;
}

if a backend does not implement 2 a qobject_cast will fail, so phonon4 then
tries to cast to 1.

this allows backends to not implement new functions immediately but remain
buildable against a new phonon.

I personally believe this to be a bad idea as it makes it more confusing
what you can expect from a version of phonon and in its current
implementation even causes runtime overhead due to many casts. at the same
time running against an old backend will render phonon not working (though
I suppose we can detect that and display a warning), so this is also not
making my heart smile.

also in practice this did not work out as intended as numerous internal
cmake changes made old backends not build with a new phonon so it's
effectively useless right now

thoughts?
should we keep trying to retain this compatibility feature for backends or
drop it?

HS

[Attachment #5 (text/html)]

<div dir="ltr">in my attempt to slay all macros in phonon&#39;s source I have come to a halt with a very \
elemental question that I think we should agree on as a community.<div><br></div><div style>right now (in \
theory) you can build phonon-vlc 0.1 against phonon 4.6 because former retains old interface defintions \
and constantly everywhere tries to use old interfaces whenever casting to the present interface is not \
working.</div>

<div style><br></div><div style>to illustrate this quickly:</div><div style><br></div><div style>class \
iInterface1 {</div><div style>void play() = 0;</div><div style>}</div><div style><br></div><div \
style>class iInterface2 : public iInterface1 {</div>

<div style>void pause() = 0;</div><div style>}</div><div style><br></div><div style>if a backend does not \
implement 2 a qobject_cast will fail, so phonon4 then tries to cast to 1.</div><div style><br></div><div \
style>this allows backends to not implement new functions immediately but remain buildable against a new \
phonon.</div>

<div style><br></div><div style>I personally believe this to be a bad idea as it makes it more confusing \
what you can expect from a version of phonon and in its current implementation even causes runtime \
overhead due to many casts. at the same time running against an old backend will render phonon not \
working (though I suppose we can detect that and display a warning), so this is also not making my heart \
smile.</div>

<div style><br></div><div style>also in practice this did not work out as intended as numerous internal \
cmake changes made old backends not build with a new phonon so it&#39;s effectively useless right \
now</div><div style>

<br></div><div style>thoughts?</div><div style>should we keep trying to retain this compatibility feature \
for backends or drop it?</div><div style><br></div><div style>HS</div></div>



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