Question about the interface classes

Matthias Kretz kretz at
Fri Jun 22 16:22:07 CEST 2007


On Friday 22 June 2007, Håvard Wall wrote:
> What's the reasoning behind the BACKEND_GET macros (and friends) in
> phonondefs_p.h?

- binary compatibility on the backend side
- less/no multiple inheritance for backend classes

> Wouldn't it be better to just add these functions as 
> virtual functions to the interface classes? They could have a trivial
> default implementation returning true (or whatever makes sense).

Virtual functions make it harder to keep BC.

> Benefits:
> - Easier to understand and write a backend (you don't have to search the
> phonon code to find out what slots to implement).

Use methodtest to get a list of all methods that you have not implemented. 
Look at kdelibs/phonon/tests/methods/* to see all the method and signal 
signatures. (Those signatures are extracted from libphonon automatically 
using the extractmethodcalls.rb script.)

> - Efficiency: it's faster to call a virtual function than to use
> QMetaObject::invokeMethod. (Important on embedded systems! And even if it
> should be "fast enough" on some devices, every extra CPU cycle consumes
> battery which is expensive on a cell phone).

The methods that get called more frequently are implemented using virtual 
For embedded I'd expect the backend to be compiled into libphonon anyway. So 
there you'd redefine the macros to call the backend functions directly 
instead of going through the meta object.

> - Library size: Gets rid of some slots which blows up the compiled code.
> (Lots of strings in tables generated in the moc-files, and strings in the
> source code when invoking the methods). (I'm very concerned about the
> library size for embedded systems. Currently the core phonon libraries are
> near 600kB stripped in release mode compiled for ARM. This is a lot if you
> only have 16MB of storage, or less...).

My libphonon has 342kB stripped (x86). But like I said, for embedded you'll 
want to compile the backend into libphonon and make direct calls...

BTW: On monday is the last day to make API changes. :-( From then on kdelibs 
is hard frozen. I'd like to have two things changed:
- the subtitle, audio-/video stream functions in MediaObject should work with 
ObjectDescription objects instead of QStrings
- the meta data should be a map string -> variant instead of string -> string

As I'm working on another part of kdelibs right now that needs a lot more love 
than Phonon at the moment any help there would be appreciated.

Matthias Kretz (Germany)                            <><
MatthiasKretz at, kretz at,
Matthias.Kretz at
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : 

More information about the Phonon-backends mailing list