Extender api review round 4

Kevin Ottens ervin at kde.org
Sat Sep 20 16:08:44 CEST 2008


Le Tuesday 16 September 2008, Rob Scheepmaker a écrit :
> Actually, you make a very compelling argument here... I haven't looked at
> it this way yet. It does require a change in extender.

OK.

> 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, you could keep this loadItems() method private, and trigger it 
asynchronously. Basically it'd be a private slot and you'd put a:
QTimer::singleShot(0, this, loadItems());

This way the API user can simply do:
Extender *extender = new Extender(...);
connect(extender, SIGNAL(...), this, SLOT(...));

That would basically it, the item loading would then be supposed to happen by 
itself.

> 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.

Well, it boils down to a similar problem, you'd have to make that separate 
from the ctor, otherwise you'll get warnings when attempting the connect on an 
Applet which wouldn't have the initExtenderItem slot.

> 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?

I prefer the first one (the loadItems() one) because when you read already 
written code it's more obvious what's going on (or you call loadItems() 
manually, or the QTimer as I propose). Otherwise your second proposal tends to 
make it too "magic" and convention-based IMO.

Regards.
-- 
Kévin 'ervin' Ottens, http://ervin.ipsquad.net
"Ni le maître sans disciple, Ni le disciple sans maître,
Ne font reculer l'ignorance."

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20080920/bc4fd62d/attachment.sig 


More information about the Plasma-devel mailing list