The following happens when processing an `@import()` rule:
1. `_st_theme_resolve_url()` to resolve file
2. `insert_stylesheet()` to track file/sheet
a. take ownership of file/sheet (ref)
b. use file as key in `stylesheets_by_file` hash table
c. use file as value in `files_by_stylesheet` hash table
3. release reference to file
This leads to a refcount error when importing a file that
was already parsed before:
1. file start with refcount 1
2. `insert_stylesheet()`
a. increases refcount to 2
b. inserting into `stylesheets_by_file` *decreases* the
passed-in key if the key already exists
c. `files_by_stylesheet` now tracks a file with recount 1
3. releases the last reference to file
The file object tracked in `files_by_stylesheet` is now invalid,
and accessing it results in a crash.
Avoid this issue by reusing existing stylesheets, so we don't insert
a stylesheet that's already tracked.
As a side-effect, this also saves us from re-parsing the same file
unnecessarily.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7306
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3619>
gjs_context_eval_module_file() is a convenience method for
- register the module (load and parse)
- evaluate the module (run)
The first can fail, but has no notion of status code; the
second will always set a valid code if provided (either as
returned by the module, or set by gjs itself).
Doing those two steps separately allows us to explicitly
handle failures to register the module, so that we can then
return the original status code from evaluating the module.
That means that if evaluating the module "fails" with a
`GJS_ERROR_SYSTEM_EXIT` error (because it was terminated
with `System.exit()`), we now return the correct status
code instead of `EXIT_FAILURE`.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3599>
The gjs API is slightly odd, in that explicit calls to `System.exit()`
are treated as errors, regardless of the passed status code.
Before addressing this, split out the module evaluation code into
a separate function to separate it from the main logic.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3599>
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>
