On Tuesday 19 June 2012, Mark wrote: > Op dinsdag 19 juni 2012 schreef Marco Martin (notm...@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.
this may be valid, (and this way would be easy to do it before kf5) i would like some other opinions about it > > 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. well, that's quite mutually exclusive to using PlasmaCore.Dialog in this case it would be a normal Item (no Dialog involved here), and everything window related would be managed by tooltipmanager. that would also be the least delta with the current implementation. > > 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: i don't think implementation details influence where it should be in the end, is almost about extracting pieces and moving them around in the end. Cheers, Marco Martin _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
