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