[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-panel-devel
Subject:    Re: Tool tips - again
From:       Emdek <emdeck () gmail ! com>
Date:       2009-04-13 19:54:45
Message-ID: op.uscb9ju0e84fud () michal
[Download RAW message or body]

On Monday 13-04-2009 19:26:52 Aaron J. Seigo wrote:
> On Sunday 12 April 2009, Emdek wrote:
> > On Sunday 12-04-2009 18:18:01 Aaron J. Seigo wrote:
> > > > - show titles of windows when showing multiple previews;
> > > 
> > > will this fit nicely? look nice? could we do it with QToolTips on the
> > > previews?
> > 
> > I'm using it already in my applet and it looks good I think:
> > 
> > http://kde-look.org/CONTENT/content-pre1/99737-1.png
> 
> and for really long titles? i suppose you just elide the text?

No, currently I'm not, but I should (I want to move to standard tool tips so I'm not \
touching this part of code now ;-)). So if the text is tool long the we could use \
that kind of gradient like in Tasks applet and the show full text in tool tip for \
tool tip (my friend that works on STasks applet proposed marque animation for it). \
;-)



> how about:
> 
> ToolTipSignaller *ToolTipContent::signallerFor(QGraphicsWidget *target)
> {
> ToolTipSignaller *signaller = d->signallers.value(target);
> 
> if (!signaller) {
> signaller = new ToolTipSignaller(target);
> d->signallers.insert(target, signaller);
> }
> 
> return signaller;
> }
> 
> the signals would belong to this ToolTipSignals class; in fact, that's  
> all it
> would contain: a handful of signals.
> 
> when ToolTipManager::currentWidget is changing, disconnect the old (if  
> any)
> signaller for the widget and connect the new signaller (if any) for the  
> new
> widget to signals from ToolTip. this would cause signals from ToolTip to  
> end
> up at the correct destination object, via the signaller.
> 
> then in ToolTipContentPrivate::onWidgetDestroyed() remove the  
> ToolTipSignaller
> *from the d->signallers collection.
> 
> how's that sound?

Looks good I think. :-)



> heck, we could even replace the fugly tooltipAboutToShow and
> tooltipAboutToHide nonsense with this stuff .. why didn't i think of  
> this last
> year? *sigh*

But there will be still old signals for backward compatibility of course?



> > So now we need clear list of needed signals and then start to work. ;-)
> 
> hoverEnter(const KUrl &)
> hoverLeave(const KUrl &)
> activated(const KUrl &)

And what about these (mostly activation for WId, with used mouse button, rest of them \
is much less useful I think)?

> activated(ToolTipWidget, MouseButton) <- allows to trigger action for given widget \
> using left, middle, right mouse button, but only single click but are we really \
> need double clicking here? Three possibilities should be enough for start. \
> activated(WId, MouseButton) <- the same as before, but for window previews, \
> especially for multiple previews. activated(KUrl, MouseButton) <- for urls (maybe \
> QString instead of KUrl, I don't know...).


I'm not sure if working on signals part isn't too big task for me (I need first to \
read code of tool tip manager), but I could at least start to work on preview part I \
think (setting QPixmap and glowing frame on hover). Maybe this should be added to \
tasks list on techbase (soft freeze is coming)?


_______________________________________________
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]