Created attachment 109697 [details] tooltip obstructs other files Propably since this (352276) bug fix the tooltip obstructs other files when its displayed above the selected/hovered file (see screenshot). This is an usability issue because one has to move out of the selection/hover highlight area to dismiss it. In Icon view mode it's even worse the cursor has to leave the file area completely. In all: tooltip placement is quite inconsistent. Mostly they're good. But sometimes they appear partially on the lower edge of the screen, sometimes partially on the left edge, sometimes not at all (my guess: completely off-screen). Additional info: The links in the screenshot point to a samba share. Because that's a little slow I could observe that the info in the tooltip is displayed in 2 stages. Standard properties (type, modified) first and shortly after that the info that has to be extracted from the video. The tooltip size adjusts to that but not its position.
Thanks for the bug report, Michael. Are you interested in producing a patch? ;-)
Git commit e9049626222c1b0d90c8e714c71440c9a7bc0e58 by Michael Heidelbach. Committed on 27/01/2018 at 14:45. Pushed by michelh into branch 'master'. baloo-widgets: Apply coding style to filemetadataprovider Summary: Prepare fixing bug 388583 Test Plan: Visual inspection make test Reviewers: elvisangelaccio, smithjd, ngraham, vhanda, #dolphin Reviewed By: elvisangelaccio Differential Revision: https://phabricator.kde.org/D10143 M +51 -46 src/filemetadataprovider.cpp https://commits.kde.org/baloo-widgets/e9049626222c1b0d90c8e714c71440c9a7bc0e58
Git commit a81ceaeaa963f233a79ef6e1bcc31b304a173939 by Michael Heidelbach. Committed on 29/01/2018 at 14:46. Pushed by michelh into branch 'master'. baloo-widgets: Refactor filemetadataprovider for better readability Summary: Prepare fixing bug 388583 Make signal emission more obvious Make it easier to distinguish synchronous and asynchronous parts Test Plan: Visual inspection Make test Reviewers: elvisangelaccio, ngraham, vhanda, smithjd, #dolphin, #frameworks Reviewed By: elvisangelaccio Differential Revision: https://phabricator.kde.org/D10105 M +171 -142 src/filemetadataprovider.cpp M +21 -2 src/filemetadataprovider.h https://commits.kde.org/baloo-widgets/a81ceaeaa963f233a79ef6e1bcc31b304a173939
Git commit 5e4203cd323a8c60526445e162e55880603e2126 by Michael Heidelbach. Committed on 08/02/2018 at 06:49. Pushed by michelh into branch 'master'. baloo-widgets: Emit metaDataRequestFinished once per request Summary: Add signal 'dataAvailable' to allow chunkwise data processing Emit metaDataRequestFinished when request processing is finished Adapted execution order to ensure loadingFinished is signalled last Test Plan: Visual inspection make test Reviewers: elvisangelaccio, smithjd, vhanda, ngraham, #dolphin, #frameworks Reviewed By: elvisangelaccio, ngraham, #dolphin Subscribers: dhaumann Differential Revision: https://phabricator.kde.org/D10113 M +10 -9 src/filemetadataprovider.cpp M +7 -5 src/filemetadataprovider.h M +9 -1 src/filemetadatawidget.cpp M +1 -0 src/filemetadatawidget.h https://commits.kde.org/baloo-widgets/5e4203cd323a8c60526445e162e55880603e2126
Created attachment 111223 [details] Video of the tooltip not disappearing In my case, the behavior of the tooltip is a little bit weirder. If I move the mouse pointer from one file to the other at a slow speed, if fades and the new tooltip appears, which to me is the desired behavior. However, if I move the pointer a little bit faster, most of the times the original tooltip persists, and doesn't let me go on to preview the other files until I move the pointer out of the tooltip itself. In the attached video you can see the following: 1) I hover over the files slowly, and the tooltip changes. That's OK. 2) I go back to the first file and move the pointer downward quickly, but the bug doesn't appear. That's OK too. 3) I repeat point 2, but this time the bug does appear: the tooltip remains there and covers what's under it, until I move the pointer away. That's not OK, the way I see it. I have no idea what changed between my 2nd and 3rd attempts. I don't think I moved the pointer faster in attempt 3. Moreover, this bug appears to me constantly as I work, thus moving the pointer at my normal speed, which isn't very fast.
(In reply to David de Cos from comment #5) What you're describing is actually intended behaviour. It shall allow the user to reach the links within the tooltip. If you consider this to be an usability issue, please file a separate bug.
Oh, I hadn't realized that's the intended behavior. I guess it makes sense to allow the mouse pointer to interact with the tooltip contents, but only if it doesn't block the view of other files, which is what Michael reported originally in this bug. Otherwise, it just gets in the way when you want to hover over several files quickly. Therefore, if that gets fixed, my problem disappears. Thanks!
Git commit f94c55fb190f2614aa0c5b10828df3a59f0c0779 by Michael Heidelbach. Committed on 11/03/2018 at 09:43. Pushed by michelh into branch 'master'. ktooltipwidget: Fix tooltip positioning Summary: Partially fix [[ https://bugs.kde.org/show_bug.cgi?id=388583 | Bug 388583 ]] Display tooltip at correct position in dolphin when - Tooltip is displayed above file item, or - Content width exceeds screen width Test Plan: Visual inspection specially for equal distance to file item (3px) Patch applied: {F5662669} Currently partial display: {F5662680} Patch applied: {F5662688} Currently invisible tooltip (displayed off-screen). Patch applied: {F5662675} Reviewers: elvisangelaccio, ngraham Reviewed By: elvisangelaccio Subscribers: #frameworks, dfaure, cfeck Tags: #frameworks Differential Revision: https://phabricator.kde.org/D9973 M +131 -3 autotests/ktooltipwidgettest.cpp M +10 -0 autotests/ktooltipwidgettest.h M +5 -5 src/ktooltipwidget.cpp https://commits.kde.org/kwidgetsaddons/f94c55fb190f2614aa0c5b10828df3a59f0c0779
Do all of those commits fully resolve this issue, or is there still more to do?
(In reply to Nate Graham from comment #9) > Do all of those commits fully resolve this issue, or is there still more to > do? About half way there.
Wanted to ask how this is going. For me this issue makes dolphin under wayland completely unusable. After dolphin startup tooltip ALWAYS pops up in the top left corner of the dolphin window. After clicking somewhere in the icon view tooltip placement kind of works, as long as there is enough space for it to the bottom screen edge. If there is not enough space tooltip shifts up but not far enough. It looks like it simply aligns the bottom edge at the position where it would align the top edge if the tooltip would be placed below the icon. So it seems the actual item height is cmpletely ignored (or badly calculated under wayland). To make it clear: This is an issue under wayland, for me dolphin under X11 performs perfectly fine.
Is this can be simply implemented with disappearing tooltip on mouse leaving the previously selected file? If prev selected item not highlighted - tooltip dissapears in any case
(In reply to Michael Heidelbach from comment #10) > (In reply to Nate Graham from comment #9) > > Do all of those commits fully resolve this issue, or is there still more to > > do? > > About half way there. Michael, were you able to complete the second half of the patches required to fix this?
Unfortunately Michael has not been active in KDE for some time, and the issue is still present under certain circumstances.