--===============0995199480==
Content-Type: multipart/alternative; 
	boundary="----=_Part_27741_17165066.1224684757653"

------=_Part_27741_17165066.1224684757653
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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 tha=
t
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 a=
s
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 =E9crit :
> > > > > * 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? =3D)
> > >
> > > 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 expos=
e
> 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=E9vin 'ervin' Ottens, http://ervin.ipsquad.net
> "Ni le ma=EEtre sans disciple, Ni le disciple sans ma=EEtre,
> Ne font reculer l'ignorance."
>
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>

------=_Part_27741_17165066.1224684757653
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

I noticed a problem,<br><br>In the new taskbar QGraphicsWidget are never de=
leted, so the tooltip is never unregistered....<br><br>Otherwhise in Qt the=
 Tooltip event is generate by the QApplication and each widget react to thi=
s event if a tooltip content is set. It&#39;s radically different from here=
. Of course using default QToolTip is bad because it&#39;s only a text and =
we can do nothing with that (something that need to be improved). Otherwhis=
e what we can do (Experimental) i will try is to react to ToolTip event ins=
tead of having our own manager. Problem : we can do that only in Applet cla=
ss, 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 p=
rovide is a Tooltip Widget that takes a QGraphicsWidget as argument and pla=
ce itself correctly.<br>
<br>Feedbacks wanted to complete this approach.<br><br><br><div class=3D"gm=
ail_quote">2008/10/22 Kevin Ottens <span dir=3D"ltr">&lt;<a href=3D"mailto:=
ervin@kde.org">ervin@kde.org</a>&gt;</span><br><blockquote class=3D"gmail_q=
uote" style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0=
pt 0.8ex; padding-left: 1ex;">
<div class=3D"Ih2E3d">Le Tuesday 21 October 2008, Aaron J. Seigo a =E9crit =
:<br>
</div><div class=3D"Ih2E3d">&gt; &gt; &gt; &gt; * void &nbsp; setToolTipCon=
tent (QGraphicsWidget *widget, const<br>
&gt; &gt; &gt; &gt; ToolTipContent &amp;data)<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; This one is very much used. Should stay. I&#39;m not su=
re what to do<br>
&gt; &gt; &gt; &gt; about ToolTipContent though. Makes sense internally, bu=
t maybe in the<br>
&gt; &gt; &gt; &gt; public API you want to pass the parameters in the metho=
d. Not having<br>
&gt; &gt; &gt; &gt; to construct an object, set the members, then make the =
call.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; have you seen how many items we pass in? =3D)<br>
&gt; &gt;<br>
&gt; &gt; Between one and three? Doesn&#39;t looks like a big deal to me, b=
ut maybe<br>
&gt; &gt; that&#39;s just me. :-)<br>
&gt;<br>
&gt; one and four, actually.<br>
<br>
</div>Ah? Aren&#39;t the WId and the QPixmap kind of mutually exclusive?<br=
>
Oh right, fallback system if no compositing... so yeah: four.<br>
<div class=3D"Ih2E3d"><br>
&gt; &gt; Now in your changes last night you added something about state of=
 the<br>
&gt; &gt; manager: activated, deactivated, inhibited. I&#39;m wondering abo=
ut this<br>
&gt; &gt; three/state thing, wouldn&#39;t inhibited or not be enough? In yo=
ur doc about<br>
&gt; &gt; deactivated, it means ignoring calls to setContent(), I&#39;m not=
 really<br>
&gt; &gt; confident with having a method silently discarding the content pa=
ssed<br>
&gt; &gt; depending on a state which might be set somewhere else. Looks lik=
e a neat<br>
&gt; &gt; way to shoot yourself in the foot.<br>
&gt;<br>
&gt; the idea is for devices where we *never* want tooltips we also tend to=
 be<br>
&gt; more memory constrained ... sooooo ...<br>
<br>
</div>Ah, I see. Makes sense, might be abused from C++ though, so definitel=
y<br>
something we don&#39;t want applet to be able to fiddle with: aka don&#39;t=
 expose in<br>
scripting APIs.<br>
<div class=3D"Ih2E3d"><br>
&gt; &gt; &nbsp; // no default, on purpose ;-)<br>
&gt;<br>
&gt; all that does it make people write more lines of code. which is silly.=
<br>
<br>
</div>Improves readability on maintainance too... which isn&#39;t silly IMO=
.<br>
<br>
&quot;setContent(w);&quot; vs &quot;setContent(w, Content());&quot;, on the=
 first form if I read<br>
the line we could assume it&#39;s using anything as default value.<br>
<div><div></div><div class=3D"Wj3C7c"><br>
Regards.<br>
--<br>
K=E9vin &#39;ervin&#39; Ottens, <a href=3D"http://ervin.ipsquad.net" target=
=3D"_blank">http://ervin.ipsquad.net</a><br>
&quot;Ni le ma=EEtre sans disciple, Ni le disciple sans ma=EEtre,<br>
Ne font reculer l&#39;ignorance.&quot;<br>
</div></div><br>_______________________________________________<br>
Plasma-devel mailing list<br>
<a href=3D"mailto:Plasma-devel@kde.org">Plasma-devel@kde.org</a><br>
<a href=3D"https://mail.kde.org/mailman/listinfo/plasma-devel" target=3D"_b=
lank">https://mail.kde.org/mailman/listinfo/plasma-devel</a><br>
<br></blockquote></div><br>

------=_Part_27741_17165066.1224684757653--

--===============0995199480==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

--===============0995199480==--