<div class="gmail_quote">On Sun, May 27, 2012 at 2:44 PM, Mark <span dir="ltr"><<a href="mailto:markg85@gmail.com" target="_blank">markg85@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div class="im">On Sun, May 27, 2012 at 9:43 AM, Aaron J. Seigo <span dir="ltr"><<a href="mailto:aseigo@kde.org" target="_blank">aseigo@kde.org</a>></span> wrote:<br></div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>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 order<br>
> to prevent a crash in the tooltip from crashing dolphin.<br>
<br>
</div>there is no reason this could not be accomodated in the Plasma tooltips. the<br>
file icon would specify that it has a tooltip, when shown the manager sends it<br>
the about to show signal, it starts the process of fetching data, when that<br>
arrives it actually populates the tooltip content.<br></blockquote><div><br></div></div><div>That could be some valuable info for Peter (Dolphin). Adding him in the cc just in case. </div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><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 altogether.<br>
<br>
</div>there are 3 classes in Plasma's tooltip system:<br>
<br>
ToolTipManager -> this one keeps track of which items have tooltips, owns the<br>
tooltip UI, shows/hides the actual tooltip and tells widgets when they should<br>
be updating their content because the tooltip will be shown (and again when to<br>
stop because it will be hidden)<br>
<br>
ToolTipContent -> this one stores what is in the tooltip itself and is 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. management to<br>
ToolTipManager.<br>
<br>
so if it is an issue of styling and controlling that style, then ToolTip 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></blockquote><div><br></div></div><div>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.</div>
<div><div class="h5">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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, it's a<br>
title, a separator, and a nicely aligned table of metadata. in Plasma we 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 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. </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
* it assumes one tooltip per widget; this was an issue for folderview, 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 isn't<br>
a real problem in practice.<br>
<br>
* ToolTipManager uses QMetaObject::invokeMethod to call toolTipAboutToShow 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 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></blockquote><div><br></div></div></div><div>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.</div>
<div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
> The current one is _way_ to much tailored at tooltips for the tasks<br>
> plasmoid and doesn't leave much room for customization (correct me if i'm<br>
> wrong).<br>
<br>
</div>the tooltips in Plasma are used by pretty much everything in Plasma. the only<br>
thing specific to the tasks plasmoid in them is the ability to view previews of<br>
windows.<br>
<br>
most things that use the tooltips ignore this feature cmpletely as it is not<br>
relevant to them. it is a requirement of some uses, such as in the tasks<br>
widget.<br>
<br>
so i wouldn't say that the current tooltips are too tailored to the tasks<br>
widget as they are used, well, everywhere.<br>
<div><br>
> I would like to suggest a ToolTipManager with styles! Not themes! I<br>
<br>
</div>perhaps this can be determined by the content rather than by explicitly<br>
setting the style in the application, which is probably just asking for<br>
inconsistencies. i also don't like the idea of having to subclass things just<br>
to get a nice tooltip in an application. it's both too much effort and too much<br>
of an invitation for inconsistency.<br></blockquote><div><br></div></div><div>Subclassing did seem like a nice but a little to complex for what it actually needs to do. So, no subclassing :) </div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
i realy wonder if the existing Plasma::ToolTipManager could not just be used<br>
in system settings already? if it is because it is too QGraphicsView centric,<br>
let's fix that first ...<br></blockquote><div><br></div></div><div>Oke, lets mix my idea up again :)</div><div>Lets put it in steps.</div><div><br></div><div>Step 1: How about i "refactor" the private ToolTip class to inherit from QDeclarativeView.</div>
<div>Step 2: Rewrite the current drawing logic for ToolTip in a QML file (TOOLTIP_STYLE_DEFAULT.qml).</div><div>Step 3: Introduce and enum:</div><div><br></div><div>enum ToolTipTemplate</div><div>{</div><div> STYLE_DEFAULT,</div>
<div> STYLE_SYSTEM_SETTINGS,</div><div> STYLE_DOLPHIN,</div><div> STYLE_CUSTOM</div><div>}</div><div><br></div><div>Step 4: introduce a setStyle in ToolTipContent with an optional 2nd parameter to set a custom QML file.</div>
<div><br></div><div>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.</div><div>The only thing i don't know how to do is how to make the ToolTipManager not focused in QGraphicsWidget anymore..</div>
<div><br></div><div>How does that sound? I kinda like the sound of it ^_^</div><div class="im"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
i do think this is a good project that can bring a very nice improvement in<br>
looks and consistency... thanks for taking it on! :)<br></blockquote><div><br></div></div><div>Thank you! </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span><font color="#888888"><br><span class="HOEnZb"><font color="#888888">
--<br>
Aaron J. Seigo</font></span></font></span><div class="im"><br>_______________________________________________<br>
Plasma-devel mailing list<br>
<a href="mailto:Plasma-devel@kde.org" target="_blank">Plasma-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/plasma-devel" target="_blank">https://mail.kde.org/mailman/listinfo/plasma-devel</a><br>
<br></div></blockquote></div><br>
<br>_______________________________________________<br>
Plasma-devel mailing list<br>
<a href="mailto:Plasma-devel@kde.org">Plasma-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/plasma-devel" target="_blank">https://mail.kde.org/mailman/listinfo/plasma-devel</a><br>
<br></blockquote></div><br>Hello,<br><br>maybe instead of this style parameter being an enum, it could be a string which would represent the QML file name. For example "" and "default" for default style (default.qml), "dolphin" for use in dolphin (dolphin.qml) etc.<br>
<br>These styles could then be saved in the same directory inside "KDE resource directory" and applications could "install" their own style to this directory.<br><br>Does this make sense also from implementation side? At least to me it look a little more open for adding new styles.<br>
<br>Regards,<br>Djuro Drljaca<br>