Unlike `StBoxLayout` which is ubiquious, `StScrollBar` is hightly unlikely
to be used outside of `StScrollView`. It therefore seems unnecessary to
deprecate the `vertical` property before removing it, so do just that.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3614>
BoxLayout is extremely common, so removing the old `vertical` property
in favor of `orientation` would be very disruptive. Instead, deprecate
it to indicate our intention of removing it eventually.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3614>
Using "vertical: false" to express "horizontal" has always been a
bit awkward. While we have stuck to the existing property for a long
time, transitioning to an `orientation` property like in GTK and
Clutter seems better.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3614>
It is tightly coupled to the preview, and not meant to be unset
or replaced during the lifetime of the object; size requests
and allocation assume that it exists.
Make that explicit by marking the property as construct-only.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3615>
We currently only specify the library to link with when declaring
a dependency, which means that satisfying other requirements like
dependencies or includes is left to the targets.
Move everything required by libshell/libst to the declared dependency,
so other targets only need to care about their own requirements.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3615>
Our code to "forward" `notify` signals from the underlying layout
manager for the `vertical` property broke when ClutterLayoutManager
removed its own `vertical` property.
Property changes via the underlying layout manager should be rare,
but still worth fixing, so explicitly connect to `notify::orientation`
now.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3613>
This is mostly for use when testing a nested gnome-shell in a terminal:
terminating it with Ctrl+C from that terminal should give the process an
opportunity to save state on shutdown (such as the screen time limits
history file).
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3397>
This is a `GSource` which is dispatched when the offset of the system
real/wall clock changes with respect to the system monotonic clock. This
can happen when the user explicitly changes the system clock, or when
there’s an NTP sync after a prolonged period offline.
The source can’t tell you *what* the offset change was, just that there
was one.
This will be used in an upcoming commit.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3397>
Last cycle, libadwaita added a new Spinner widget whose visuals
we should adapt. It loops extremely slowly though (a framerate
of 60fps would require 3180(!) frames), which means our current
asset-based implementation isn't well-suited for the job.
Instead, reimplement the underlying GdkPaintable as ClutterContent.
This does not only ensure consistency with libadwaita, but also
gives us more flexibility by picking up style information from
the widget the content is attached to.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3565>
ClutterImage as is, is very basic and doesn't really serve any purposes
other than being inherited by StImageContent. As we cannot easily push
ImageContent to Mutter by merging it with ClutterImage because it will
bring more GdkPixbuf usages and also because Clutter doesn't really deal
with theming bits.
Instead, merge it with StImageContent and let GNOME Shell take over from
here.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3547>
Quoting Ebassi https://www.bassi.io/articles/2023/02/20/bindable-api-2023/:
Whenever you’re describing a function that takes a callback, you
should always annotate the callback argument with the argument that
contains the user data using the (closure argument) annotation
You should not annotate the data argument with a unary (closure).
The unary (closure) is meant to be used when annotating the callback
type
Recently gobject-introspection became a bit more strict with this and
that generated some warnings:
Warning: St: invalid "closure" annotation: only valid on callback
parameters
This commit fix all the closure annotations.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3535>
The hook would be optional if anything called `meta_plugin_get_info()`,
except that nothing has done so for the last ten years.
It seems a bit pointless to export information that is completely
unused, in particular as we never updated it ("version 0.1"?!),
so just stop doing that.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3524>
