The tooltip state. Not that good. Proposal for improvement.

[Aaron J. Seigo]

On Saturday, May 26, 2012 03:08:41 Mark wrote:
> For dolphin i can understand the reason to have it's own tooltip class
> because it wants to fetch the tooltip data in a separate process in order
> to prevent a crash in the tooltip from crashing dolphin.

there is no reason this could not be accomodated in the Plasma tooltips. the 
file icon would specify that it has a tooltip, when shown the manager sends it 
the about to show signal, it starts the process of fetching data, when that 
arrives it actually populates the tooltip content.

> To get this in a workable situation where anyone can use the tooltips as
> they seem right we probably have to make a new ToolTipManager altogether.

there are 3 classes in Plasma's tooltip system:

ToolTipManager -> this one keeps track of which items have tooltips, owns the 
tooltip UI, shows/hides the actual tooltip and tells widgets when they should 
be updating their content because the tooltip will be shown (and again when to 
stop because it will be hidden)

ToolTipContent -> this one stores what is in the tooltip itself and is used by 
the widget to tell the manager what should be shown

ToolTip -> this is a private class, and handles the UI display

styling belongs to ToolTip. definition belongs to ToolTipContent. management to 
ToolTipManager. 

so if it is an issue of styling and controlling that style, then ToolTip would 
need adjustment and perhaps ToolTipContent to direct which style to use. 
ToolTipManager probably wouldn't get touched.

however, do we really need radically different visual styles?

all three application have a pixmap on the left and text on the right. the 
text on the right changes a fair amount from app to app, though: in 
systemsettings it is a category, a separator and a listing; in dolpin, it's a 
title, a separator, and a nicely aligned table of metadata. in Plasma we see 
very similar arrangements in the clock with multiple timezones and in the 
pager displaying multiple windows.

so i'm not sure it's a styling issue at all, and would in fact suggest that 
having a consistent presentation would be an improvement over the current 
situation.

there are things that could use some improving, however:

* Plasma::ToolTipManager is fairly focused on QGraphicsWidget. making it 
usable with QWidgets and ready for QML2 is probably important.

* it assumes one tooltip per widget; this was an issue for folderview, which 
it worked around by putting an invisible item over the item the mouse was 
over. perhaps this could have been different in folderview, however, and isn't 
a real problem in practice.

* ToolTipManager uses QMetaObject::invokeMethod to call toolTipAboutToShow and 
toolTipAboutToHide in items that have tooltips. it would be nice to have a 
more elegant way to do this, in particular a mechanism that would work nicely 
with QML2 and which allows the widget with the tooltip to define the 
connection.

so there are certainly some design issues to be addressed.

as for content, it would be interesting to see if ToolTipContent could be 
extended in some way to more easily accomodate the needs of things like 
showing a table of data (perhaps a QHash<QString, QString> .. what does 
dolphin use for this datastructure?)

> The current one is _way_ to much tailored at tooltips for the tasks
> plasmoid and doesn't leave much room for customization (correct me if i'm
> wrong). 

the tooltips in Plasma are used by pretty much everything in Plasma. the only 
thing specific to the tasks plasmoid in them is the ability to view previews of 
windows.

most things that use the tooltips ignore this feature cmpletely as it is not 
relevant to them. it is a requirement of some uses, such as in the tasks 
widget.

so i wouldn't say that the current tooltips are too tailored to the tasks 
widget as they are used, well, everywhere.

> I would like to suggest a ToolTipManager with styles! Not themes! I

perhaps this can be determined by the content rather than by explicitly 
setting the style in the application, which is probably just asking for 
inconsistencies. i also don't like the idea of having to subclass things just 
to get a nice tooltip in an application. it's both too much effort and too much 
of an invitation for inconsistency.

i realy wonder if the existing Plasma::ToolTipManager could not just be used 
in system settings already? if it is because it is too QGraphicsView centric, 
let's fix that first ...

i do think this is a good project that can bring a very nice improvement in 
looks and consistency... thanks for taking it on! :)

-- 
Aaron J. Seigo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20120527/072f83f2/attachment.sig>