Hiding the `WorkspacesDisplay` triggers a reallocation of the
`ControlsManagerLayout` which can fail with the following error:
```
JS ERROR: TypeError: workspace is undefined
_getSpacing@resource:///org/gnome/shell/ui/workspacesView.js:229:13
vfunc_allocate@resource:///org/gnome/shell/ui/workspacesView.js:355:18
vfunc_allocate@resource:///org/gnome/shell/ui/overviewControls.js:200:33
vfunc_hide@resource:///org/gnome/shell/ui/workspacesView.js:1070:38
vfunc_unmap@resource:///org/gnome/shell/ui/overviewControls.js:672:33
hideOverview@resource:///org/gnome/shell/ui/layout.js:312:28
_hideDone@resource:///org/gnome/shell/ui/overview.js:617:32
onComplete@resource:///org/gnome/shell/ui/overview.js:390:37
_makeEaseCallback/<@resource:///org/gnome/shell/ui/environment.js:134:13
_easeActorProperty/<@resource:///org/gnome/shell/ui/environment.js:298:60
```
This can be reproduced by closing the overview with the three-finger
gesture.
Thus propagate the unmap before hiding the `WorkspacesDisplay`.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2088>
The unfullscreen gesture was defaulting to enabled until the first
window focus change. With it now being run in the capture phase, the
gesture was preventing clicks in the top panel except on the activities
button before the first window was opened.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2087>
Like the main gnome-shell process, the extensions service loads code from
extensions. It therefore makes sense to prevent GType name clashes there
as well, just like we already to in the gnome-shell process.
This may break some extensions that use the old type name in .ui files,
but they can be fixed easily by specifying an explicit GTypeName.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2024>
Currently only banners in the SHOWN state are hidden when the underlying
notification is destroyed, but if they are in the SHOWING state, they
remain visible. Because the 'notification' member has already been set
to null when the notification got destroyed, closing the banner by
clicking on the close button, will not do anything and clicking on the
notification itself will result in an error message. For notifications
without a timeout, i.e. critical ones, this will result in an
uncloseable notification.
This can happen if the program creating a critical notification
immediately closes it again, as might happen with power notifications
from gnome-settings-daemon in some situations.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4855
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2079>
Besides dropping its GTK dependency (which doesn't affect us),
GWeather 4.0 replaces its own timezone type with GTimeZone.
It's easy enough to adjust to that, so port over to the new
version.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2083>
Replace deprecated functions with their direct replacements:
- dep.get_pkgconfig_variable() → dep.get_variable()
- prg.path() → prg.full_path()
- source/build_root() → project_source/build_root()
In one case we need meson.global_source_root() that was only
added in meson 0.58, so bump the requirement to that.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2077>
The WorkspaceGroup class in defined as CONST, which means that,
strictly speaking, is inaccessible from outside the file
workspaceAnimation.js. But Desktop Icons NG needs access to it.
Although the current Javascript engine "tolerates" this access,
a warning message is shown in the log advertising that it's
incorrect, and that although it is still allowed, the code
should be fixed.
This patch changes the definition from CONST to VAR to allow
accessing it from extensions.
jk
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2068>
The code to highlight matches did not properly escape the passed in text
as for markup before adding its highlighting markup. This lead to some
search result descriptions not showing up, because their descriptions
contained characters, such as "<", that would have to be escaped when
used in markup or otherwise lead to invalid markup.
To work around this some search providers wrongly started escaping the
description on their end before sending them to gnome-shell. This lead
to another issue. Now if the highlighter was trying to highlight the
term "a", and the escaped description contained "'", the "a" in
that would be considered a match and surrounded by "<b></b>". This
however would also generate invalid markup, again leading to an error
and the description not being shown.
Fix this by always escaping the passed in string before applying the
highlights in such a way that there are no matches within entities.
This also means that search providers that escaped their description
strings will now show up with the markup syntax. This will have to be
fixed separately in the affected search providers.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4791
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2033>
Firstly don't use EASE_IN for any minimize/unminimize animations because
those start slow and end fast. The effect of that was minimize/unminimize
appearing to be unresponsive to user clicks for a little while before
accelerating away. All such animations should be EASE_OUT for an immediate
response followed by deceleration at the end.
Secondly we replace the shallow 200ms QUADratic curves with a steeper
400ms EXPOnetial curve. Because it's steeper and twice as long the fast part
feels the same as 200ms QUAD, but there's an extra 200ms after that in which
to slow down smoothly giving a more fluid appearance. No sudden stops.
Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=786789
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2066>
If you slow down the unminimize animation you will notice it overshoots and
then snaps back, but only for decorated windows. Undecorated windows would
unminimize to their correct position. So we remove decorations from the
equation and now all window types unminimize to their correct position.
This wasn't noticeable because the unminimize animation velocity is usually
so high at the end (EASE_IN_EXPO) that there are no frames rendered near the
end of the curve to show it had overshot.
This appears to be consistent with the Mutter source - associating the
actor geometry with `buffer_rect` and not `frame_rect`. See
`meta_window_actor_sync_actor_geometry` for example.
Related to: https://bugzilla.gnome.org/show_bug.cgi?id=786789#c1
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2066>
The way it is currently calculated is broken for days with DST changes
or leap seconds and it is not needed anymore anyway. This will also make
the fix in the following commit simpler.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2023>
Given the correct end date this code would be able to determine this
correctly itself and doesn't need to rely on that property. And events
without correct end dates are currently not shown anyway. This prepares
for removing the allDay property entirely.
This also fixes events going from 13:00 the current day to 01:00 not
showing "...". It also fixes multi-day events wrongly detected as
all-day events by the calendar-server showing up as "All day", despite
only covering 1 hour of the day.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2023>
Events with a date time (not just a date) where the end time is missing
or matching the start time were considered to not overlap the selected
interval if they were happening on the start time of the interval. This
was causing such zero-length events to be omitted from the calendar if
they were starting at 0:00.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2023>
Using a starting time other than 0:00 will prevent events before the
chosen starting time from showing up for that range. This was causing
events before 12:00 to be missing in the shell calendar on the first day
of a range.
Fix this by always starting at 0:00 and then incrementing by days rather
than a time value that depending on DST or leap seconds may or may not
correspond to a day.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2023>
The ical events, we are comparing these intervals to use the first point
in time after the end of the event as their end time, while the code in
gnome-shell was using the last point in time within the range. This was
causing multi-day events ranging from 0:00 to 0:00 to have a trailing
"..." shown on the last day.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2023>
MetaContext:unsafe-mode was added as a debugging tool to temporarily
remove restrictions on privileged APIs. But as it turns out, there
are now extensions that toggle the property permanently. Right now
none of them are malicious (as far as I can see), but it's still a
bad idea and should be discouraged.
Do this with a notification that warns the user when unsafe mode is
enabled non-interactively (i.e. via looking glass), and hopefully
also clarifies what the weird lock icon in the top bar is about.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4798
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2050>
libgnome-bluetooth will start to offer a 2.0 library version
depending on GTK4. Given that GNOME Shell already depends on
GTK3, it cannot use this next version of gnome-bluetooth. And
since GJS will automatically try and use the latest version
available of any library, Shell must specify it wants 1.0
explicitly.
Add a required GnomeBluetooth version number when importing it
for the status indicator.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2015>
Showing multiple preference dialogs at the same time (for instance
by repeated `gnome-extensions prefs` calls) may or may not work as
expected, depending on whether any of the dialogs is modal or not
(read: opened via the Extensions app).
The easiest way to address this is to disallow more than a single
dialog at the time. It's arguably also the more predictable behavior,
and means extensions don't have to deal with inconsistent state
caused by multiple dialogs.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4564
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2013>
GTK4 relies entirely on refcounting for cleanup (that is,
there is no longer a destroy() method that forces a dispose
run regardless of the refcount).
Unfortunately that makes cleanup harder in (some) language
bindings, where an object may be kept alive implicitly by
closures etc.
Address this by releasing the hold count when the window
is closed rather than when it is destroyed.
This isn't the most elegant, but it ensure that the service
doesn't get stuck if an extension doesn't carefully clean
up everything in its prefs widget.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4564
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2013>
Like the old Tweener API, ease() allows to transition multiple
properties at once. If autoReverse or repeatCount are specified,
they should apply to all transitions, but right now we only set
them for the first one.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2007>
Now that we allow extensions at the lock screens, extensions
are allowed for every session mode gnome-shell would typically
change to at runtime.
This means there's little advantage to having an allowExtensions
property in the session mode definition.
This commit simplifies the code a bit by dropping the property.
Third party session modes can still lock down extensions through
gsettings if they need to.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1967>
Now extensions can specify which session modes they work in,
but specifying the login screen or unlock screen session modes in
an extensions metadata still won't work, because those session
modes disallow extensions.
This commit fixes that.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1967>
At the moment it's not realy possible to extend the login screen to do
things it doesn't have built-in support for. This means in order
to support niche use cases, those cases have to change the main
code base. For instance, oVirt and Vmware deployments want to be able
to automaticaly log in guest VMs when a user pre-authenticates through a
console on a management host. To support those use cases, we added
code to the login screen directly, even though most machines will never
be associated with oVirt or Vmware management hosts.
We also get requests from e.g. government users that need certain features
at the login screen that wouldn't get used much outside of government
deployments. For instance, we've gotten requests that a machine contains
prominently displays that it has "Top Secret" information.
All of these use cases seem like they would better handled via
extensions that could be installed in the specific deployments. The
problem is extensions only run in the user session, and get
disabled at the login screen automatically.
This commit changes that. Now extensions can specify in their metadata
via a new sessionModes property, which modes that want to run in. For
backward compatibility, if an extension doesn't specify which session
modes it works in, its assumed the extension only works in the user
session.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1967>
