kpanelextension

[Lubos Lunak]

On Thursday 23 May 2002 20:06, Aaron J. Seigo wrote:
> Hi.
[snip]
>
> obviously, this breaks BC with anything using KPanelExtension. according to
> LXR only kicker and kwintv3 use it. kwintv3 is still in nonbeta, so should
> be a non issue. the real question is whether or not it is ok to break BC on

 I think we shouldn't break BC, no matter how much used the class is used.

> this one class which is used currently only by kicker (which makes me
> wonder why it was put in kdeui in the first place?)

 Good question.

>
> without the change, i don't know if i'll be able to reliably have the
> extensions show size changes on the fly. the other alternative is to
> attempt to get a rather ugly little hack that i tried to work (though it
> seems there are easy ways around it, so it wouldn't be a great solution) or
> to leave the extensions as they are (which is broken IMHO). in other words:
> w/out this change i don't think the extensions can be configured from the
> kcm properly.
>
> attached is the patch again KPanelExtension. thoughts? ideas? magic wand
> waving that will make this unecessary?

 A quite simple way to add new BC-breaking features to a class that doesn't 
have derived classes that have to stay BC is declaring this class as 
deprecated and using a class derived from it instead.

 Simply said, make KPanelExtension2 : public KPanelExtension, and add whatever 
you want. And depending on the answer to the question above, probably put it 
in libkicker_core. If we used namespaces, it could be even called 
KPanelExtension too, without breaking binary or source compatibility.

>
> i've looked at the virtual_hook option and boy is it ever ugly. i'd like to
> avoid using that if at all possible.

 I wonder if there will be somebody desperate enough to use it until KDE4.0.
 ;)

-- 
 Lubos Lunak
 l.lunak at email.cz ; l.lunak at kde.org
 http://dforce.sh.cvut.cz/~seli