Summary: | GIMP and Pidgin windows do not appear in Task Manager on Wayland | ||
---|---|---|---|
Product: | [Plasma] kwin | Reporter: | Nate Graham <nate> |
Component: | wayland-generic | Assignee: | Eike Hein <hein> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | abin.gecb, dennis.lissov, dev+kde, kde, kde, meven29, mgresko8, mysignup27, nicolas.fella, notmart, plasma-bugs, postix, qydwhotmail, rickyteja21071995, spamulousbastard+kde, torokati44, torotil |
Priority: | NOR | Keywords: | wayland |
Version: | 5.23.0 | ||
Target Milestone: | --- | ||
Platform: | Other | ||
OS: | Linux | ||
Latest Commit: | https://invent.kde.org/plasma/kwin/commit/bf84d8ba1934123ef9b17ae263b852e870172383 | Version Fixed In: | 5.25.5 |
Sentry Crash Report: | |||
Attachments: | How to trigger this |
Description
Nate Graham
2021-10-24 13:45:26 UTC
It appears in the Task Manager on X11. I don't reproduce this in neon master in my VM. When launching from kickoff, the gimp icon is visible during the loading window, then disappears and reappears as the main window appears. Except the icon is greyed without colors. plasma-system-monitor list gimps is in the applications tab. When launching from command-line, the same but the same except the icon is correct. But plasma-system-monitor does not list gimp in the applications although it is visible in the process list with its icon. It would be excepted though, I guess. I am not sure gimp was in Wayland mode though. Was it with Plasma 5.23.1 or master ? This was with it git master, using GIMP 2.10.24 in XWayland mode, launched using Kickoff or KRunner. It does appear in System Monitor's Applications page when launched like this. Like you, I see the icon while it's launching. But then for me it disappears and fails to re-appear when the main window opens. I can reproduce that launching gimp from the command line causes the icon to appear in the Task Manager as expected. How odd. I ran plasmashell with wayland_debug and we're not getting a second window announced Plasma window management. This implies it is a kwin bug somewhere perhaps also depends from the gimpo version, as here (with neon) i get the taskbar entry for gimp just fine. can you also run xprop from the terminal and click on the gimp window which doesn't show up on the task manger? (and paste output here) _NET_WM_USER_TIME(CARDINAL) = 258851960 _NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_MOVE, _NET_WM_ACTION_RESIZE, _NET_WM_ACTION_MINIMIZE, _NET_WM_ACTION_SHADE, _NET_WM_ACTION_MAXIMIZE_VERT, _NET_WM_ACTION_MAXIMIZE_HORZ, _NET_WM_ACTION_FULLSCREEN, _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_CLOSE _KDE_NET_WM_FRAME_STRUT(CARDINAL) = 0, 0, 31, 0 _NET_FRAME_EXTENTS(CARDINAL) = 0, 0, 31, 0 _NET_WM_DESKTOP(CARDINAL) = 0 _KDE_NET_WM_ACTIVITIES(STRING) = "3e5e7e2a-2b45-4c46-8398-5a39967694cf" WM_STATE(WM_STATE): window state: Normal icon window: 0x0 _NET_WM_STATE(ATOM) = _NET_WM_STATE_MAXIMIZED_VERT, _NET_WM_STATE_MAXIMIZED_HORZ, _NET_WM_STATE_FOCUSED WM_HINTS(WM_HINTS): Client accepts input or input focus: True Initial state is Normal State. bitmap id # to use for icon: 0x2601468 bitmap id # of mask for icon: 0x2601469 window id # of group leader: 0x2600001 XdndAware(ATOM) = BITMAP _MOTIF_DRAG_RECEIVER_INFO(_MOTIF_DRAG_RECEIVER_INFO) = 0x6c, 0x0, 0x5, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x10, 0x0, 0x0, 0x0 _KDE_NET_WM_USER_CREATION_TIME(CARDINAL) = 258850622 _NET_WM_ICON(CARDINAL) = Icon (48 x 48): ░ ░ ░░ ▒▒ ░ ░▒▒ ▒ ░▒▒▒ ▒▒ ▒▒▒▒ ▒▒▒ ░▒▒▒▒▒ ▒▒▒▒ ▒▒▒▒▒▒▒ ▒▒▒▒▒▒ ░▒▒▒▒▒▒▒▒ ▒▒▒▒▒▒▒▒░░ ░░▒▒▒▒▒▒▒▒▒▒▒ ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░░▒▒▒▒▒▒▒▒▒▒▒▒ ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ ▒▒▒▒▒▒▒▒▒▒ ▒▒▒▒▒░ ░▒▒▒▒▒▒ ▒▒▒▒▒▒▒▒▒ ░▒▒▒▒ ▒▒▒▒░ ░░ ▒▒▒▒▒▒▒▒ ░▒▒▒░ ░ ░▒▒▒ ▒▒▒▒ ▒▒▒▒▒▒▒▒ ░▒▒▒░ ▒▒▒▒ ▒▒▒ ▒▒▒ ▒▒▒▒ ▒▒▒▒▒▒▒▒ ▒▒▒▒▒▒▒░ ▒▒▒▒ ▒▒▒ ▒▒▒ ▒▒▒▒ ▒▒▒▒▒▒▒░ ░▒▒▒▒▒▒▒▒▒ ░▒▒▒▒ ░▒░ ▒▒▒ ▒▒░ ▒▒▒▒▒▒▒░ ▒▒▒▒▒▒▒▒▒▒░ ▒▒▒▒▒░ ░▒▒▒░ ░▒▒▒▒▒▒▒░ ▒▒▒▒▒▒▒▒▒▒▒ ▒▒▒▒▒▒ ▒▒▒▒▒░ ░▒▒▒▒▒▒▒▒░ ▒▒▒▒▒▒▒▒▒▒▒░▒▒▒▒▒▒▒▒░ ░▒▒▒▒▒▒▒▒ ░▒▒▒▒▒▒▒▒▒ ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ ▒▒▒▒▒▒▒▒▒▒▒░ ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ ░▒▒▒▒▒▒▒▒▒ ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░ ▒▒▒▒▒▒▒▒▒ ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░ ▒▒▒▒▒▒▒░ ░▒▒▒▒▒▒▒▒▒░▒▒▒▒▒▒▒▒▒▒▒▒░ ▒▒▒▒▒▒▒ ░▒▒▒▒▒▒▒▒▒ ░░▒▒▒▒▒▒░ ▒░▒▒▒▒▒▒░ ▒▒▒▒▒▒▒▒▒░ ▒▒▒▒▒▒▒▒ ░▒▒▒▒▒▒▒▒▒░ ▒▒ ░▒▒▒▒▒ ▒▒▒▒▒▒▒▒▒▒░ ░▒▒░ ▒▒▒ ▒▒▒▒▒▒▒▒▒▒▒▒▒ ░▒▒▒ ▒▒▒▒▒▒▒▒▒▒▒▒ ░▒▒▒ ░▒▒▒▒▒▒▒▒▒▒ ▒▒▒▒░ ░░▒▒▒▒▒▒░ ▒▒▒▒░ ░▒▒▒▒▒▒ ░▒▒▒▒▒▒░ ▒▒▒▒▒▒▒ ▒▒▒▒▒▒▒▒ ░▒▒▒▒▒▒▒ ░▒▒▒▒▒▒░ ░▒▒▒ ▒ WM_WINDOW_ROLE(STRING) = "gimp-image-window-1" _NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 39851094 _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL _NET_WM_USER_TIME_WINDOW(WINDOW): window id # 0x2601455 WM_CLIENT_LEADER(WINDOW): window id # 0x2600001 _NET_WM_PID(CARDINAL) = 728854 WM_LOCALE_NAME(STRING) = "en_US.UTF-8" WM_CLIENT_MACHINE(STRING) = "Liberator" WM_NORMAL_HINTS(WM_SIZE_HINTS): user specified location: 316738672, 22045 program specified minimum size: 591 by 724 window gravity: NorthWest WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST WM_CLASS(STRING) = "gimp-2.10", "Gimp-2.10" WM_ICON_NAME(STRING) = "GNU Image Manipulation Program" _NET_WM_ICON_NAME(UTF8_STRING) = "GNU Image Manipulation Program" WM_NAME(STRING) = "GNU Image Manipulation Program" _NET_WM_NAME(UTF8_STRING) = "GNU Image Manipulation Program" Upgraded to Fedora 35 which has GIMP 2.10.28, and now it's not happening anymore. Musta been an issue in GIMP itself. *** Bug 448960 has been marked as a duplicate of this bug. *** I can reproduce this with current Plasma master and GIMP 2.10.30 I confirm I can also reproduce with latest Fedora 35 updates. This is not true only for gimp but also for xsane. The issue seems to be somewhat non-deterministic. Sometimes it happens and sometimes it doesn't *** Bug 451055 has been marked as a duplicate of this bug. *** FWIW, I can _not_ reproduce it on openSUSE TW with Plasma 5.24.4 Wayland using GIMP 2.10.30. I am seeing very similar symptoms with gVim also, version 8.2 on Fedora 35. On my machine, it doesn't disappear from the taskbar immediately, but often after some number of hours, I find that it's gone missing. I don't know what condition triggers it. I have saved xprop output from two currently running gVim instances that aren't bugged. If either of them becomes affected before I close them, I will comment again with the diff. As the other comments say, GIMP seems to disappear immediately after the splash screen exits. https://invent.kde.org/plasma/plasma-workspace/-/blob/master/libtaskmanager/taskmanagerrulesrc Maybe this file needs an update? I can reproduce this bug in Fedore 35 with KDE 5.24.4 and frameworks 5.91.0 (In reply to Fushan Wen from comment #15) > https://invent.kde.org/plasma/plasma-workspace/-/blob/master/libtaskmanager/ > taskmanagerrulesrc > > Maybe this file needs an update? Quite possibly. (In reply to Fushan Wen from comment #15) > https://invent.kde.org/plasma/plasma-workspace/-/blob/master/libtaskmanager/ > taskmanagerrulesrc > > Maybe this file needs an update? It's unlikely that this is the cause. That file affects the mapping from windows to desktop files, but in this case the task manager doesn't even "see" the window in the first place. To me it looks like KWin doesn't send the info to taskmanager for some reason [3269020.528] org_kde_plasma_window_management@52.window_with_uuid(62, "{dd01c3a7-b794-497d-9d9c-4333a31abe69}") [3269020.690] -> org_kde_plasma_window_management@52.get_window_by_uuid(new id org_kde_plasma_window@72, "{dd01c3a7-b794-497d-9d9c-4333a31abe69}") [3269024.406] org_kde_plasma_window@72.virtual_desktop_entered("a4933728-ef92-4999-9de7-937520582347") [3269024.472] org_kde_plasma_window@72.app_id_changed("gimp") [3269024.503] org_kde_plasma_window@72.pid_changed(26370) [3269024.528] org_kde_plasma_window@72.title_changed("GIMP-Start") [3269024.554] org_kde_plasma_window@72.state_changed(164352) [3269024.580] org_kde_plasma_window@72.icon_changed() [3269024.617] -> org_kde_plasma_window@72.get_icon(fd 36) [3269025.338] org_kde_plasma_window@72.parent_window(nil) [3269025.391] org_kde_plasma_window@72.geometry(479, 246, 962, 551) [3269025.456] org_kde_plasma_window@72.initial_state() [3269062.285] -> org_kde_plasma_window@65.set_minimized_geometry(wl_surface@34, 150, 0, 14, 80) [3269062.448] -> org_kde_plasma_window@69.set_minimized_geometry(wl_surface@34, 150, 0, 14, 80) [3269066.103] -> org_kde_plasma_window@65.set_minimized_geometry(wl_surface@34, 150, 0, 14, 80) [3269068.129] -> org_kde_plasma_window@69.set_minimized_geometry(wl_surface@34, 150, 0, 14, 80) [3269068.254] -> org_kde_plasma_window@67.set_minimized_geometry(wl_surface@34, 150, 0, 14, 80) [3269323.519] -> org_kde_plasma_window@65.set_minimized_geometry(wl_surface@34, 150, 0, 70, 80) [3269323.572] -> org_kde_plasma_window@69.set_minimized_geometry(wl_surface@34, 150, 0, 70, 80) [3269323.591] -> org_kde_plasma_window@67.set_minimized_geometry(wl_surface@34, 150, 0, 70, 80) [3269323.636] -> org_kde_plasma_window@66.set_minimized_geometry(wl_surface@34, 220, 0, 110, 80) [3269323.684] -> org_kde_plasma_window@68.set_minimized_geometry(wl_surface@34, 0, 80, 110, 80) [3269323.730] -> org_kde_plasma_window@70.set_minimized_geometry(wl_surface@34, 110, 80, 110, 80) [3269323.777] -> org_kde_plasma_window@72.set_minimized_geometry(wl_surface@34, 220, 80, 110, 80) [3269323.915] -> org_kde_plasma_window@72.set_minimized_geometry(wl_surface@34, 220, 80, 110, 80) [3269616.619] -> org_kde_plasma_window@65.set_minimized_geometry(wl_surface@34, 150, 0, 70, 80) [3269616.685] -> org_kde_plasma_window@69.set_minimized_geometry(wl_surface@34, 150, 0, 70, 80) [3269616.705] -> org_kde_plasma_window@67.set_minimized_geometry(wl_surface@34, 150, 0, 70, 80) [3269616.761] -> org_kde_plasma_window@66.set_minimized_geometry(wl_surface@34, 220, 0, 110, 80) [3269616.818] -> org_kde_plasma_window@68.set_minimized_geometry(wl_surface@34, 0, 80, 110, 80) [3269616.866] -> org_kde_plasma_window@70.set_minimized_geometry(wl_surface@34, 110, 80, 110, 80) [3269616.914] -> org_kde_plasma_window@72.set_minimized_geometry(wl_surface@34, 220, 80, 110, 80) [3270094.002] org_kde_plasma_window@72.unmapped() [3270126.081] -> org_kde_plasma_window@72.destroy() after that nothing Hmm now I can't reproduce it anymore when I investigated it. Looking at the other comments, it's also somewhat random for others. Did anyone find something out that triggers it? I could reproduce this today (GIMP icon disappearing from Task Manager after a few seconds) on Fedora 36 KDE but I restarted the OS and it was gone and doesn't happen anymore. GIMP 2.10.30 installed using DNF | KDE Plasma 5.23.3 | KDE Frameworks 5.96.0 | Qt 5.15.5 | Kernel 5.18.13-200 |Wayland Created attachment 151040 [details]
How to trigger this
Update: I can reproduce it again by closing and launching GIMP multiple times. It's a hit-or-miss but from 11 launches, 6 of them had hidden task manager icon.
I found a trick to trigger this: launch GIMP and right after it's open you need to quickly resize the window by grabbing the _top bar using mouse_ and drag it to resize.
If it didn't work you need to close GIMP and try again.
How can I send the necessary details to debug this?
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/2801 Git commit 3934d1d0f2f3125fd7406e7be4f68c0f0d1e5520 by Vlad Zahorodnii. Committed on 09/08/2022 at 11:26. Pushed by vladz into branch 'master'. wayland: Remove surface() check in Window::setupWindowManagement() At the moment, an Xwayland window can be marked ready for painting even though the corresponding wl_surface is missing. If that happens, Window::setupWindowManagement() will fail to create a plasma window and the task manager won't display the corresponding item. As a short-term solution, remove the surface() check. It's not really needed after all. For example, if it takes too long to start an app or it doesn't show up at all, we still want to see a task manager item. In long-term, kwin probably needs to take into account both xsync and whether wl_surface has been associated, which is more complex. M +1 -4 src/window.cpp https://invent.kde.org/plasma/kwin/commit/3934d1d0f2f3125fd7406e7be4f68c0f0d1e5520 Git commit bf84d8ba1934123ef9b17ae263b852e870172383 by Vlad Zahorodnii. Committed on 09/08/2022 at 12:21. Pushed by vladz into branch 'Plasma/5.25'. wayland: Remove surface() check in Window::setupWindowManagement() At the moment, an Xwayland window can be marked ready for painting even though the corresponding wl_surface is missing. If that happens, Window::setupWindowManagement() will fail to create a plasma window and the task manager won't display the corresponding item. As a short-term solution, remove the surface() check. It's not really needed after all. For example, if it takes too long to start an app or it doesn't show up at all, we still want to see a task manager item. In long-term, kwin probably needs to take into account both xsync and whether wl_surface has been associated, which is more complex. (cherry picked from commit 3934d1d0f2f3125fd7406e7be4f68c0f0d1e5520) M +1 -4 src/window.cpp https://invent.kde.org/plasma/kwin/commit/bf84d8ba1934123ef9b17ae263b852e870172383 |