Extender api review round 4

[Rob Scheepmaker]

On Tuesday 16 September 2008 00:25:47 Kevin Ottens wrote:
> I think I'm mostly the only proponent of those two ones. But I will state
> it again a last time because from the comments I've seen floating around I
> think my motivation for those ones got misunderstood.
>
> My reasons for not having them are the following:
> <snip>

Actually, you make a very compelling argument here... I haven't looked at it 
this way yet. It does require a change in extender. Currently in it's 
constructor, extenderItems are loaded and initExtenderItem get's called for 
every item. With signal/slot, the signal will first have to be connected to 
the slot. So either this would require one extra function, 
Extender::loadItems() so the applet can connect the signal with the slot 
before manually loading the items, or Extender's constructor connects 
extender's signal with an initExtenderItem slot in the applet, kind of like 
how dataengines can connect themselves with a dataUpdated slot.  I think this 
last approach is nicer.... that actually changes very little in the 
implementation of applets that use extenders.
The main disadvantage of this approach would be that I fear it's less obvious 
from just looking at the api how to use extenders. What do you think is the 
nicest approach?

Regards,
Rob Scheepmaker