On Sun, May 27, 2012 at 9:43 AM, Aaron J. Seigo <ase...@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.
>
> > 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.
>
Subclassing did seem like a nice but a little to complex for what it
actually needs to do. So, no subclassing :)
>
> 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 ...
>
Oke, lets mix my idea up again :)
Lets put it in steps.
Step 1: How about i "refactor" the private ToolTip class to inherit
from QDeclarativeView.
Step 2: Rewrite the current drawing logic for ToolTip in a QML file
(TOOLTIP_STYLE_DEFAULT.qml).
Step 3: Introduce and enum:
enum ToolTipTemplate
{
STYLE_DEFAULT,
STYLE_SYSTEM_SETTINGS,
STYLE_DOLPHIN,
STYLE_CUSTOM
}
Step 4: introduce a setStyle in ToolTipContent with an optional 2nd
parameter to set a custom QML file.
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.
The only thing i don't know how to do is how to make the ToolTipManager not
focused in QGraphicsWidget anymore..
How does that sound? I kinda like the sound of it ^_^
> i do think this is a good project that can bring a very nice improvement in
> looks and consistency... thanks for taking it on! :)
>
Thank you!
>
> --
> Aaron J. Seigo
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
