Broken activities overview in GS 3.36
G-dH opened this issue · 7 comments
Describe the Bug
All in activities overview:
- after you DND a window clone to another workspace, the clone isn't removed from the original workspace.
- after closing a window, the burn animation is performed, but the clone is not completely removed from the workspace overview, remaining window clones won't rearrange.
JS ERROR: TypeError: actor is undefined
_shouldDestroy@/home/user/.local/share/gnome-shell/extensions/burn-my-windows@schneegans.github.com/extension.js:204:33
- switching to another workspace and back after closing a window will cause this error:
Object .Gjs_ui_workspace_WindowClone (0x557192ec8e40), has been already deallocated — impossible to access it. This might be caused by the object having been destroyed from C code using something such as destroy(), dispose(), or remove() vfuncs.
== Stack trace for context 0x557191efe940 ==
#0 7ffde0259170 b resource:///org/gnome/shell/ui/workspace.js:1398 (1ddc2da82268 @ 1925)
#1 5571929d8418 i resource:///org/gnome/shell/ui/workspace.js:1246 (1ddc2da80d30 @ 213)
== Stack trace for context 0x557191efe940 ==
...
System
- Ubuntu 20.04 / X11
- Burn-My-Windows version 4
- GNOME Shell version: 36.6.9
Thanks for the report! I'll look into this later today.
I tried my best but I did not find a way to hack-in window-close animations in GNOME Shell 3.36's overview. Meta.Windows
and corresponding WindowClones
seem to be destroyed the other way around when compared to later versions. This makes this very hard or even impossible (see this comment).
Therefore, I have chosen to disable overview animations for GNOME Shell 3.36 with the latest commit to main
. If anybody finds a hack to get this running, I am happily receiving pull requests!
I'd say that removing the window clone from the workspace and increasing WINDOW_REPOSITIONING_DELAY constant to cover the animation time would be enough.
Sadly, it does not seem to be enough. WINDOW_REPOSITIONING_DELAY
is set to 750ms per default; setting the window-close animation time to 500ms does not solve the issue.
It's quite difficult to trace the code flow for me. One difference seems to be that Workspace._doRemoveWindow
is called after the clone is destroyed on GNOME 3.38 and beyond but not on GNOME 3.36. This is due to respective handlers of the clone's destroy
signal (3.36, main). In main
, this ensures that the repositioning is triggered after the clone is destroyed. So this could be fixed by increasing WINDOW_REPOSITIONING_DELAY
as you suggested, or maybe by calling Workspace._doRemoveWindow
in an additional destroy
handler.
The main issue seems to be that Workspace._removeWindowClone
cannot remove the clone as the corresponding Meta.Window
does not exist anymore. I think that the clone does not get removed after the animation by this method as it cannot find the index. However, we could search for the clone if we had the actor itself and not the metaWindow... I'll give it a last attempt :D
Calling Workspace._doRemoveWindow
on the clone's destroy
signal, seems to do the trick! If you want to, you can try the branch feature/fix-14
.
OK, I'll test it.
Btw, I meant (and tested) to call _removeWindowClone()
instead of doing nothing in the _windowRemoved()
function, and because the repositioning timeout is then started immediately, I set the WINDOW_REPOSITIONING_DELAY to destroy-animation-time
to avoid repositioning during the animation.
feature/fix-14
seems to be working flawlessly on my system :)