Phonon design in general

[Håvard Wall]

> > -          VideoPlayer & AudioPlayer & SeekSlider & VolumeSlider : nice
> > things to have but it looks to me there are more like example code than
> > really core functionality. They have no interface to the backend.
> >
> >
> >
> > This code is all great value to phonon and I think we should not remove
> > it. It just makes more sense to have them in a separate “example”
> > directory. I’m pretty sure most people won’t use them.
>
> http://lxr.kde.org/ident?i=AudioPlayer
> http://lxr.kde.org/ident?i=SeekSlider
> VolumeSlider is only used in JuK at this point.
>
> > And if they want to use them,
> > they can still integrate them into their own app (like the
> > ObjectDescriptionModel for KCM).
>
> The model I agree to make 100% inline if possible and if it's safe to do
> that. Removing the Player and Slider classes I'm not very happy about.
>
> I just tested the savings of removing VideoPlayer and it's 7532 bytes.
> Removing only the Q_OBJECT macro saves only 36 bytes, removing all public
> slots (keeping Q_OBJECT) saves 28 bytes (this is very impressive!).
>
> If those 50kB really improve the situation on embedded (btw, how big are
> QtCore and QtGui? stripped on my machine they're 1.5MB and 7.6MB) we should
> consider a libphononutils or so. Another candidate for that lib would be
> EffectWidget.

From my point of view 50K is well worth some efforts. Your size measurements 
for QtCore and QtGui looks about right to me, they're big, and that's why we 
need the qfeature system to let the customer reduce the library size. I don't 
think it's fair to compare the size of phonon to the size of Qt. If you 
compare individual features within Qt you'll find that even the largest 
feature (graphics-view) is less than 300K.

I believe the idea of moving "utility" classes into a separate library might 
be a good idea, but we should probably create some use-cases for how a 
programmer will be using phonon to see what classes might be disposable in 
most cases. 

--
hw