The widgets `NotificationMessage` and `NotificationSection` in `calendar.js`
aren't used only by the calendar.
Move the two widget to messageList.js since once we add by-source grouping for
messages (which will happen in a future commit) we need a much tighter
coupling between them and the rest of the MessageList. In future the
`NotificationSection` will need to be removed to make expanding of
groups work.
This also removes a circular import of files: `calender.js` imports
`messageTray.js` and it imports `calender.js`.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3429>
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>
Since commit eeddf49371, the menu button in toggles is separated
by an actual widget rather than just CSS borders.
However the menu button can be hidden, in which case the menu toggle
acts as a regular quick toggle. The separator shouldn't be visible
either in that case, so hide it.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/8159
Fixes: eeddf49371 ("style: Improve the styles for the separation in quick setting buttons")
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3621>
There are two instances where we set the deprecated `vertical`
property with a `{vertical}` shorthand that escaped previous
greps; move those to the new `orientation` property too.
Fixes: b75b4abaf0 ("js: Set BoxLayout orientation")
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3618>
Since `Spinner` is no longer a subclass of `Animation`/`AnimatedIcon`,
the latter are now unused. Apparently that's not only true for
gnome-shell itself, but also extensions, so there's little reason
for keeping the former base classes around.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3612>
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>
The container is tightly coupled with the preview, and there is
never a need to replace it at a later point. Set it directly
during construction, so the underlying base class can make
this 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 adds a comment to make clear that the Utilities category is
intended to be organized alphabetically by the display name of
the apps (*not* by the desktop file names), and adds comments
with the current display name of each app.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3609>
These have (Logs) or previously had (Characters) the
X-GNOME-Utilities category in their .desktop file and so showed
up in the Utilities folder (despite 152faae claiming that the
category was "completely unused"). Characters had the category
removed in
https://gitlab.gnome.org/GNOME/gnome-characters/-/commit/210eb09
in apparent expectation that it would be added to the list, but
it seems it was not.
We could restore consideration of the category, but I guess let's
just list the apps instead? I don't know if any others are
missing.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3607>
In order to keep the test code brief, all expected times and dates are
written as ISO 8601 strings in the test code, and use `Z` to specify UTC
(again, to keep things brief).
If the test is run under a significantly different timezone, the
end-of-day timestamp changes significantly, as it’s calculated by the
code-under-test using the local timezone.
Avoid that issue by requiring the `timeLimitsManager` tests to always be
run in UTC.
The previous failure could be reproduced by running `TZ=Europe/Madrid
meson test -C /opt/gnome/build/gnome-shell timeLimitsManager --verbose`
— the test for “tracks a single day’s usage early in the morning” would
fail.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3605>
