Window previews looks slightly offset to the left and top right now
because we don't use the same padding on all edges of the Workspace. We
do that because the oversize and overlap of the window previews is
different on all sides (for example the bottom overlap is very large
because there we show the window title).
To make sure window previews are always perfectly centered on the
Workspace, only use the largest one of the oversize values as spacing
and padding, and add the larger one of the overlap values for the
vertical padding in addition.
With this, we now center the window previews on the Workspace while
never overpainting the allocation of that Workspace to show overlays.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3634
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1670>
This was forgotten when porting to GTK 4, leading to the following error
when user tries to copy the error message produced by an extension:
JS ERROR: TypeError: Gtk.Clipboard is undefined
_initActions/<@resource:///org/gnome/Shell/Extensions/js/extensionsService.js:255:31
run@resource:///org/gnome/Shell/Extensions/js/dbusService.js:177:20
main@resource:///org/gnome/Shell/Extensions/js/main.js:19:13
run@resource:///org/gnome/gjs/modules/script/package.js:206:19
start@resource:///org/gnome/gjs/modules/script/package.js:190:8
@/nix/store/fwnkwvhwm3kqck4fhkc5y5z853radggg-gnome-shell-40.0/share/gnome-shell/.org.gnome.Shell.Extensions-wrapped:7:17
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1795>
We only want to show the welcome dialog in the user session, not
on the login screen or during initial setup. We currently achieve
that by explicitly checking for those mode names, but there are
other modes like gnome-classic where the dialog is equally un-
helpful. Support those cases by adding a session mode property
that determines whether the welcome dialog should be enabled,
so that modes can opt in or out of the feature themselves.
(Both the 'gdm' and 'initial-setup' modes are based on the
'restricted' mode, so this change does not affect them)
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4026
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1793>
Usage of GET requests for checking updates was made deprecated
at website some time ago [1], but REST endpoint was
CSRF-protected until recently [2].
The body of update request may be big enough and thus does not
suitable for GET requests.
[1] 0b38da1b2b
[2] e3ab0c07dc
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1781>
As documented in g_once_init_enter(): "While @location has a volatile qualifier,
this is a historical artifact and the pointer passed to it should not be
volatile.". And effectively this now warns with modern glibc.
Drop this from our logging function.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1770>
As documented in g_once_init_enter(): "While @location has a volatile qualifier,
this is a historical artifact and the pointer passed to it should not be
volatile.". And effectively this now warns with modern glibc.
Drop this from our logging function.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1770>
`key` is an empty string in this case, causing `charCodeAt(0)` to return
`NaN`, which when passed to `Clutter.unicode_to_keysym` now generates an
error in gjs >= 1.67.3:
```
JS ERROR: Error: Argument wc: value is out of range for uint32
```
And the symbolic keys like Backspace, Enter and Caps Lock would have their
presses ignored.
Just skip the call to `charCodeAt` that will fail and allow
`Clutter.unicode_to_keysym` to return its usual error flag.
Fixes: https://bugs.launchpad.net/bugs/1918738
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1758>
The parameter to `ModalDialog.close(timestamp)` is optional. But when
invoked via the network dialog's Cancel button it was receiving an
implicit parameter value that's definitely not a timestamp:
```
[0x560f18af0c50 StButton.modal-dialog-linked-button:first-child hover ("Cancel")]
```
And as of today (or gjs >= 1.67.3) that's reported as an error:
```
JS ERROR: Error: Argument timestamp: value is out of range for uint32
popModal@resource:///org/gnome/shell/ui/main.js:638:12
popModal@resource:///org/gnome/shell/ui/modalDialog.js:206:14
close@resource:///org/gnome/shell/ui/modalDialog.js:179:14
```
and so you can't Cancel the dialog anymore.
Make sure `ModalDialog.close()` receives an `undefined` timestamp it
knows how to handle.
Fixes: https://bugs.launchpad.net/bugs/1918666
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1757>
Since commit 770231, StImageContent implements the GIcon interface, which
allowed us to represent all application icons as GIcon (app-info, X11 icon
property or themed fallback icon).
While that change made for a nicer ShellApp API, it did introduce a
conceptual issue in st_texture_cache_bind_cairo_surface_property():
GIcons usually represent static icons, while the ClutterContent
returned by that method updates automatically when the bound property
changes.
Address this by tracking the MetaWindow:icon property in ShellApp, and
update the fallback icon when it changes. With that, a GIcon object
always represents the same icon, and any icon change is reflected
by a corresponding GIcon change.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1761>
We hold a reference to all windows we track for the app. While that
reference is unlikely to be the last remaining one, we still shouldn't
release it until we are done with the window.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1761>
Creating a content object from a cairo surface may fail, in which case
we return an empty content with a 0x0 preferred size.
However when we treat such a content object as GIcon, we happily load
it anyway. Don't do that, so consumers like StIcon can fall back properly
to an alternative.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1761>
While most GIcons passed to this function cause a StImageContent to be
created with the requested size, cairo surface based icons already are
passed as StImageContent with a preferred size corresponding to the
size of the surface they were created from. As a result icons of window
backed applications were never scaled up like the other icons. Fix this
by ignoring the content size for these case.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1751>
Right now we use a ClutterClone ghost of the panel simply to add some
spacing to the top monitor edge.
We can remove the panelGhost by adjusting the allocations of all the
parts of the overview ourselves inside ControlsManagers vfunc_allocate,
this should also work with extensions that move the panel somewhere
else.
This makes the initial relayout of the overview significantly faster,
because we now no longer have to relayout the whole panel in the
process.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1755>
The OverviewControls actor gets allocated a fixed size by its parent,
the OverviewActor, anyway, so it's pretty useless to go through the size
request machinery and add up all the sizes of items in the iconGrid,
coming up with a preferred size that's wrong anyway.
Instead simply return a min and preferred size of 0 in
get_preferred_height/width of ControlsManagerLayout.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1755>
