To do this, we now wait for the start/stop job to complete. We also have
two targets in gnome-session to ensure that everything is working as
expected.
In order to start the services, we simply request the
gnome-session-x11-services-ready.target unit, and wait for it to become
available. To stop, we use the gnome-session-x11-services.target unit
which should stop all services in a way that is entirely race free.
This requires both gnome-session and gnome-settings-daemon changes to
work (which are in the corresponding merge requests).
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/895
Now that we properly notify mutter about when a size-change animation
has ended, it should never happen that a new size-change animation is
started without the last one being cancelled (ie. 'kill-window-effects'
being emitted).
This means there should also never be an old animationInfo attached to a
window actor, so warn in case we still find one when starting the
animation.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1251
We're currently using the hack of telling mutter that our effect is
completed (even though it isn't) in order to unfreeze updates of the
window actor.
This causes a bug with detecting the wl_outputs a window is
visible on, because the MetaWindowActor emits its "effects-completed"
signal too early, making Mutter update the wl_outputs while we're doing
the animation.
Now since meta_wayland_actor_surface_is_on_logical_monitor() uses the
transformed position and size of the MetaSurfaceActor and is being
called right after we setup the animation (but before it actually
starts, that happens at the next paint cycle) it will use a "very wrong"
rectangle: The transformation has been set to move the actor back to its
old position, and while we did already unfreeze updates and called
clutter_actor_set_position() in meta_window_actor_sync_actor_geometry(),
the actual allocation is not updated yet; this makes
clutter_actor_get_transformed_position() return a position including in
the new transformation, but not including the new allocation, and the
rectangle ends up being moved to the next monitor or completely out of
the stage.
To fix this issue properly, we need to decouple unfreezing actor updates
from emitting the "effects-completed" signal, which is now possible with
the new meta_window_actor_freeze() and meta_window_actor_thaw() APIs. So
use those new methods to freeze and thaw actor updates ourselves and
make sure to call shellwm.completed_size_change() only after the
animation has finished.
Mutter MR: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1250
Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/513https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1251
It might be that we receive a "kill-window-effects" signal between the
emission of the "size-change" and the "size-changed" signal.
In this case we already have the animationInfo attached to the window
actor, so we should also remove it.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1251
Since commit 0ecddafc20 gsd-xsettings startup has been made conditional
on the systemd user instance being available at runtime. While that is
correct, it means that completing xwayland startup is also conditional
now.
We always want xwayland startup to go ahead, so wait for the XSettings
plugin to appear on the bus when gsd-xsettings is launched by gnome-session
and complete the task immediately if startup fails.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1252
These paths are meant for Xwayland, not for X11 compositors being restarted
through alt-f2 + r. Maybe some signal analogous to init-xserver should be
added for Xwayland shutdown paths, but this signal we are currently
listening for is backend agnostic.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/2329
Currently, a failure to start the Systemd unit `gsd-xsettings.target`
would be considered a failure to start Xwayland.
That means that if `gsd-xsettings.target` fails to start for whatever
reason, no X11 client can be used on Wayland.
However, XSettings is by no mean mandatory for X11 clients and many
legacy X11 clients do not implement XSettings. Those who do always have
a fallback path and therefore can still work without XSettings.
Make a failure to start the Systemd unit `gsd-xsettings.target` non
blocking for Xwayland, and just log a warning message.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1065
We do spawn gsd-xsettings, and watch its name before notifying on the
given task, so the mutter bits can proceed with X11 startup.
One notable change is that we only start gsd-xsettings, instead of the
generic gnome-session-x11-services target. We do so as we have to wait
on a dbus name to appear in order to deem the initialization done, and
making it all depend on gsd-xsettings seems tidier.
Less notably, we also use ::shutdown-xserver to shutdown the related
services. Its major benefit is that it'd allow us to ensure the olderly
shutdown of those services, but it's unused at the moment.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/836
When a window is being resized by the compositor, with Wayland the
compositor first asks the window to change its size and emits the
"size-change" signal, and then emits the "size-changed" signal after
the window acknowledges the new size. To show a fancy resize animation,
gnome-shell creates a "screenshot" of the resizing window on the
"size-change" signal, and later animates that "screenshot" to the new
window size on the "size-changed" signal.
Now if a client is not responding to our requests asking it to change
its size, we get a "size-change" signal and start showing the
window-clone, but never a "size-changed" signal, animating and hiding
the clone again. This causes a so called "ghost window" that is shown
above everything else and never disappears again.
To fix that, start showing the window clone once we get the
"size-changed" signal instead of the "size-change" signal. This makes
sure the window actually updates its size and the clone is going to be
hidden again.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/1078https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1055
This reverts commit c0c027c608. Because for
some reason animating external opacity and position is still incurring
internal repaints, which disables offscreening and makes fading of
overlapping actors look wrong. `ON_IDLE` should be fixed in mutter before
it is used (in boxpointer at least) again.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/2270
To bypass offscreening in cases where continuous animation is happening.
Offscreening is slower in such cases so this reduces the render time of
animations within offscreenable actors.
On an i7-7700 this reduces the render time of boxpointers for example by
25-30%.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1025
xgettext gained some support for template strings, and no longer
fails when encountering '/' somewhere between backticks.
Unfortunately its support is still buggy as hell, and it is now
silently dropping translatable strings, yay. I hate making the
code worse, but until xgettext really gets its shit together,
the only viable way forward seems to be to not use template
strings in any files listed in POTFILES.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1014
Since ES5, trailing commas in arrays and object literals are valid.
We generally haven't used them so far, but they are actually a good
idea, as they make additions and removals in diffs much cleaner.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/805
ES6 allows to omit property names where they match the name of the
assigned variable, which makes code less redunant and thus cleaner.
We will soon enforce that in our eslint rules, so make sure we use
the shorthand wherever possible.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/805
If an else block only contains an if statement, the two can be
combined into an if-else block, which cuts down on indentation
and usually helps legibility.
There are exceptions (for instance where the outer if and else
blocks are mirrored), but where it makes sense, change the code
to avoid lonely ifs.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/805
Resizing effects are more finicky as other effects, as the actual
animation is delayed until we receive the ::size-changed signal.
However that signal may never be emitted if the window is destroyed
just after starting the size-change effect, in which case the effect
is never completed, blocking mutter from destroying the corresponding
window actor.
Address this by tracking when a resize effect is pending, and complete
the effect when appropriate.
https://gitlab.gnome.org/GNOME/mutter/issues/655https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/815
Clutter originally cluttered its namespace with key symbols, before
prefixing all symbols with KEY. We still use the unprefixed symbols
occasionally, replace them so mutter can drop the deprecated symbols.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/808
Every since commit aa394754, StBoxLayout has supported ClutterActor's
expand/align properties in addition to the container-specific child
properties. Given that that's the only container left with a special
child meta, it's time to fully embrace the generic properties (and
eventually remove the child meta).
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/780
Remove all transformations from window actors after a window animation
was either cancelled or finished. Right now we only do that if the
transition finished successfully, which seems kind of pointless (it can
probably be historically explained because the callbacks inside the
"kill-window-effects" signal handler are connected to those
`*WindowDone()` functions though and the `*WindowOverwritten()`
functions were only added later in [1]).
This fixes a recent regression where a window animation would get
cancelled and remain stuck by switching workspaces. The regression
probably happened due to different behaviour of the `onOverwritten`
callback of Tweener and the `onStopped` callback of Clutter transitions:
For the workspace-switching animation the window actors get reparented
to a temporary container, which makes Clutter transititons emit
"stopped" (`clutter_actor_remove_child_internal()` stops transitions on
its children), while Tweener would continue the animation.
[1] 6dd302e5cehttps://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/784
Remove the `this.actor = ...` and `this.actor._delegate = this` patterns in most
of classes, by inheriting all the actor container classes.
Uses interfaces when needed for making sure that multiple classes will implement
some required methods or to avoid redefining the same code multiple times.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/559
As arrow functions have an implicit return value, an assignment of
this.foo = bar could have been intended as a this.foo === bar
comparison. To catch those errors, we will disallow these kinds
of assignments unless they are marked explicitly by an extra pair
of parentheses.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/731
We now do 2 things along Xwayland startup/shutdown:
- Start or stop the gnome-session-x11-services target, that will
pull all X11 related services that the session might depend on.
- As we start ibus-daemon manually, trigger a restart in order to
toggle the XIM daemon on and off along with Xwayland presence.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/680
Properties that aren't marked as animatable don't support *implicit*
animations, but they can still be animated with explicit transitions.
Use the newly added convenience method to cut down further on Tweener
usage.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/666
The set_brightness() method is the most convenient way of controlling
the effect's brightness, but Clutter animations only deal with properties,
so start using the (ClutterColor) brightness property instead.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/666
Currently WindowDimmer exposes a JS property that is used to control the
underlying effect. This works fine with Tweener, but not with Clutter
animations which we want to use ultimately.
As a first step towards that, expose a setDimmed() method instead of
the property and handle the animation internally, so it can be adapted
more easily.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/666
We now have everything in place to replace Tweener for all animatable
properties with implicit animations, which has the following benefits:
- they run entirely in C, while Tweener requires context switches
to JS each frame
- they are more reliable, as Tweener only detects when an animation
is overwritten with another Tween, while Clutter considers any
property change
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/22
The different units - seconds for Tweener and milliseconds for
timeouts - are not a big issue currently, as there is little
overlap. However this will change when we start using Clutter's
own animation framework (which uses milliseconds as well), in
particular where constants are shared between modules.
In order to prepare for the transition, define all animation times
as milliseconds and adjust them when passing them to Tweener.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/663
Those unused arguments aren't bugs - unbeknownst to eslint, they all
correspond to valid signal parameters - but they don't contribute
anything to clarity, so just remove them anyway.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/627
While mutter supports a variety of different grid layouts (n columns/rows,
growing vertically or horizontally from any of the four corners), we
hardcode a fixed vertical layout of a single column.
Now that mutter exposes the actual layout to us, add support for a more
traditional horizontal layout as well.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/575
Braces are optional for single-line arrow functions, but there's a
subtle difference:
Without braces, the expression is implicitly used as return value; with
braces, the function returns nothing unless there's an explicit return.
We currently reflect that in our style by only omitting braces when the
function is expected to have a return value, but that's not very obvious,
not an important differentiation to make, and not easy to express in an
automatic rule.
So just omit braces consistently as mandated by gjs' coding style.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/608
While we have some style inconsistencies - mostly regarding split lines,
i.e. aligning to the first arguments vs. a four-space indent - there are
a couple of places where the spacing is simply wrong. Fix those.
Spotted by eslint.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/608
We are currently inconsistent on whether case labels share the same
indentation level as the corresponding switch statement or not. gjs
goes with the default of no additional indentation, so go along with
that.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/608
We can use that newer method where we don't care about the actual position
of an element inside the array.
(Array.includes() and Array.indexOf() do behave differently in edge cases,
for example in the handling of NaN, but those don't matter to us)
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/152
Using one variable to initialize all gestures will update the address of
the "gesture" pointer with every newly initialized object. This means
that event handlers which also use the "gesture" pointer like the
'keyboard-visible-changed' handler will update a different gesture as
soon as the pointer is changed.
This lead to a bug where the handler of 'keyboard-visible-changed'
wrongly nabled the unfullscreen gesture. Fix that by assigning each
gesture its own variable.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/598
The `switch-to-application-n` shortcuts are essentially "launch the nth
app in the dash" actions, so they are at the very least confusing when
the dash isn't available because the overview itself is disabled (for
example in initial-setup mode).
So disable the shortcuts when the overview is disabled, but delegate the
decision to a separate function so that extensions like 'panel-favorites'
which expose favorites by some other means can easily re-enable them.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1333
Make the dialog a widget itself, removing the `_group` property used for
handling the actor.
Update all the inherited classes to be also GObject implementations, moving all
the signals to proper object ones.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/55
To prevent a small gap between windows in the workspace switching
animation, we temporarily shift windows up or down by the height of the
panel. This obviously breaks the animation for fullscreen windows, those
will overlap with the ones on the other workspace since there is no
panel shown in that case.
Fix this by checking whether the old or new workspace includes a
fullscreen window and don't shift the windows if there is one.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/757https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/322
If a window gets destroyed right before it's resize
animation starts the user can get confronted with an undead
zombie clone that doesn't go away.
This commit makes sure said clones get reaped with their
actors.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1166
Inserting a workspace is implemented by appending a new workspace, then
shifting all windows after the "new" workspace up. This has an unintended
side effect on sticky windows, as changing its workspace will unstick it.
Fix this by excluding sticky windows - there's little point in moving them
anyway, given that they should be on all workspaces (including the original
workspace and the target one).
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1151
The window group is hidden while in overview, so the stick-to-content
animation isn't visible either. Worse, the gestures messes up the
position of window actors in that case. Just limit the gesture to
normal mode for now, we will soon add it back in the overview with
its own animation handling.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/516
The touch/touchpad gestures to switch workspace currently hard-code
the modes in which we want the gestures to work. While these modes
are correct, the existing switch animation only works in NORMAL mode,
not in the overview where the window group is hidden. The easiest way
to address this is to handle both cases completely separately, namely
use separate actions in- and outside the overview.
Make the existing usable in that way by making the list of allowed
modes a constructor parameter.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/516
The top drag gesture is not of any use if the topmost window is not
a fullscreen window and will only block events near the important top
screen edge (i.e. the panel). To fix this, only enable this gesture if
the focus window is a fullscreen window.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/552
Having Unity-like shortcuts for activating the first nine applications
in the dash has been a long requested feature, but somehow nobody got
around to implement it.
As the shortcut is most useful outside the overview where the dash is
not visible, only consider favorite apps as they have a predictable
order.
https://bugzilla.gnome.org/show_bug.cgi?id=648000
ES6 finally adds standard class syntax to the language, so we can
replace our custom Lang.Class framework with the new syntax. Any
classes that inherit from GObject will need special treatment,
so limit the port to regular javascript classes for now.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/361
When using dynamic workspaces, it is possible to try to change to a
non-existent one if the user defines hotkeys for changing to desktop
1, 2, 3... This case is not detected, and gnome shell shows an error:
JS ERROR: TypeError: workspace is null
actionMoveWorkspace@resource:///org/gnome/shell/ui/windowManager.js:2130:13
wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22
_showWorkspaceSwitcher@resource:///org/gnome/shell/ui/windowManager.js:2104:13
wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22
This patch adds a check before trying to change the workspace, to avoid
switching to a non-existent one.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/365
Instead of defaulting to a natural scroll behavior,
have the workspace switch action use the natural-scroll setting
in org.gnome.peripherals.touchpad to determine the correct
direction of travel when swiping. 4 finger swipes will then
match the behavior of the rest of the UI.
Reference: https://gitlab.gnome.org/GNOME/gnome-shell/issues/516
Shell.GenericContainer exposes the size negotiation machinery
through the use of signals. Signals are not specially performant.
One of the reasons is that they acquire a global lock for signal
handlers lookup. GNOME Shell has more than 2,000 actors at any
given point in time, up to 20 levels deep in hierarchy, making
size negotiation and painting non-trivial tasks. Such a critical
section of Clutter's machinery shouldn't rely on signals
whatsoever.
Regardless of that, Shell.GenericContainer is a workaround to
a non-existing issue anymore. It shouldn't be used anyway, and
any performance improvements that removing it can potentially
yield are bonuses to it.
This commit starts this work by removing Shell.GenericContainer
usage from Panel.Panel class. The class now extends St.Widget,
and as such, it has no "this.actor" field set anymore. A couple
of places where this actor field was used are adjuste as well.
It is important to notice that we now allocate the Panel itself
inside vfunc_allocate(). This was previously done before emitting
the signal by Shell.GenericContainer.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/153
Since we always keep the active workspace until the user switches
to a different one, we may end up with two empty workspaces at
the end. It's not obvious to users why this happens, and there's
indeed no good reason for the behavior - just remove the trailing
workspace in that case.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/536
