In general: NPE in stackoverlay when target window is non-`TabList.NORMAL`
crashes `insertWindow` midway. (eg. size-changed signal never connected).
A `TabList.NORMAL` window is focusable and doesn't `mw.skip_taskbar`.
Example: The main window of pycharm on startup is (sometimes) non-normal(!).
Focusing the window fail so it's likely to become the stackoverlay target.
(java applications is a WM's worst nightmare..)
Seem the ordering of "focus", "window-created", "window-added" and "first-frame"
and the corresponding update of eg. global.display.focus_window and the mru list
is quite complicated and non-deterministic..
Some sampling reveals the following possible combinations on 3.28 X11:
fw = global.display.focus_window, mw = metaWindow in insertWindow (new window)
fw = mw mw = mru0 !fw fw = mru0 fw = mru1
false false false false false
false false false true false
false true false false true
false true true false false
true false false false true
true true false true false
So it's quite messy, but we can (hopefully) always rely on the currently
focused ("adult") window to be in the mru.
Note: the reason we doesn't simply use `maximize(Meta.MaximizeFlags.HORIZONTALLY`
for toggle-maximize-width is that maximized windows are unmovable [1] and (more
debatable) that maximized width should honor minimumMargin.
[1] doesn't play to well with paperwm, though we have some hacks in place for
regular maximized windwos
Ref: #157
Windows sometimes was registered (`registerWindow`) twice on startup (observed
on X11 3.28) causing all sorts of problems.
Seems like the extension sometimes is enabled/disabled twice on startup causing
the 'startup-complete' signal to be connected twice. Use the `Signals` class to
manage the signal to guard against this scenario.
I added a one-shot function to `Signals` since it's an error to disconnect an
already disconnected signal and that would happen on disable if the
'startup-complete' signal disconnected the signal itself.
assoc: d8069078f2
Partly motivated to prevent resizing to enormous sizes if the steps contains
mixed ratios and pixel counts: [0.3, 300] would interpret 300 as a ratio :)
On multi monitor setups we usually want the monitor focus to follow the mouse
pointer since non-active workspaces don't react to the pointer at all.
Unfortunately it's not possible to warp the pointer from gnome-shell extensions
in wayland yet. The pointer will be left on an inactive monitor when switching
workspaces using the keyboard. This makes it extremely easy to trigger an motion
event and inadvertently switching monitor focus (in fact this simply happens the
moment we activate the motion listener).
So add a motion threshold to filter out pointer motions without user intent.
A colored border is added to frame the space when using the workspace carousel.
This helps to separate the workspaces visually. Especially when using a
shared image background for workspaces and the gnome shell background.
We also make the background the same size as the monitor making the overview
transition smooth when using a single background.
During regular use the border is hidden, to avoid shadows at the edges of the
monitor.
closes#86
The 'workspace-names' values might still come out of sync when a in-the-middle
workspace is removed - but:
- This is not very visible since each space have a "copy" of it's real name
- The code have been dead for a long time
- Better to handle everything in `workspacesChanged`
The best solution is probably to reindex the existing spaces' settings on
workspace removal and then set 'workspace-names' based on the live-spaces.
When running a disable/enable loop (eg. through screen locking) space.init() was
run before windows were registered (ie. gotten their clones etc.).
We also need to set up the monitors unconditionally before space.init() is run.
This is a bit ugly but should work until we can clean it up better.
closes#128
If we've run out of workspaces when there's more monitors to populate simply add
new ones.
NB: this only works after startup-complete as we need to listen to
`notify::n-workspaces` first.
closes#116
Workspaces created after startup was never actually initialized, eg.
the `window-added/removed` signals were never connected.
Simply run space.init when constructing a space and handle the _startingUp edge
case.
dconf can't reliable get default values(?)
According to https://bugzilla.redhat.com/show_bug.cgi?id=1541448 the dconf
default value might also differ from the gsettings default value(?)
I did not find a way to differentiate between "use default value" and the actual
default value - so running the script might change some settings from "use
default value" to the actual default value.
IIUC 'gsettings' require the gsettings daemon to run, while 'dconf' is lower
level and modify the database directly.
Fixes#121
Tor Hedin Brønner