Plasma::ToolTipManager API review

[Alexis Ménard]

I noticed a problem,

In the new taskbar QGraphicsWidget are never deleted, so the tooltip is
never unregistered....

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.

Feedbacks wanted to complete this approach.


2008/10/22 Kevin Ottens <ervin at kde.org>

> 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."
>
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/plasma-devel/attachments/20081022/e09b23de/attachment.htm