(references to gnome-shell commits/merge-requsts)
22b6a09c (!815 (merged)) removed WindowManager._removeEffect, but didn't remove
all its uses as it was made on top of b6d47c18. So when cherry picked some code
paths in 3.34 still relied on _removeEffect.
Simply monkey patch around the problem...
When using `workspaces-only-on-primary` it's possible to trigger insertWindow
from `window-added` instead of `window-created`, leaving insertWindow thinking
the window is `existing`.
Simply use `metaWindow.unmapped` to figure out if a window is newly created or
not.
If a user updates the extension without restarting gnome-shell we risk
re-reading the updated schema file without using the updated code (typically
after locking the screen (disable/enable cycle))
related-to: #190
It's possible to pick up schema changes without a full reload. If the new
bindings conflicts with gnome-shell we will try to override. But since we have
registered no action, this will fail.
Simply guard against actionless bindings.
fixes#190
3.34 changed introduced changes to the layout algorithm breaking our simple
ordering monkey patch.
Simply take computeLayout from 3.32 and monkeypatch it back in.
When dragging a window to a shared secondary monitor, moveDone is blocked by
`inGrab`. However we only want this as long as the window haven't been detached
by window-entered-monitor.
Use `tilix --working-directory %d` for tilix. Otherwise the daemon will have the
workspace dir as working directory. Subsequent new windows might inherit that
directory. (eg. in spaces that doesn't specify an explicit directory(?))
We override these methods so this will work from the typical launchers:
Shell.App.open_new_window
Shell.App.launch_action('new-window', ...)
Gio.DesktopAppInfo.launch
Gio.DesktopAppInfo.launch_action('new-window', ...)
NOTE: overridden `launch` can act somewhat strange with single process many
window apps if the process. If the process is launched with a specific directory
new windows might inherit this on non-overridden `new-window`. (seen in Tilix)
When spawning windows on a secondary monitor, and there's
workspaces-only-on-primary, we simply want to connect the necessary signals and
make sure the window is shown.
When using `workspaces-only-primary` and a scratch window is moved from a
secondary monitor to the primary gnome-shell will make the window unstuck. So we
need to make it stuck again.
Tor Hedin Brønner