<br><br>Op dinsdag 19 juni 2012 schreef Marco Martin (<a href="mailto:notmart@gmail.com">notmart@gmail.com</a>) het volgende:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Tuesday 19 June 2012, Mark wrote:<br>
> Hi,<br>
><br>
> Today was quite an interesting day with QML tooltips. One issue after<br>
> the other popped up.<br>
<br>
but it's *very* useful that you made those issues pop up, don't see it as<br>
wasted time ;)</blockquote><div><br></div><div>Yeah, well... I hate the fact that everytime i want to do something big in kde i hit a very hard blocking issue. The last one was with adding just one more QAction (KAction) shortcut, that turned out to be a design issue in kde's kaction and kshortcut that mobes back into qt itself! I don't see this one as wasted time, but it is frustrating at times. </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> What i have right now are working tooltips in a very rough shape. The<br>
> icon provided is also being shown in the tooltip and overall it looks<br>
> somewhat decent to continue to the next step. That would be to make<br>
> Dolphin and System Settings usable with these tooltips.<br>
><br>
> Sadly, while improving it further, i've hit a blocking issue that i<br>
> can't fix. The following issues arose of which the 2nd one is blocking<br>
> me right now.<br>
> 1. Somehow when moving the cursor from an item that shows a tooltip<br>
> (like the tasks) to another item that shows a bigger tooltip (like the<br>
> pager) the result is a messed up layout: <a href="http://ompldr.org/vZWUyNw" target="_blank">http://ompldr.org/vZWUyNw</a><br>
<br>
having seen a bit of the code, i think there is still the possibility that is<br>
the tooltip mainitem having the wrong size (otherwise would be clipped only at<br>
bottom)<br>
would need some debug to say what is the size of mainitem and what is the size<br>
of the things it contains</blockquote><div><br></div><div>Could you....? </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> This doesn't happen if i directly hover over the pager icon for the<br>
> tooltip. I haven't found a cause for this. (note, the position itself<br>
> is OK here, but done manually which is wrong)<br>
> 2. Tooltips positioned using popupPosition are positioned directly<br>
> above the item where they need to be positioned:<br>
> <a href="http://ompldr.org/vZWUyNg" target="_blank">http://ompldr.org/vZWUyNg</a> This is the way it's currently designed and<br>
> Marco doesn't want to break the design in the KDE 4.x series. This is<br>
> something he will look into for KF5.<br>
<br>
this doesn't depend from the position, that is correct.<br>
depends from the fact that Dialog doesn't paint the borders that are near to<br>
the screen edge or to a panel.<br>
<br>
now, this is ok for the use case of popups, because a) they are designed as<br>
objects that come out from the panel, b) when is attached to the screen edge<br>
it will accept input from the mouse until the very border (fitts law)<br>
<br>
> 3. The height of the tooltips cannot be animated because height (and<br>
> width) are read-only. Furthermore, since it's a window, it's likely to<br>
> be slow as well due to X11 resizing stuff.<br>
<br>
yeah, i don't much see solutions to this one on x11 (waylaaand;).<br>
iirc there was a kwin plugin in the works that tried to fake a smooth resize<br>
of windows with a transition of their pixmaps? is that thing still alive?<br>
<br>
in brief, is not pretty, bit don't worry about size animation for now</blockquote><div><span class="Apple-style-span" style><br></span></div><div><span class="Apple-style-span" style> As said, i'm oke with this limitation. </span><br>
</div><div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> 4. added to this is my dislike against PlasmaCore.Dialog. I simply<br>
> don't like it but gave it my best try to use it.<br>
><br>
> The first one is something i can work around. Third is also something<br>
> i can live with, but combined with the issues i had before and along<br>
> with my dislike for PlasmaCore.Dialog and the fundamental design<br>
> change that needs to happen to make it usable for tooltips makes me<br>
> think that i should perhaps do things a bit differently.<br>
<br>
It's done for popups, and in order for popups to be consistent, freedom to do<br>
whatever with it must be sacrified<br>
<br>
> Marco also suggested that i copy the current PlasmaCore.Dialog C++<br>
> side and adjust it for the tooltip needs. That's the part where i<br>
> really could use some help in deciding how i should go further with<br>
> this. The side effects are not really what i'd like to see. If i<br>
> follow this approach it means that the (to be made) libTooltip (which<br>
> was supposed to be as clean as possible with as little dependencies as<br>
> possible) is suddenly going to link against Plasma. Which was the<br>
> exact reason why it should be split in it's own library to prevent a<br>
> plasma dependency! Note that any application using the lib will need<br>
> plasma, but if i could have used PlasmaCore.Dialog it would be a<br>
> runtime dependency. Now it looks like it's going to be a compile time<br>
> dependency as well which kinda beats the purpose of making a library<br>
> out of it.<br>
<br>
I'm still not sold about moving tooltips outside libplasma. If this is so,<br>
using a different qml file that doesn't import plasma when an app is not ran<br>
in kde wouldn't be hard tough.<br>
if it's outside libplasma also means quite a lot of code to be duplicated,<br>
tooltipmanager, tooltipdata, tooltip and pieces of corona such as<br>
popupposition (eh, there is really no way around every single corner case that<br>
function takes care has to be managed) at that point plasma2 could use that<br>
library and not provide a tooltip anymore, that's also an option.</blockquote><div><br></div><div>The idea was to move all tooltip stuff from plasma to it's own library. Including the things you mention here. </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
It also means the tooltip won't use corona but a private scene. I always tried<br>
to limit the proliferation of private qgraphicsscenes, but looks like in qml2<br>
won't matter anymore since there is 1:1 correspondence scene/view.<br>
<br>
in the end the easiest solution would be taking the current ToolTip private<br>
class, showel a QDeclarativeView in it as the main layout element and be done.</blockquote><div><br></div><div>I'm already doing that! Now i just make a dialog in qml and move it around. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
the reasons why Dialog is at the moment suitable are mainly two:<br>
* it removes the borders when it goes at the edge of the screen<br>
* it uses dialogs/background.svgz instead of widgets/tooltip.svgz for its<br>
background<br>
<br>
i would really rather not add api to control those two things, given kdelibs<br>
is frozen and i don't think would be a good approach anyways.<br>
<br>
> So these are the options i currently see:<br>
><br>
> - Abandon PlasmaCore.Dialog, copy the C++ side behind it and fix it<br>
> according to my needs. This also means that i will have a custom QML<br>
> import where that new component will be living. Added dependency of<br>
> plasma.<br>
<br>
no, it doesn't have to be an import there are several other ways to do it,<br>
that in this case are more suitable.<br>
<br>
a class name that will instantiate a c++ object can be registered from the c++<br>
part with qmlRegisterType<br>
or in this case even better, the whole qgraphicsview would be instantiated<br>
from the c++ part in the tooltipmanager itself (would be what is the ToolTip<br>
private class nowdays) so the qml would only manage the layout and won't know<br>
about the window at all (if in the end is decided to do an independent thing<br>
where is not an issue to have its own private scene it may even be a<br>
qdeclarativeview).<br>
this is imo the best option.</blockquote><div><br></div><div>Change of plans. All these options mean that the library is going to link against plasma at compile time. So from now on i will continue with this in the following way:</div>
<div>- it's going to be inside of plasma</div><div>- adding a private dialog class that either inherits plasma::dialog or the dialog from marco</div><div>- sending that one to qml either by import or by registering it's type whichever one works the easiest</div>
<div><br></div><div>How does that sound? Though i'm guessing it is going to be for KF5 if i keep it in plasma -_-<span></span></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
Cheers,<br>
Marco Martin<br>
_______________________________________________<br>
Plasma-devel mailing list<br>
<a href="javascript:;" onclick="_e(event, 'cvml', '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>
</blockquote>