Schneegans/Burn-My-Windows

Broken activities overview in GS 3.36

G-dH opened this issue · 7 comments

G-dH commented

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
Schneegans commented

Thanks for the report! I'll look into this later today.

Schneegans commented

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!

G-dH commented

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.

Schneegans commented

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

Schneegans commented

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.

G-dH commented

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.

G-dH commented

feature/fix-14 seems to be working flawlessly on my system :)