Prior to Geoclue v2.7, the location description did not seem to ever be
set. Now, the source used to determine the location is set as the
description. This can result in the location name in dateMenu to be set
as "WiFi", "GeoIP", etc., since we relay the description as the location
name to GWeather. Instead, pass an empty string so GWeather continues
to set the location name itself.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2729>
The Config module is shared between the main process, D-Bus
services and tests, which previously prevented it from being
ported to ESM.
The previous commit removed the last outstanding blocker, so
we can now port the last remaining module.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2880>
We have been using type-safe comparisons in new code for quite a while
now, however old code has only been adapted slowly.
Change all the remaining bits to get rid of another legacy style
difference.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2866>
We have made good progress with transitioning to the new style,
to the point where we can complete it with a final push.
Start with changing the remaining places that still use double
quotes.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2866>
Commit 17d9ec5788 made the input method call update() more eagerly,
but also at times that it does not have a cursor position yet. Make
it bail out correctly in that situation.
Fixes: 17d9ec5788 ("inputMethod: Keep Capabilite.FOCUS before context.focus_in/focus_out")
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2876>
If context.focus_out() is called *after* context.set_capabilities(0),
The FocusOut D-Bus method is ignored because of no FOCUS capability.
If context.focus_out() is called *before* context.set_capabilities(0),
The 0 capability is set to the next focused context and the
FocusIn D-Bus method is ignored because of no FOCUS capability.
So context.set_capabilities(0) should not be called.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6415
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2666>
The module is shared between the various D-Bus services and the
main gnome-shell process, so it was originally left out to allow
porting different bits at their own speed.
Now that everything has been ported to ESM, there is no reason
to not move that particular module as well.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2868>
ExtensionUtils was originally used for shared functions between
the extension system and the (old) prefs-tool, but then gained
useful API meant for extensions themselves.
It's a bit weird to mix the two, so split out the extension convenience
API into a separate module.
We will soon split up the module further, and add specific "flavors"
for extensions and preferences, with the current code providing a
shared base for both.
That should explain both the new location and the odd module name. :-)
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2837>
Now that we always have an extension manager object, we can use
the same code path for use from extensions and prefs.
For that, inject the D-Bus service's extensionManager instead
of the current extension.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2832>
When looking for a directory name that matches the extension UUID,
we can just as well use GLib's dirname()/basename() functions
instead of wrapping the path in a GFile.
We also know that the original path corresponds to a regular file
and not a directory, so rearrange the loop to avoid a lookup that
is guaranteed to fail.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2832>
We currently use a regular expression to extract the exact file path
from a stack line. That RE is no longer accurate:
- we assume a line number at the end, but at one point the column
number was added as well
- stacks from ES modules use file:// URIs instead of plain paths
Luckily that doesn't matter: We don't want to access any actual
files, so all we need is a path that can be traversed and that
contains the UUID.
We can get that with simple string manipulation, so avoid the regex
overhead.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2832>
gi modules are always loaded (there is no API for "set version without
loading"), so
we need to break dependencies.js into three sections:
- Required
- Compile-time optional
- Runtime optional
Required dependencies are always imported, compile-time optional
dependencies
are loaded if gnome-shell is compiled with support for them, and for
runtime optional dependencies we catch any errors when attempting to
load them.
If runtime optional dependencies fail to load we log a debug-level
message.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2822>
We started to version them last cycle, so docs can be differentiated
between versions. It is not *expected* that two versions show up
on the same system, but then it also doesn't hurt handling it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2822>
Once environment.js is an ES module we need to ensure we can dynamically
specify the version for required GI dependencies such as Clutter.
Moving dependency version setup to dependencies.js ensures gi.require
calls are done before environment.js imports any utilities.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2822>
The environment module is used to initialize the environment, yet it
currently also defines the adjustAnimationTime() function.
Ideally it should not export any utility functions, in particular
once converted to ESM.
The function cannot be moved to the existing Utils module, as that
depends on an initialized environment, and can therefore not be
imported from environment.js, so use that opportunity to group
together several animation helpers in a new animationUtils module.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2822>
Part of the possible completions involves evaluating the part
of the passed in text that looks like an object, so that we
can query it for properties.
Using a Function or eval() for that means that we can only
complete text that does not use `await`. To get over that
limitation, evaluate the text in an AsyncFunction instead.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2842>
`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>
We currently special-case the DISABLED error when initializing
filtering, but not on app filter changes.
While it seems reasonable that Malcontent.Manager wouldn't emit
the signal while disabled, that's not actually true: It is emitted
when any user account information tracked by AccountsServices
changes.
Even if the signal were limited to changes of the ParentalControls
extension, it would still get emitted when app filtering *becomes*
disabled.
So regardless of potential improvements in libmalcontent itself,
we should filter out the DISABLED consistently, both when creating
the initial filter and when updating it.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6749
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2796>
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>
The IBusCandidatePopup can get 'stuck' in an active, visible state if
it is on-screen at the point when the input method is changed to a method
that doesn't use such popup (e.g. regular English).
Force the candidate popup to close when the engine is changed.
It will reappear (via regular lookup table update signal) if/when it is
next required.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6717
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2774>
Emitting this signal is broken right now: We check for a length of 0 on
this._objects[objectPath], but the
`this._objects[objectPath][interfaceName] = null` we do before the
check doesn't actually remove the key, it only sets the value to null,
leaving the key around and thus the amount of entries in the object doesn't
change.
Fix that by using the delete statement instead, "delete" properly removes
the key and thus affects the amount of entries in the object, making our
length === 0 check effective.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2730>
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>
Extensions can export asynchronous enable() and disable()
functions. To guard against re-entrancy when enabling or
disabling an extension, this commit adds two new states:
ENABLING and DISABLING which are set immediately prior
to calling enable() and disable() respectively.
This commit updates the extensions CLI and Extensions app
with new strings for these states.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2364>
The IBusInputContext currently seems to be a bit sloppy wrt propagating
the current state to engines after those are changed, this results in
engines possibly ending with purpose/hint/etc that do not actually
correspond to the current state.
Ensure this state is cleared on unfocus of our IBusInputContext, so
that the next time the input method receives an input focus, the new
state makes it all the way to the currently active engine.
Fixes situations in the GDM/lock screen password entry that IBus
would miss the PASSWORD hint set on the StEntry, and let passwords
be fed to engines.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5966
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2512>
Besides user interaction, there's two users of IBusManager.setEngine():
- The code that toggles all IBus engines off on entries with PASSWORD
purpose.
- The code that toggles completion support on OSK presence.
These are currently pretty oblivious to each other. Make this
interaction more resilient by making all external IBusManager changes
more cautious about directly changing the engine, and revoke properly
the completion mode if it needs be (e.g. changing to a non-XKB engine).
But another notable change is that ibus-typing-booster is now preferred
always, over PASSWORD purpose hints. This is done to avoid possible
doubled attempts to change the current engine (and ensuing IBusInputContext
confusion).
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2512>
