console.log() is implemented with structured logging, and as we
set an appropriate log domain, it's identical to the custom function
bar the custom fields with extension data.
Few people know about those custom fields, and adding them comes
at a cost, as we end up producing and parsing a stacktrace on
every log() call.
It therefore seems appropriate to drop the custom function, and
turn the global log() symbol into a simple convenience alias for
console.log().
If it turns out that people do miss the custom fields, we can add
an alternative to ExtensionUtils.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2830>
`toLocaleFormat` is now `formatDateWithCFormatString` and formatTime and
formatTimeSpan are moved into dateUtils.
Instead of overriding system.clearDateCaches, add a helper in dateUtils.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2827>
Environment variables aren't the best option to pass parameters
to a process (wouldn't it be "fun" if SHELL_PERF_MODULE appeared
in a regular user session?).
Instead, use a (hidden) --automation-script command line flag to
specify a script file that should be used to drive an automated
session.
As a side effect, the script no longer has to be relative to the
main module itself, so it will be possible to run scripts that
aren't bundled with the shell sources.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2812>
The perf scripts that can be used to script the gnome-shell UI
for testing are sufficiently separate from the rest of the code
base to allow porting them to ESM modules before the rest of
the code base.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2812>
The file indicates to the systemd shutdown scripts that extensions
should be disabled, so that extensions that crash the shell on
startup cannot lock out the user indefinitely.
For that purpose, we create the file before initializing extensions,
and remove it after 60 seconds. That generally works, because it's
highly unlikely that a session genuinely ends within the first minute.
It's possible though (for example during developments or when running
tests), so also remove the file when shutting down cleanly before
the timeout.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2807>
Continue the move to ESM by loading modules dynamically with
the standard import() expression, rather than by installing a
custom (legacy) importer.
This is a breaking change that affects all extensions, as they
now need to explicitly export the expected symbols.
As we are already breaking all extensions, take that opportunity
and remove support for the individual entry points: Using a
class with enable()/disable() methods has been the recommended
pattern for a long time, it is now the only entry point.
Instead of instantiating the class from an `init()` function,
the class must now be exported as default to be recognized.
Additionally, we no longer install an importer on the extension
object, so extensions that consist of more than one file MUST
import those files as modules now.
There will be a second breaking change for extensions when
gnome-shell's own code is ported to ESM, so most extension
developers will likely want to wait until the port is complete
before starting to port their extensions.
Based on a commit from Evan Welsh.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2795>
- spin out all the panel button styling into a drawing mixin
- clean up the styles generally
- make special cases for the clock and non-flat buttons
- contrast fixes for non-flat buttons, fixes#6768
- new stop icon for the screen recording/cast indicators
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2804>
Commit c449058d44 changed the pointer clone to use a single
actor. However that broke applying the hotspot translation to the
position, so the magnified cursor is now displayed with a shift.
Undo the change to restore the old behavior.
This reverts commit c449058d44.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2780>
gjs now has an internal mainloop that it can spin to resolve
module imports. That loop uses the thread default context,
so its possible that other sources, namely from mutter, get
dispatched when iterating the context. If that happens before
mutter is properly initialized, this will lead to a crash.
GjsContext needs to iterate its internal mainloop when initializing
to resolve internal modules, to avoid iterating Meta's mainloop and
triggering events before Meta is ready we will initialize the Shell
global and thus the GjsContext (js_context) before Meta.
Once GjsContext is initialized, we can call meta_context_setup().
Once Meta is setup and started, we'll run init.js which uses GJS'
internal promises API to set a "mainloop hook". The mainloop hook
is run immediately after the module returns so GJS will not attempt
to iterate the main loop again before exiting.
Also adjust the 'headlessStart' test to not wait for the
MetaContext::started signal, as that signal has now already
been emitted when the code is executed.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6691
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2781>
get_size() in _syncAnimationSize() can't be called until the actor
has a parent, otherwise we'll get an error for calling
st_get_theme_node() prior to the actor being on a stage.
_syncAnimationSize() is called asynchronously via
textureCache.load_sliced_image() and there is currently no guarantee
the actor will actually be "loaded" prior to calling it.
This becomes a more obvious error/issue when refactoring parts of the
Shell loading to also be asynchronous.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2563>
We are about to port the helper proxy to GApplication, which means
that it will establish a display connection before exporting its
D-Bus name. That means that the compositor must be able to respond
to a roundtrip request to avoid locking, so don't block on the proxy
becoming available.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2733>
Now that we track apps instead of instances, we can make the menu
items activatable, because the corresponding action is no longer
app specific (like activating a particular tab): We can simply
activate the app, which hopefully will bring it to the foreground
again.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2790>
The background apps menu currently tracks instances rather than
apps. That matches the behavior of `flatpak ps` and can be useful,
for example when one particular instance runs out of control.
But as we don't include any information that allows to actually
distinguish between instances, multiple instances appear simply
as duplicated app entries.
Given that a menu is too limited for detailed information, stop
representing individual instances, and track apps instead.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6654
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2790>
Provide a reasonably public way to register and unregister search
providers, without adding too much API.
`Main.overview.searchController` provides access that may be generally
useful, while `SearchController.addProvider()` and
`SearchController.removeProvider()` provide a simple interface for
extensions.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2783>
We started to support Soup3 in GNOME 41, and used it by default
since GNOME 43. This should be enough time for distros to adapt,
so GNOME 45 looks like a good moment to drop the old Soup2 support.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2776>
Since we started to support the color-scheme preference, extensions
should be able to provide appropriate variants (if they deal with
colors).
So look for a variant with -dark/-light suffix before using the
plain stylesheet.css, and reload extension stylesheets on
color scheme changes.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2324>
Now that the app menu indicator is no longer shown, it shouldn't be possible
to toggle the popup menu via keyboard shortcut anymore, so remove the code
and gsettings definitions for that.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2610>
When the screencast dbus service crashes due to gstreamer, we should also
handle that and not pretend to continue recording.
Let's listen to g-name-owner changes for that and then also send a
notification about it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2752>
The events that the draggable uses to initiate a drag operation
are the same as the ones a click action consumes for clicks.
It is still possible to combine the two, but it's finicky and far
from being straight-forward. To make this easier, add a dedicated
addClickAction() method to draggables that takes care of the
setup before adding the action to the draggable actor.
In the longer term, we'll want to turn DND into an action, and
have something like GTK's gesture group to allow combining actions
that would otherwise step on each other's toes.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2742>
Actions provide a higher-level API than event handlers, not unlike
GTK's event controllers (albeit less complete). Allowing them to
take care of the low-level bits where possible is generally a good
idea.
Menu items are a very straight-forward case, with a good amount
of code saving, so port them over.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2742>
The handler dates back to commit 50f248ec5b in 2011, and is
part of the original hack of making the activities button a
PanelMenu.Button while suppressing its menu.
By now, panel buttons without a menu have been properly supported
for years, but somehow that bit of the hack stuck around, even though
it is no longer actually needed (probably since the introduction of
DummyMenu.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2741>
When we can't detect a headphone by form factor, we do a string
match on the port name. A match on 'Headphone' isn't less likely
to be valid than a match on 'headphone', so make sure we ignore
capitalization.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2691>
After the introduction of implicit grabs in Clutter, a release
event will now always be delivered to the actor that received
the corresponding press event.
This results in surprising behavior when moving the pointer
while pressed, as a button release will always activate the
original item, even when the pointer moved to a different item
or outside the menu altogether.
Address this by checking the hover state (that is, whether
the item contains the pointer actor) before activating it.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6606
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2740>
When a WindowPreview is being destroyed, the class default handler for
the `destroy` signal is responsible for destroying its child actors.
This happens after the emission of the `destroy` signal, i.e. after
`WindowPreview::_onDestroy()` has been run.
The destruction of the WindowPreview's child actors now triggers a
re-pick, but due to WindowPreview having already being marked as
`CLUTTER_IN_DESTRUCTION`, it will not be picked, resulting in a `leave`
event if the cursor was on top of the WindowPreview at the time
`destroy()` was called on it.
So this leads to `WindowPreview::vfunc_leave_event()` being run after
`WindowPreview::_onDestroy()`, which means the idle started by the leave
event handler will not be removed and ends up accessing actors after
they have already been destroyed.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5512
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6065
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2738>
Dash labels are children of the main uiGroup and so could be destroyed
before their logical-owner DashItemContainer during shutdown.
This implies that we could destroy them twice. To avoid this, unset them
when destroyed.
This is mostly visible when using dash-to-dock, but it's still
technically possible with upstream code:
** Message: 19:57:49.847: Shutting down GNOME Shell
(gnome-shell:2788214): Gjs-CRITICAL **: 19:57:49.933: Object St.Label
(0x55b33668eab0), has been already disposed — impossible to access it.
This might be caused by the object having been destroyed from C code using
something such as destroy(), dispose(), or remove() vfuncs.
== Stack trace for context 0x55b3345fd3d0 ==
#0 7ffeabd810d0 b /data/GNOME/gnome-shell/js/ui/dash.js:86
#1 55b335b62f88 i /data/GNOME/JHBUILD_HOME/.local/share/gnome-shell/extensions/dash-to-dock@micxgx.gmail.com/docking.js:487
#2 7ffeabd838f0 b self-hosted:1121
#3 55b335b62ec8 i /data/GNOME/gnome-shell/js/ui/layout.js:240
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2739>
The left/right navigation between top bar buttons is usually
handled by a key-press handler on the button's menu.
However when a DummyMenu is used, the button itself serves as
fake menu actor and will get grabbed when "opening" the menu.
Due to that grab, the event is not propagated to the stage,
and regular keynav does not work.
To avoid the focus getting stuck in that case, add an explicit
key-press handler that bypasses the grab.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2734>
When the user clears all notifications from the notification menu UI, it's
possible for a queued notification to be destroyed after the currently displayed
notification. The removal of the currently displayed notification is not
processed until the notification menu is closed (due to `this._bannerBlocked`).
By then, it's possible that `_notificationRemoved` has already been overwritten
when `_onNotificationDestroy` is invoked with another (queued) notification.
This eventually results in a notification banner that cannot be removed by the
user as the notification object needed to do so has already been destroyed.
Fix this by only assigning to `_notificationRemoved` if `this._notification ==
notification`.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2736>
When checking for an extension schemadir, an error will be thrown if
`query_info()` is used and the directory is missing.
Catch the case of a missing directory, but throw an error if the
path exists as a non-directory type.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2727>
Both :icon-name and :gicon are propagated to the internal QuickToggle
with property bindings. However the bindings are set up in the wrong
order:
:icon-name is a convenience property to set :gicon to a ThemedIcon
of the given name. That means binding :icon-name first will correctly
set the underlying StIcon's :gicon, but then the :gicon binding will
set it again to null.
Fix this by swapping the order in which the bindings are set up,
so that it works for both properties.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6542
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2726>
Commit 9d75d777c7 introduced code to hide the subtitle of the
quick setting toggle when it matches the title of the toggle.
That's because NetworkManager tries to make the network names
more palatable on its own, and reports that the name of single
wired networks is "Wired" even if it may have another name.
What that commit failed to account for, however, is that there are
other circumstances where we end up with a subtitle is exactly the
same of the title. For example, when turning off Wi-Fi or mobile
broadband connections.
The behaviour of commit 9d75d777c7 is safe enough to be applied
on other device-backed connections, so do it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2682>
When a window is in the background and should not have the cursor on top
of it, its _cursor will be null. By getting the texture through it, we
add this extra check, which was missing before, leading to a cursor
drawn at 0, 0 on windows where it should not have been drawn.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2702>
909616b208 seems to have wrapped window actors in a container, so the actor.has_pointer check started failing. Instead, switch to meta_window_has_pointer () which doesn't rely on window actor implementation details.
We check for existence of has_pointer first just in case someone attempts to run gnome-shell 44.1 with mutter 44.0 which does not have the function exported publicly yet.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2710>
Whether or not animations should be enabled depends on various
factors, some of which may change at runtime. We therefore
track changes, and sync the setting by calling inhibit/uninhibit
as necessary.
Except that we never actually record the new state, so when animations
are disabled, we end up inhibiting them every time
the setting is synced, whoops.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2698>
Even though commit b89d90eb8 talked about the GLib.BookmarkFile
type, this didn't stop the code from sneaking a silly typo and
refer to this GLib.BookmarksFile (i.e. extra 's').
Fix the code to refer to the right type name and constructor.
Fixes: b89d90eb8 ("screenshot: Use GLib.BookmarkFile to save recent screenshots")
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2692>
In GNOME OS, due to a misconfiguration, geoclue was configured without
systemd support. In that configuration, geoclue does not install its
systemd .service file (geoclue.service) but it (incorrectly) includes
the following line in its D-Bus service file:
SystemdService=geoclue.service
As a result, when dbus-daemon tried to activate it at gnome-shell's
request, it would fail with:
Unit geoclue.service not found
Then, GeoclueAgent._onGeoclueVanished() would be called, as the
name_vanished_handler passed to Gio.bus_watch_name(). This is consistent
with Gio.bus_watch_name()'s documentation:
> You are guaranteed that one of the handlers will be invoked after
> calling this function.
But that function assumed that this._managerProxy is defined, leading
to:
JS ERROR: TypeError: this._managerProxy is undefined
_onGeoclueVanished@resource:///org/gnome/shell/ui/status/location.js:163:9
Fix this by checking for nullishness of this._managerProxy. (Strictly
speaking, it's undefined rather than being null, but other code in this
file already uses the vaguer '!= null' test, which considers undefined
to be null.)
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2689>
At least for the time being, the background portal's app monitor
only supports flatpak apps, which are the only apps where we can
reliably match processes to .desktop files and assume that they
belong to graphical apps.
To indicate that there may well be apps that don't appear in the
list despite running in the background, add a clarifying section
title.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6400
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2681>
There is only a very limited subset of GTK that is usable from
within the compositor, and by now we should have replacements
for all of them in place.
On the other hands there is plenty that can go catastrophically
wrong in the rest. In particular on wayland, GTK must never open
a wayland display connection.
Make sure that extensions don't do anything silly, by disallowing
all GDK backends.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2680>
Prior to commit 7bd98f3f5f animation
onComplete handlers always occured at least after one main loop
iteration.
Now, if animations are disabled, they can get invoked immediately.
That breaks the endSessionDialog button handler, which calls
close before setting up the "closed" signal handler.
This commit fixes the handler to get set up first.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2677>
At least for the time being, the background portal's app monitor
only supports flatpak apps, which are the only apps where we can
reliably match processes to .desktop files and assume that they
belong to graphical apps.
To indicate that there may well be apps that don't appear in the
list despite running in the background, add a clarifying section
title.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6400
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2660>
There's a few things going on here, that unfortunately must
happen in lockstep:
- The gnome-desktop-3.0 dependency gets replaced by gnome-desktop-4
and gnome-bg-4. The code in ui/background.js required minor updates.
- The libnma dependency gets replaced by a libnma4 dependency. The
code in misc/modemManager.js required minor updates.
- The gtk3 dependency is torn down everywhere but tests. Some
missing GdkPixbuf dependencies had to be added to compensate for
its lack.
- gtk_init_check() is no longer called
As a result, we replace a hard gtk3 dependency with a soft gtk4
run-time linking one, only added indirectly through gnome-bg-4
and libnma4.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2655>
When the `QuickMenuToggle` was a discrete button, it could be set to
toggle mode, but the inner buttons no longer reacts as expected.
Bind the `toggle-mode` property between the `QuickMenuToggle` and its
contents so they behave as single toggle when enabled.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2664>
Avoid the GTK dependency, and use the common GLib API to store
screenshots in recent files. While at it, give it a better
exec hint than the implicit "gnome-shell %u" GTK added for us,
nobody seems to pay attention to that, but if they ever did
it's better to provide sensible information.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2656>
gnome-bluetooth clears the list of devices when the adapter goes
away, but we cannot assume that that'll happen when powered down.
We don't want to show a (potentially outdated) list of devices
that cannot be interacted with in that case, so explicitly check
for the active state when returning devices.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2658>
The FolderView is a subclass of BaseAppView, which already has a
full-blown SwipeTracker attached to it. So no need to add another
PanGesture on top, the SwipeTracker will handle it for us.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2318>
