Bug 461193 - Tooltip remains on the screen after changing focus to another app
Summary: Tooltip remains on the screen after changing focus to another app
Alias: None
Product: filelight
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Neon Linux
: NOR minor
Target Milestone: ---
Assignee: Unassigned bugs mailing-list
: 463205 464114 465504 (view as bug list)
Depends on:
Reported: 2022-10-30 10:12 UTC by Patrick Silva
Modified: 2023-02-09 13:48 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In: 23.04

screenshot (48.35 KB, image/png)
2022-10-30 10:12 UTC, Patrick Silva

Note You need to log in before you can comment on or make changes to this bug.
Description Patrick Silva 2022-10-30 10:12:59 UTC
Created attachment 153318 [details]

1. scan Home with Filelight
2. hover over a folder
3. alt+tab to another app while the tooltip is visible

as we can see in the attached screenshot, the tooltip remains on the screen

the tooltip should only be visible while Filelight is focused

Operating System: KDE neon Unstable Edition
KDE Plasma Version: 5.26.80
KDE Frameworks Version: 5.100.0
Qt Version: 5.15.6
Graphics Platform: Wayland
Comment 1 Bug Janitor Service 2022-11-21 13:59:53 UTC
A possibly relevant merge request was started @ https://invent.kde.org/utilities/filelight/-/merge_requests/61
Comment 2 Harald Sitter 2022-11-24 10:37:43 UTC
Git commit e06fcc2eb04c7d3b70a4cebaef6aa23b89ad0677 by Harald Sitter.
Committed on 24/11/2022 at 10:35.
Pushed by sitter into branch 'master'.

port painting to qml & add list view

this brings more of the UI into the qml world, this time the rendering
of the filelight map. it is implemented using qtquick shapes of stacking
circles. this also introduces a listview to more reasonably glance,
navigate and manage files inside the current scope (as opposed to the
previous labeling approach inside the map). to ease discoverability the
hover states between map and list are somewhat linked so it becomes
easier to spot which segment is where in the list, and vice versa.

to facilitate all this a huge amount of reshuffling happened:

- item.cpp no longer exists, its functionality moved into either qml or
the map.cpp
- new classes dropperitem (to receive drop events from qml)
contextmenucontext (to implement the c++ side of context menu actions)
filemodel (to model the file objects for the listview)
- File is no longer a QObject, this has been moved up one level in the
architecutre -> Segment now is a QObject and delegates most of the UI
relevant functions from File
- Files are now "linked" to their segment through a uuid string. this
allows the UI code to establish a relationship between entities in the
listview and the mapview. this is intentionally not pointer based to
avoid clashes, confusion, and to prevent the Files from contributing to
the lifetime of Segments (and thus complicate the entire shebang)
- various settings have been retired as they are no longer applicable:
AA is now always on, there is no practical reason why the user would
disable it in 2022, font size (now following system defaults and
sometimes able to scale down if not enough space)
Related: bug 458181, bug 444057, bug 434146

M  +3    -1    src/CMakeLists.txt
M  +0    -8    src/Config.cpp
M  +0    -3    src/Config.h
A  +105  -0    src/contextMenuContext.cpp     [License: GPL(3+eV) GPL(v3.0) GPL(v2.0)]
A  +50   -0    src/contextMenuContext.h     [License: GPL(3+eV) GPL(v3.0) GPL(v2.0)]
M  +0    -82   src/dialog.ui
A  +36   -0    src/dropperItem.cpp     [License: GPL(3+eV) GPL(v3.0) GPL(v2.0)]
A  +25   -0    src/dropperItem.h     [License: GPL(3+eV) GPL(v3.0) GPL(v2.0)]
A  +87   -0    src/fileModel.cpp     [License: GPL(3+eV) GPL(v3.0) GPL(v2.0)]
A  +42   -0    src/fileModel.h     [License: GPL(3+eV) GPL(v3.0) GPL(v2.0)]
M  +19   -1    src/fileTree.h
M  +3    -0    src/main.cpp
M  +34   -12   src/mainContext.cpp
M  +0    -1    src/mainContext.h
A  +76   -0    src/qml/CenterShape.qml     [License: GPL(3+eV) GPL(v3.0) GPL(v2.0)]
M  +400  -37   src/qml/MapPage.qml
A  +76   -0    src/qml/SegmentShape.qml     [License: GPL(3+eV) GPL(v3.0) GPL(v2.0)]
M  +7    -8    src/qml/main.qml
M  +2    -0    src/qml/qml.qrc
D  +0    -876  src/radialMap/item.cpp
D  +0    -111  src/radialMap/item.h
D  +0    -51   src/radialMap/labels.h
M  +97   -150  src/radialMap/map.cpp
M  +76   -19   src/radialMap/map.h
M  +20   -0    src/radialMap/radialMap.cpp
M  +72   -16   src/radialMap/radialMap.h
M  +1    -27   src/settingsDialog.cpp
M  +0    -3    src/settingsDialog.h

Comment 3 Patrick Silva 2022-12-19 12:32:40 UTC
*** Bug 463205 has been marked as a duplicate of this bug. ***
Comment 4 Patrick Silva 2023-01-11 02:50:04 UTC
*** Bug 464114 has been marked as a duplicate of this bug. ***
Comment 5 1jasotel+kde 2023-01-27 11:37:50 UTC
Sorry, I don't think this is fixed. I wanted to add that I'm also having this issue. I'm using an updated (27th Jan. 2023) KDE Neon with X11. 

I constantly alternate between Firefox and Konsole and the problem is 100% reproducible as described by the OP. Furthermore, I also observed that is has something to do with the "mouse focus". If the windows are side by side, I can:
 - In Firefox, hover over an item with tooltip to let it pop out
 - alt-tab to Konsole
 - the tooltip remains indefinitely
 - if I move the mouse (not giving focus back to firefox, only "mouse focus"), the tooltip disappears

If the windows are over each other, even with different geometry/size, as long as the Firefox tooltip position remains inside the Konsole area, the tooltip remains. 

To remove the tooltip I always need to momentarily move the mouse over the Firefox window. Don't need to give it the focus, just move the mouse over it.
Comment 6 Nate Graham 2023-01-27 16:23:32 UTC
It's supposed to be fixed with the 23.04 version, which hasn't been released yet.
Comment 7 Patrick Silva 2023-02-09 13:48:22 UTC
*** Bug 465504 has been marked as a duplicate of this bug. ***