I noticed a problem,<br><br>In the new taskbar QGraphicsWidget are never deleted, so the tooltip is never unregistered....<br><br>Otherwhise in Qt the Tooltip event is generate by the QApplication and each widget react to this event if a tooltip content is set. It's radically different from here. Of course using default QToolTip is bad because it's only a text and we can do nothing with that (something that need to be improved). Otherwhise what we can do (Experimental) i will try is to react to ToolTip event instead of having our own manager. Problem : we can do that only in Applet class, so what about taskbar that contains QGraphicsWidgets ; Solution : then can overload event() method and catch the tooltip event in AbstractTaskItem, and display it (partially crap). In this case the only thing we have to provide is a Tooltip Widget that takes a QGraphicsWidget as argument and place itself correctly.<br>
<br>Feedbacks wanted to complete this approach.<br><br><br><div class="gmail_quote">2008/10/22 Kevin Ottens <span dir="ltr"><<a href="mailto:ervin@kde.org">ervin@kde.org</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">Le Tuesday 21 October 2008, Aaron J. Seigo a écrit :<br>
</div><div class="Ih2E3d">> > > > * void setToolTipContent (QGraphicsWidget *widget, const<br>
> > > > ToolTipContent &data)<br>
> > > ><br>
> > > > This one is very much used. Should stay. I'm not sure what to do<br>
> > > > about ToolTipContent though. Makes sense internally, but maybe in the<br>
> > > > public API you want to pass the parameters in the method. Not having<br>
> > > > to construct an object, set the members, then make the call.<br>
> > ><br>
> > > have you seen how many items we pass in? =)<br>
> ><br>
> > Between one and three? Doesn't looks like a big deal to me, but maybe<br>
> > that's just me. :-)<br>
><br>
> one and four, actually.<br>
<br>
</div>Ah? Aren't the WId and the QPixmap kind of mutually exclusive?<br>
Oh right, fallback system if no compositing... so yeah: four.<br>
<div class="Ih2E3d"><br>
> > Now in your changes last night you added something about state of the<br>
> > manager: activated, deactivated, inhibited. I'm wondering about this<br>
> > three/state thing, wouldn't inhibited or not be enough? In your doc about<br>
> > deactivated, it means ignoring calls to setContent(), I'm not really<br>
> > confident with having a method silently discarding the content passed<br>
> > depending on a state which might be set somewhere else. Looks like a neat<br>
> > way to shoot yourself in the foot.<br>
><br>
> the idea is for devices where we *never* want tooltips we also tend to be<br>
> more memory constrained ... sooooo ...<br>
<br>
</div>Ah, I see. Makes sense, might be abused from C++ though, so definitely<br>
something we don't want applet to be able to fiddle with: aka don't expose in<br>
scripting APIs.<br>
<div class="Ih2E3d"><br>
> > // no default, on purpose ;-)<br>
><br>
> all that does it make people write more lines of code. which is silly.<br>
<br>
</div>Improves readability on maintainance too... which isn't silly IMO.<br>
<br>
"setContent(w);" vs "setContent(w, Content());", on the first form if I read<br>
the line we could assume it's using anything as default value.<br>
<div><div></div><div class="Wj3C7c"><br>
Regards.<br>
--<br>
Kévin 'ervin' Ottens, <a href="http://ervin.ipsquad.net" target="_blank">http://ervin.ipsquad.net</a><br>
"Ni le maître sans disciple, Ni le disciple sans maître,<br>
Ne font reculer l'ignorance."<br>
</div></div><br>_______________________________________________<br>
Plasma-devel mailing list<br>
<a href="mailto:Plasma-devel@kde.org">Plasma-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/plasma-devel" target="_blank">https://mail.kde.org/mailman/listinfo/plasma-devel</a><br>
<br></blockquote></div><br>