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 _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
