Hi, Today was quite an interesting day with QML tooltips. One issue after the other popped up.
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 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. 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. 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. 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. 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. - Add a experimental imports folder "experimentalcomponents" where we don't promise backwards compatibility or even that the import exists in the next release. Add a ExperimentalComponents.Tooltip (or Dialog) which is tailored for tooltips and my needs and probably based on the current PlasmaCore.Dialog or directly on Plasma::Dialog. I would continue with continue with the tooltip stuff in a library that can exist without a dependency on plasma. Which option is the way to go? I prefer the "experimentalcomponents" way. Or is there another (easier) way that i haven't even considered yet? Your input would be very helpful. Cheers, Mark _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
