Bug 388583

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.