logError() prints an exception with an optional prefix, and is
used fairly commonly through-out the code base.
The problem is that by being defined in gjs, it uses "Gjs" as the
GLib log domain, not our own as expected.
Address this by adding a small override that implements the function
with console.error().
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3072>
The new InteractiveScreenshot() D-Bus method is implemented using
the signals introduced by the previous commit, and is fundamentally
very simple: take the screenshot, and return the GFile URI.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2999>
These signals will let the yet to be introduced D-Bus method to
be notified of when either a screenshot has been taken, or if
the screenshot UI has been closed without taking a screenshot.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2999>
Add a screenshot-exclusive mode that makes the screencast button
unreactive, and therefore disables screencasting. It doesn't change
the visibility of the button though, as that's done by the codepath
that checks if screencasting is supported.
This will be used by the D-Bus callback to take interactive
screenshots.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2999>
Make the captureScreenshot() auxiliary function return the GFile at
which the texture was saved. This file will be used to return the
screenshot URI to the new D-Bus method to take interactive
screenshots.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2999>
Now that we can use console.debug() to log messages that aren't
shown by default, we can be a lot more verbose without spamming
the system log.
Use that to all extension state changes, which can be useful for
debugging.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3058>
When an extension is disabled, we "rebase" all extensions that
were enabled afterwards, in case they override the same method.
This can be fairly expensive, in particular when disabling many
extensions at once, for instance when locking the screen.
Help with that by sorting extensions by the number of session-modes,
as extensions that support multiple modes are less likely to be
disabled on session mode changes.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2851>
Since commit c290a38730eb2a, St.Bin respects the child's
expand properties instead of basing expansion on the
alignment.
Commit b02800f8 updated a number of callers to prepare for the
change, but the "Flags" tab in looking glass was missed.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3060>
Right now, St.Bin ignores the child's expand properties, and
instead expands the child if its alignment is set to FILL.
This will change when we replace the custom allocation code
with a layout manager, so to prepare for that, set the expand
property where needed to keep the expected behavior.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3046>
- updated mixin for tile_button
- dropped the overview_button mixin
- minor changes to dash, appDisplay and switcherPopup JS to accommodate new stylesheet
- new focus style for all tile buttons
- improved high contrast style support for app grid and dash
- renamed some style-classes
- tidied up dash stylesheet
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3017>
Requires mutter!1908 first.
So now consumers of the clutter blur code don't have to know the
implementation is Gaussian and no longer need to convert the intended
blur radius to a sigma value.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1905>
If an interface has any signals, we don't want to auto-shutdown
while a caller is still connected to a signal.
Unfortunately we can't tell whether there are any signal connections,
so we track all callers instead, and keep the service alive while
any of them is still on the bus.
For services that we call from gnome-shell itself - like screencasts
or extensions - this has the unintended side effect of effectively
disabling auto-shutdown.
Address this by exempting the org.gnome.Shell name from sender
tracking.
Services that we expect to keep running for the lifetime of the
shell already disable auto-shutdown, so the only downside is a
small startup delay to resolve the well-known shell name.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7250
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3052>
- new drawing function to convert px to em, for select instances
- updated fontsize function to convert fonts in pt to em
- replace instances of discrete sizes with defined values
- fix instances where assets or icons did not scale along with text
- rework panel buttons to accommodate the scaling padding and icons
- new 'scalable' definitions for elements that follow text scaling
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3033>
After the port to ESM, an extension's `prefs.js` file is imported
asynchronously. An unintended side effect of that is that we now
show the dialog before anything can be added to the window (either
by the extension, or the fallback error UI).
The delay almost always won't be noticeable to users, but it's
bad practice and prevents extensions from using some API that
only works before the window is realized.
To address the issue, add a `loaded` signal to the dialog that allows
the caller to postpone showing the window until the UI is ready.
Close: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7201
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3025>
Using an exported `init()` function to create the object is an odd
pattern, and not having the object referenced anywhere makes it harder
to access for debugging or extensions.
Just export the `EndSessionDialog` class and instantiate it like we
do for other objects.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2997>
Custom properties are not cached by the theme node itself, so
looking them up repeatedly at every repaint is relatively
expensive.
Avoid this by caching the values ourselves at style changes.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2994>
Custom properties are not cached by the theme node itself, so
looking them up repeatedly at every repaint is relatively
expensive.
Avoid this by caching the values ourselves at style changes.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2994>
I can't think of a reason why limiting the border to a maximum
would make any sense.
The original intention was probably to set a minimum border width
to avoid having to deal with border/no-border complexity in the code,
but as cairo accepts a line width of 0, it just works.
However limiting the size to the overall height seems reasonable,
as at that size a bigger height and different fill color can
achieve the same effect without requires special handling of
other values like the radius.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2994>
The Eval() method currently evaluates the provided string, and
returns the result immediately. This isn't useful when a promise
is returned, which has become much more likely now that accessing
any module requires import().
Simply await the result, to handle both sync and async code.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3021>
These have been long deprecated over in clutter, and (via several
vtables) simply forward the call to the equivalent ClutterActor methods
Save ourselves the hassle and just use ClutterActor methods directly
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3010>
When GridSearchResults::_getMaxDisplayedResults() is called after the
first character has been entered in the search, GridSearchResults has
no children yet. _getMaxDisplayedResults() tries to determine the
maximum number of search results based on how often the largest child
would fit into the allocated size or -1 (i.e. no limit) if there are no
children. So for the initial search there is no limit and in the app
search all matching apps get added as possible results, which due to the
search term being only a single character is almost all installed apps.
This now causes allocation to be run for all these results, despite the
vast majority of them never being visible, which on slower machines can
cause noticeable delays before the search results are displayed.
This now adds the ability for search providers to specify a maximum
number of results that gets used instead of -1 when specified. By being
provider specific this means extensions implementing their own providers
will not be affected by this.
Further this sets the maximum for the app search provider to 6 as per
the current designs.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7155
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3004>
PopupMenuManager was connecting to notify::key-focus on the stage on
construction, but only ever reacting to it when one of its menus was
open. Given that every single app icon and text entry creates a
PopupMenuManager this was causing a lot of these handlers to be created.
Every single handler meant calling into JS code only for the vast
majority of them to determine that they would not do anything.
Additionally these handlers were leaked for the whole lifetime of the
stage due to never getting disconnected.
This now only connects the handler when a menu is open and disconnects
again when it is closed, significantly reducing the number of active
handlers at a time.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7143
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3001>
If the cursor was placed on one of the widgets that get removed when
rebuilding the calendar due to a month change, destroying the hovered
widget will trigger a repick. This repick can then trigger an allocation
while not all buttons of the calendar are present.
If the last allocation before selected-date-changed is emitted was from
such an incomplete state, DateMenuButton will still freeze the layout in
this state in its signal handler.
What freezing the layout in DateMenuButton is supposed to do is to
prevent size changes of the menu when changing days, but for this the
layout needs to be frozen before potentially rebuilding calendar. This
change ensures that by emitting the signal earlier.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5411
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5469
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2989>
