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>
Since commit 1807be1, we clear the fallback icon when a window is
removed, and notify the icon change. The notify call currently
happens after removing the window from the running state, but
before syncing the state (and possibly clear the running state
altogether).
That state is inconsistent and results in an assertion hit when
some code tries to re-fetch the icon in response to the notify
call.
Address this by updating the state before clearing the fallback
icon, so that the app will be in the correct STOPPED state after
removing the last window.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4888
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2073>
We were not properly tracking the window used for the fallback icon.
This could trigger a crash, as disconnection of the signal handler might
happen on the wrong window, which in turn could cause the icon change
notification to happen on a destroyed ShellApp instance.
Fix this by tracking the window used for the fallback icon. Disconnect
the icon notify callback explicitly for this window only when it is
removed.
Also, just to be extra safe, make sure that the icon is never NULL even
if x11_window_create_fallback_gicon should return NULL for some reason.
Closes: #4436
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2065>
We currently track windows via MetaWorkspace's ::window-added and
::window-removed signals. Those aren't emitted for override-redirect
windows though, as those aren't actually located on any workspace
(see https://gitlab.gnome.org/GNOME/mutter/-/blob/gnome-41/src/core/window.c#L1322).
While that shouldn't be an issue as there's no good reason to look up
the ShellApp of an OR window, extensions can make modifications that
result in OR windows ending up in places that assume that every window
has an associated ShellApp.
We can either
- accept that extensions break stuff (including badly)
- carefully handle app-less windows everywhere
- extend tracking to OR windows
Opt for the last option, as that's the most user-friendly and least
disruptive one.
It's also simpler to track ::window-created and ::unmanaged, as we
don't have to track workspaces or windows moving between workspaces.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4751
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2029>
The window-type property may change, and with it the skip-taskbar
property that decides whether we consider it "interesting".
As a result we can end up showing untracked window, i.e. one
which does not have an associated app.
Cover this case by simply tracking all windows regardless of
their type. This won't change the app's running state, as that
is solely based on the skip-taskbar property (which is enforced
for all previously excluded window types).
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4751
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2029>
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>
