[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-panel-devel
Subject: Re: Plasma::ToolTipManager API review
From: "=?ISO-8859-1?Q?Alexis_M=E9nard?=" <menard () kde ! org>
Date: 2008-10-22 14:12:37
Message-ID: 81941aea0810220712ub60c759kc522aca11f2dfb00 () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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@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@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>
[Attachment #5 (text/html)]
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>
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic