Le Tuesday 21 October 2008, Aaron J. Seigo a écrit : > > > > * void setToolTipContent (QGraphicsWidget *widget, const > > > > ToolTipContent &data) > > > > > > > > This one is very much used. Should stay. I'm not sure what to do > > > > about ToolTipContent though. Makes sense internally, but maybe in the > > > > public API you want to pass the parameters in the method. Not having > > > > to construct an object, set the members, then make the call. > > > > > > have you seen how many items we pass in? =) > > > > Between one and three? Doesn't looks like a big deal to me, but maybe > > that's just me. :-) > > one and four, actually.
Ah? Aren't the WId and the QPixmap kind of mutually exclusive? Oh right, fallback system if no compositing... so yeah: four. > > Now in your changes last night you added something about state of the > > manager: activated, deactivated, inhibited. I'm wondering about this > > three/state thing, wouldn't inhibited or not be enough? In your doc about > > deactivated, it means ignoring calls to setContent(), I'm not really > > confident with having a method silently discarding the content passed > > depending on a state which might be set somewhere else. Looks like a neat > > way to shoot yourself in the foot. > > the idea is for devices where we *never* want tooltips we also tend to be > more memory constrained ... sooooo ... Ah, I see. Makes sense, might be abused from C++ though, so definitely something we don't want applet to be able to fiddle with: aka don't expose in scripting APIs. > > // no default, on purpose ;-) > > all that does it make people write more lines of code. which is silly. Improves readability on maintainance too... which isn't silly IMO. "setContent(w);" vs "setContent(w, Content());", on the first form if I read the line we could assume it's using anything as default value. 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
