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

Mark markg85 at gmail.com
Sat May 26 01:08:41 UTC 2012


Hi,

While trying to fix some blur issues on tooltips i found myself digging
deeper in ... other issues.

For starters, there is no tooltip consistency!
- Dolphin uses it's own tooltip classes.
- System Settings uses it's own tooltip classes.
- The plasma panels use the Plasma::ToolTipManager class - like it should
be!

That's only for the consistency using classes! The style also differs and
only the last one has blur behind it [1].

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.

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.
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). I would like to suggest a ToolTipManager with styles! Not themes! I
repeat, not themes! Just style as in which data is being displayed where.
The plasma theme is still the one to be for the theme so nothing changes
there. What i think that should be possible is defining a ToolTip Theme. Or
i actually think it's required if the plasma tooltip stuff is to be used in
places where the tooltip can look completely different (again, like
dolphin).

For example (in ascii art).
ToolTipTheme - Dolphin

  |-------|          test...
  |ICON|  ------------------------
  |-------|  test...
               text...

ToolTipTheme - TasksAppLauncher

  |-------|  APP NAME
  |ICON|  APP DESCRIPTION
  |-------|

ToolTipTheme - TasksPopup

  |--------------------------|
  |--------------------------|
  |--------------------------|
  |--------------------------|
  |--------------------------|
  |--------------------------|
  |-------|
  |ICON|  APP DESCRIPTION
  |-------|

That should make the intention clear even though the ascii art sucks ;)

I would say that we need an abstract theme class:

class ToolTipThemeAbstract
{
  virtual QGraphisWidget* getTheme() = 0;
}

and some classes that implement it:
class ToolTipThemeDolphin : public ToolTipThemeAbstract
{
  QGraphisWidget* getTheme();
}

In this case the theme for Task popups would do the rendering of the
preview and window stuff.

The ToolTipManager call would remain the same only the values would be
different.
Plasma::ToolTipManager::self()->setContent(QGraphicsWidget,
ToolTipThemeAbstract);
The ToolTipManager would simply render the theme (getTheme()). I'm not
quite sure yet if the data can just be put directly in the theme or if the
theme and data should be separated.

Also, some themes should probably be provided by default. For example
the TasksAppLauncher theme like in the ascii art above seems like a quite
common fancy tooltip. Other themes like the dolphin one should just be an
"in house" theme in the dolphin codebase. Others might like it, but it's
certainly not a default theme that needs to be provided or something.

I think this would cleanup the ToolTip mess quite a bit and make it very
flexible for everyone to use.

I will try and make a proof of concept for this in the coming days. Don't
count on anything though - just to prevent high hopes.
If this works out and is going to be used for KDE then i would like to
deprecate the current ToolTip and friend classes, delete them in frameworks
and replace everything by this proposed tooltip structure.

Please do let me know what your thoughts are about this one!

Cheers,
Mark

[1] Right now i'm fixing the blur issue for Dolphin and System Settings.
Those patches will appear on reviewboard somewhere tomorrow.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20120526/e7dd6e46/attachment-0001.html>


More information about the Plasma-devel mailing list