QML Tooltip progression. Hitting a few snags.

Tue Jun 19 13:01:47 UTC 2012

Op dinsdag 19 juni 2012 schreef Marco Martin (notmart at gmail.com) het
volgende:

> On Tuesday 19 June 2012, Mark wrote:
> > Hi,
> >
> > Today was quite an interesting day with QML tooltips. One issue after
> > the other popped up.
>
> but it's *very* useful that you made those issues pop up, don't see it as
> wasted time ;)

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.

>
> > What i have right now are working tooltips in a very rough shape. The
> > icon provided is also being shown in the tooltip and overall it looks
> > somewhat decent to continue to the next step. That would be to make
> > Dolphin and System Settings usable with these tooltips.
> >
> > Sadly, while improving it further, i've hit a blocking issue that i
> > can't fix. The following issues arose of which the 2nd one is blocking
> > me right now.
> > 1. Somehow when moving the cursor from an item that shows a tooltip
> > (like the tasks) to another item that shows a bigger tooltip (like the
> > pager) the result is a messed up layout: http://ompldr.org/vZWUyNw
>
> having seen a bit of the code, i think there is still the possibility that
> is
> the tooltip mainitem having the wrong size (otherwise would be clipped
> only at
> bottom)
> would need some debug to say what is the size of mainitem and what is the
> size
> of the things it contains

Could you....?

>
> > This doesn't happen if i directly hover over the pager icon for the
> > tooltip. I haven't found a cause for this. (note, the position itself
> > is OK here, but done manually which is wrong)
> > 2. Tooltips positioned using popupPosition are positioned directly
> > above the item where they need to be positioned:
> > http://ompldr.org/vZWUyNg This is the way it's currently designed and
> > Marco doesn't want to break the design in the KDE 4.x series. This is
> > something he will look into for KF5.
>
> this doesn't depend from the position, that is correct.
> depends from the fact that Dialog doesn't paint the borders that are near
> to
> the screen edge or to a panel.
>
> now, this is ok for the use case of popups, because a) they are designed as
> objects that come out from the panel, b) when is attached to the screen
> edge
> it will accept input from the mouse until the very border (fitts law)
>
> > 3. The height of the tooltips cannot be animated because height (and
> > width) are read-only. Furthermore, since it's a window, it's likely to
> > be slow as well due to X11 resizing stuff.
>
> yeah, i don't much see solutions to this one on x11 (waylaaand;).
> iirc there was a kwin plugin in the works that tried to fake a smooth
> resize
> of windows with a transition of their pixmaps? is that thing still alive?
>
> in brief, is not pretty, bit don't worry about size animation for now

 As said, i'm oke with this limitation.

>
> > 4. added to this is my dislike against PlasmaCore.Dialog. I simply
> > don't like it but gave it my best try to use it.
> >
> > The first one is something i can work around. Third is also something
> > i can live with, but combined with the issues i had before and along
> > with my dislike for PlasmaCore.Dialog and the fundamental design
> > change that needs to happen to make it usable for tooltips makes me
> > think that i should perhaps do things a bit differently.
>
> It's done for popups, and in order for popups to be consistent, freedom to
> do
> whatever with it must be sacrified
>
> > Marco also suggested that i copy the current PlasmaCore.Dialog C++
> > side and adjust it for the tooltip needs. That's the part where i
> > really could use some help in deciding how i should go further with
> > this. The side effects are not really what i'd like to see. If i
> > follow this approach it means that the (to be made) libTooltip (which
> > was supposed to be as clean as possible with as little dependencies as
> > possible) is suddenly going to link against Plasma. Which was the
> > exact reason why it should be split in it's own library to prevent a
> > plasma dependency! Note that any application using the lib will need
> > plasma, but if i could have used PlasmaCore.Dialog it would be a
> > runtime dependency. Now it looks like it's going to be a compile time
> > dependency as well which kinda beats the purpose of making a library
> > out of it.
>
> I'm still not sold about moving tooltips outside libplasma. If this is so,
> using a different qml file that doesn't import plasma when an app is not
> ran
> in kde wouldn't be hard tough.
> if it's outside libplasma also means quite a lot of code to be duplicated,
> tooltipmanager, tooltipdata, tooltip and pieces of corona such as
> popupposition (eh, there is really no way around every single corner case
> that
> function takes care has to be managed) at that point plasma2 could use that
> library and not provide a tooltip anymore, that's also an option.

The idea was to move all tooltip stuff from plasma to it's own library.
Including the things you mention here.

>
> It also means the tooltip won't use corona but a private scene. I always
> tried
> to limit the proliferation of private qgraphicsscenes, but looks like in
> qml2
> won't matter anymore since there is 1:1 correspondence scene/view.
>
> in the end the easiest solution would be taking the current ToolTip private
> class, showel a QDeclarativeView in it as the main layout element and be
> done.

I'm already doing that! Now i just make a dialog in qml and move it around.

>
> the reasons why Dialog is at the moment suitable are mainly two:
> * it removes the borders when it goes at the edge of the screen
> * it uses dialogs/background.svgz instead of widgets/tooltip.svgz for its
> background
>
> i would really rather not add api to control those two things, given
> kdelibs
> is frozen and i don't think would be a good approach anyways.
>
> > So these are the options i currently see:
> >
> > - Abandon PlasmaCore.Dialog, copy the C++ side behind it and fix it
> > according to my needs. This also means that i will have a custom QML
> > import where that new component will be living. Added dependency of
> > plasma.
>
> no, it doesn't have to be an import there are several other ways to do it,
> that in this case are more suitable.
>
> a class name that will instantiate a c++ object can be registered from the
> c++
> part with qmlRegisterType
> or in this case even better, the whole qgraphicsview would be instantiated
> from the c++ part in the tooltipmanager itself (would be what is the
> ToolTip
> private class nowdays) so the qml would only manage the layout and won't
> know
> about the window at all (if in the end is decided to do an independent
> thing
> where is not an issue to have its own private scene it may even be a
> qdeclarativeview).
> this is imo the best option.

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:
- it's going to be inside of plasma
- adding a private dialog class that either inherits plasma::dialog or the
dialog from marco
- sending that one to qml either by import or by registering it's type
whichever one works the easiest

How does that sound? Though i'm guessing it is going to be for KF5 if i
keep it in plasma -_-

>
> Cheers,
> Marco Martin
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel at kde.org <javascript:;>
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20120619/ea022b1e/attachment.html>