<div class="gmail_quote">On Sun, May 27, 2012 at 5:48 PM, Aaron J. Seigo <span dir="ltr"><<a href="mailto:aseigo@kde.org" target="_blank">aseigo@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="HOEnZb"><div class="h5">On Sunday, May 27, 2012 14:44:50 Mark wrote:<br>
> On Sun, May 27, 2012 at 9:43 AM, Aaron J. Seigo <<a href="mailto:aseigo@kde.org">aseigo@kde.org</a>> wrote:<br>
> > On Saturday, May 26, 2012 03:08:41 Mark wrote:<br>
> > > For dolphin i can understand the reason to have it's own tooltip class<br>
> > > because it wants to fetch the tooltip data in a separate process in<br>
> > > order<br>
> > > to prevent a crash in the tooltip from crashing dolphin.<br>
> ><br>
> > there is no reason this could not be accomodated in the Plasma tooltips.<br>
> > the<br>
> > file icon would specify that it has a tooltip, when shown the manager<br>
> > sends it<br>
> > the about to show signal, it starts the process of fetching data, when<br>
> > that<br>
> > arrives it actually populates the tooltip content.<br>
><br>
> That could be some valuable info for Peter (Dolphin). Adding him in the cc<br>
> just in case.<br>
><br>
> > > To get this in a workable situation where anyone can use the tooltips as<br>
> > > they seem right we probably have to make a new ToolTipManager<br>
> > > altogether.<br>
> ><br>
> > there are 3 classes in Plasma's tooltip system:<br>
> ><br>
> > ToolTipManager -> this one keeps track of which items have tooltips, owns<br>
> > the<br>
> > tooltip UI, shows/hides the actual tooltip and tells widgets when they<br>
> > should<br>
> > be updating their content because the tooltip will be shown (and again<br>
> > when to<br>
> > stop because it will be hidden)<br>
> ><br>
> > ToolTipContent -> this one stores what is in the tooltip itself and is<br>
> > used by<br>
> > the widget to tell the manager what should be shown<br>
> ><br>
> > ToolTip -> this is a private class, and handles the UI display<br>
> ><br>
> > styling belongs to ToolTip. definition belongs to ToolTipContent.<br>
> > management to<br>
> > ToolTipManager.<br>
> ><br>
> > so if it is an issue of styling and controlling that style, then ToolTip<br>
> > would<br>
> > need adjustment and perhaps ToolTipContent to direct which style to use.<br>
> > ToolTipManager probably wouldn't get touched.<br>
> ><br>
> > however, do we really need radically different visual styles?<br>
><br>
> Well, i guess we need.. Just the tasks plasmoid has 2 different tooltip<br>
> styles. One for the app launcher icon and one for the launched apps with a<br>
> preview. System settings needs another different style and dolphin needs<br>
> yet another different style.<br>
><br>
> > all three application have a pixmap on the left and text on the right. the<br>
> > text on the right changes a fair amount from app to app, though: in<br>
> > systemsettings it is a category, a separator and a listing; in dolpin,<br>
> > it's a<br>
> > title, a separator, and a nicely aligned table of metadata. in Plasma we<br>
> > see<br>
> > very similar arrangements in the clock with multiple timezones and in the<br>
> > pager displaying multiple windows.<br>
> ><br>
> > so i'm not sure it's a styling issue at all, and would in fact suggest<br>
> > that<br>
> > having a consistent presentation would be an improvement over the current<br>
> > situation.<br>
> ><br>
> > there are things that could use some improving, however:<br>
> ><br>
> > * Plasma::ToolTipManager is fairly focused on QGraphicsWidget. making it<br>
> > usable with QWidgets and ready for QML2 is probably important.<br>
> ><br>
> ><br>
> > * it assumes one tooltip per widget; this was an issue for folderview,<br>
> > which<br>
> > it worked around by putting an invisible item over the item the mouse was<br>
> > over. perhaps this could have been different in folderview, however, and<br>
> > isn't<br>
> > a real problem in practice.<br>
> ><br>
> > * ToolTipManager uses QMetaObject::invokeMethod to call toolTipAboutToShow<br>
> > and<br>
> > toolTipAboutToHide in items that have tooltips. it would be nice to have a<br>
> > more elegant way to do this, in particular a mechanism that would work<br>
> > nicely<br>
> > with QML2 and which allows the widget with the tooltip to define the<br>
> > connection.<br>
> ><br>
> > so there are certainly some design issues to be addressed.<br>
> ><br>
> > as for content, it would be interesting to see if ToolTipContent could be<br>
> > extended in some way to more easily accomodate the needs of things like<br>
> > showing a table of data (perhaps a QHash<QString, QString> .. what does<br>
> > dolphin use for this datastructure?)<br>
><br>
> Dolphin created tooltips based on KFileItem. They then get send to<br>
> dolphin's internal FileMetaDataToolTip class that makes puts it all<br>
> together on top of a QWidget.<br>
<br>
</div></div>right; so for Dolphin, either subclassing ToolTipContent or making a factory<br>
method to turn a KFileItem into a ToolTipContent might be best. and then<br>
ToolTipManager can handle the rest from there.<br>
<br>
OR ... ToolTipContent to have a constructor that takes a KFileItem and which<br>
does the translation internally. this would only make sense if there is more<br>
than one application in which a tooltip on a file would be useful. my guess is<br>
"yes", but that's just a guess. looking for these apps would be a good idea<br>
first.<br>
<br>
what could be done is an iterative approach:<br>
<br>
* make a subclass of ToolTipContent in libkonq that has this KFileItem mutator<br>
ability<br>
* if there is use for it outside of kde-baseapps, at that point merge that<br>
code with ToolTipContent<br>
<div class="im"><br>
> Step 1: How about i "refactor" the private ToolTip class to inherit<br>
> from QDeclarativeView.<br>
<br>
</div>+1<br>
<div class="im"><br>
> Step 2: Rewrite the current drawing logic for ToolTip in a QML file<br>
> (TOOLTIP_STYLE_DEFAULT.qml).<br>
<br>
</div>+1<br>
<div class="im"><br>
> Step 3: Introduce and enum:<br>
><br>
> enum ToolTipTemplate<br>
> {<br>
>     STYLE_DEFAULT,<br>
>     STYLE_SYSTEM_SETTINGS,<br>
>     STYLE_DOLPHIN,<br>
>     STYLE_CUSTOM<br>
> }<br>
<br>
</div>enums for specific applications sounds like a very bad idea. what if the<br>
applications change? what about other applications? which should they follow?<br>
if anything, the enum should be "semantic" in nature and named after what the<br>
view is for (file previews, window previews, ...)<br>
<br>
even better would be no enumeration. instead, based on what is in the<br>
ToolTipContent intelligently pick the best layout internally. this has the<br>
benefit of a simpler API, less exposure of implementation details and less<br>
requirement for application developers to get it "right".<br>
<div class="im"><br>
> Step 4: introduce a setStyle in ToolTipContent with an optional 2nd<br>
> parameter to set a custom QML file.<br>
<br>
</div>let's see if we can get away without this first. otherwise, this becomes our<br>
excuse to use them everywhere because it means we don't have to think very<br>
hard ("just make another qml file!") and will more likely end up with<br>
fragmentation in the presentation ... which is exactly the state we have right<br>
now.<br>
<br>
so let's start with one QML file and only when we come upon something<br>
completely unworkable. iow, let's not schedule "Step 4" and only put it back<br>
in if/when it becomes required.<br>
<div class="im"><br>
> This way the tooltips themselves are done in QML, there is still the option<br>
> of styling - without making subclasses - and some default tooltips are<br>
> provided.<br>
<br>
</div>that's a pretty nice idea :)<br>
<div class="im"><br>
> The only thing i don't know how to do is how to make the ToolTipManager not<br>
> focused in QGraphicsWidget anymore..<br>
<br>
</div>Marco already mentioned making it use QObjects in the public API. this would<br>
make the internal implementation a lot less pretty, but that's why it is<br>
internal.<br>
<br>
i imagine it would use qobject_cast<>s to figure out what kind of object it was<br>
handling, and then add those objects to different collections of watched<br>
objects, with a type specific method for watching each. or, put another way,<br>
watching QGraphicsWidgets with one code path, QWidgets with another,<br>
QQuickItems with another (in future), etc. ... not pretty, but with the<br>
proliferation of ways of making UIs with Qt while we are in the transition<br>
state (which i expect to last at least until Qt6) i don't see a better way<br>
from a "public API must be pretty and must be able to maintain BC" point of<br>
view.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Aaron J. Seigo<br></font></span><br></blockquote><div> </div><div>Awesome! First things first, Inheriting from QDeclarativeView and I'll see how to progress from there.</div><div>I will ignore theming for now and just get the basics working.</div>

<div><br></div><div>Also, there was - some time ago - a blog post about a new QML thing to make window previews possible in QML.. I can't find that post any, but i need it for this to work. Does anyone know where it's hidden?</div>

<div><br></div><div>Is this (tooltip refactoring) going to be for frameworks only or for KDE 4.10(?) as well?</div><div><br></div><div>Right now i'm making "hack fixes" for System Settings - followed by dolphin afterwards - to at least let the tooltips look the same as the panel tooltips.</div>

<div>It's actually progressing quite nicely though i'm having some stupid icon frame that doesn't want to go away at the moment :p <a href="http://ompldr.org/vZHk4Ng">http://ompldr.org/vZHk4Ng</a></div><div><br>

</div><div>The alignment issues where already there.. Lets say it's "tightly" aligned ;)</div></div>