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

[Aaron J. Seigo]

On Sunday, May 27, 2012 14:44:50 Mark wrote:
> On Sun, May 27, 2012 at 9:43 AM, Aaron J. Seigo <aseigo at kde.org> wrote:
> > 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.
> 
> That could be some valuable info for Peter (Dolphin). Adding him in the cc
> just in case.
> 
> > > 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?
> 
> Well, i guess we need.. Just the tasks plasmoid has 2 different tooltip
> styles. One for the app launcher icon and one for the launched apps with a
> preview. System settings needs another different style and dolphin needs
> yet another different style.
> 
> > 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?)
> 
> Dolphin created tooltips based on KFileItem. They then get send to
> dolphin's internal FileMetaDataToolTip class that makes puts it all
> together on top of a QWidget.

right; so for Dolphin, either subclassing ToolTipContent or making a factory 
method to turn a KFileItem into a ToolTipContent might be best. and then 
ToolTipManager can handle the rest from there.

OR ... ToolTipContent to have a constructor that takes a KFileItem and which 
does the translation internally. this would only make sense if there is more 
than one application in which a tooltip on a file would be useful. my guess is 
"yes", but that's just a guess. looking for these apps would be a good idea 
first.

what could be done is an iterative approach:

* make a subclass of ToolTipContent in libkonq that has this KFileItem mutator 
ability
* if there is use for it outside of kde-baseapps, at that point merge that 
code with ToolTipContent

> Step 1: How about i "refactor" the private ToolTip class to inherit
> from QDeclarativeView.

+1

> Step 2: Rewrite the current drawing logic for ToolTip in a QML file
> (TOOLTIP_STYLE_DEFAULT.qml).

+1

> Step 3: Introduce and enum:
> 
> enum ToolTipTemplate
> {
>     STYLE_DEFAULT,
>     STYLE_SYSTEM_SETTINGS,
>     STYLE_DOLPHIN,
>     STYLE_CUSTOM
> }

enums for specific applications sounds like a very bad idea. what if the 
applications change? what about other applications? which should they follow? 
if anything, the enum should be "semantic" in nature and named after what the 
view is for (file previews, window previews, ...)

even better would be no enumeration. instead, based on what is in the 
ToolTipContent intelligently pick the best layout internally. this has the 
benefit of a simpler API, less exposure of implementation details and less 
requirement for application developers to get it "right".

> Step 4: introduce a setStyle in ToolTipContent with an optional 2nd
> parameter to set a custom QML file.

let's see if we can get away without this first. otherwise, this becomes our 
excuse to use them everywhere because it means we don't have to think very 
hard ("just make another qml file!") and will more likely end up with 
fragmentation in the presentation ... which is exactly the state we have right 
now. 

so let's start with one QML file and only when we come upon something 
completely unworkable. iow, let's not schedule "Step 4" and only put it back 
in if/when it becomes required.

> This way the tooltips themselves are done in QML, there is still the option
> of styling - without making subclasses - and some default tooltips are
> provided.

that's a pretty nice idea :)

> The only thing i don't know how to do is how to make the ToolTipManager not
> focused in QGraphicsWidget anymore..

Marco already mentioned making it use QObjects in the public API. this would 
make the internal implementation a lot less pretty, but that's why it is 
internal.

i imagine it would use qobject_cast<>s to figure out what kind of object it was 
handling, and then add those objects to different collections of watched 
objects, with a type specific method for watching each. or, put another way, 
watching QGraphicsWidgets with one code path, QWidgets with another, 
QQuickItems with another (in future), etc. ... not pretty, but with the 
proliferation of ways of making UIs with Qt while we are in the transition 
state (which i expect to last at least until Qt6) i don't see a better way 
from a "public API must be pretty and must be able to maintain BC" point of 
view. 

-- 
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/49752a4a/attachment.sig>