space.targetX = Math.round(clone.targetX) + ... resulted in null when
clone.targetX was undefined. This could happend on extension startup and caused
the space to be unusable.
Initialize clone.targetX and remove duplicated space.targetX initialization.
Not exposed in the preference ui yet.
Can be set with dconf or in `user.js` like this:
var settings = Extension.imports.convenience.getSettings();
settings.set_string('default-background', '/path/to/image.jpg');
ref #83
Zoom is the default option in gnome when using pictures as the background image.
This is a much better default then what we've been using.
When using color backgrounds with noise we need to use the `wallpaper` style, as
the noise isn't designed for stretching.
ref #83
Runs X11 by default, pass in -w to run a wayland session. The dbus address is
copied to clipboard, so it's easy to connect to the new sesssion from emacs
using `gnome-shell-set-dbus-address`.
Depends on Xephyr in the case of x11, and xclip is used to copy the dbus
address.
It seems that we're getting display twice as input to `grap-op-begin`.
In the gnome-shell source they're not doing this, but that might actually be a
bug.
The code here tried to serve two purposes, animating spaces above the newly
selected space and hiding spaces that would no longer be visible. Hiding
probably never worked as the loop wouldn't touch all spaces.
We split it up properly, fixing the performance bug mentioned in the parent.
While properly handling animation on its own.
Due to `to.clip` being the top actor combined with ClutterActor.get_next_sibling
returning null for top actors. (ie. it doesn't wrap)
Iterate to the spaces instead of using get_previous_sibling to avoid subtle
dependency on `to` being the top.
This bug cased a quite large performance drop. Clutter FPS halved on my
setup (10+ workspaces) during certain operations.
Reproduction:
Focus window A
Slurp (vert. tiles window B)
Go to window B
Barf (untiles B vert.)
B has focus, but is not selected.
Happens because removeWindow ensures a window is selected, but addWindow doesn't
select the added window (which both makes sense).
We need to update the most recently used workspace stack when adding and
removing workspaces.
To make this less of a pain we make spaces.stack track all spaces, not just the
ones that aren't visible. Prefering instead to filter out the visible spaces on
`selectSpace`, this is a lot cleaner.
On startup we want to add windows «manually» and not through signals, eg.
because we want to reconstruct an old space. So while we should construct the
spaces as fast as possible to startup look good, we need to defer connecting
most signals until everything has settled (ie. after `startup-complete`).
We introduce `Spaces.init` and `Space.init` which connect signals and take care
of things that can't be done on `enable`, but rather after `startup-complete`.
Some more stuff:
Use `Main.layoutManger._startingUp` to detect startup, this is actually the
thing that's set when `startup-complete` is emitted.
Since we're using the window mru to construct the initial workspace order we
need to wait for all the windows to actually be available.
Installing and enabling the extension didn't work, as some stuff accessed
`TopBar.menu` too early. This was a pretty bad bug, that was fixed, but then
reverted.
The code isn't all that pretty, but it's easy to modify and tune to test what
works well.
I've opted to keep the workspace menu's smooth scroll implementation. When
swiping it's necessary to wait for a button press on the desired space since the
pointer can be anywhere. As such making sure that the workspace stack always
ends up in a discrete state isn't that useful, so I opted for more control when
swiping.
We should add some preferences that users can use to tune the speed of swiping.
I assume that this can vary quite a lot between different touchpads.
Having the hot corner activate the overview works rather poorly with scrolling
through the workspaces.
We disable the functionality by default. The preference `override-hot-corner`
controls the functionality, so set it to false if you want it back.
A possibility is having the hot-corner force the top bar to be visible when
a fullscreen window has focus, but it's not yet implemented.
We only need to calculate visible windows when we're ready to show window
actors again. This makes the tracking more robust as it should always be called
at the correct time.
`fixVisible` is replaced by `space.isPlaceable(metaWindow)` which checks if the
window actor can be placed at its clone's position. We simply call isPlaceable
from the main `moveDone` loop.
Ole Jørgen Brønner