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."
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
