Commit Graph

9313 Commits

Author SHA1 Message Date
Florian Müllner
0483dd31f0 extensionBase: Set up translations automatically
If an extension provides the gettext domain in its metadata,
then we can simply set up translations from the constructor,
so do that for a bit more convenience.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2838>
2023-07-30 10:29:44 +03:00
Florian Müllner
abdd1346da extensionBase: Stop injecting extensionManager
All extension lookups now happen through the dedicated
Extension/ExtensionPreferences classes, so the shared
code no longer has to access the extensionManager.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2838>
2023-07-30 10:29:44 +03:00
Florian Müllner
82237a398f extensions: Add static lookupByUUID() method
This allows the Extension/Preferences classes to provide
the UUID -> extension lookup without exposing the underlying
extension manager.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2838>
2023-07-30 10:29:44 +03:00
Florian Müllner
931ca5e4ab extensions: Replace exported gettext functions
Use the new defineTranslationFunctions() method from the previous
commit to create gettext functions for the module, instead of
re-exporting from the shared module.

It is now up to extension developers to use the more effective

```js
import {Extension} from 'etensions/extension.js';
const {gettext: _} =
    Extension.defineTranslationFunctions(import.meta.url);
```

or the more convenient

```js
import {Extension, gettext} from 'extensions/extension.js';
const _ = gettext;
```

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2838>
2023-07-30 10:29:44 +03:00
Florian Müllner
f59d523694 extensions: Add static defineTranslationFunctions() method
The method can be used to define a set of gettext functions that
call the corresponding method of an extension.

Those functions are very similar to the gettext functions we are
exporting, except that:

 - looking up the extension is delegated to the
   Extension/Preferences class
 - it is possible to avoid examining the stack
   when called with `import.meta.url`

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2838>
2023-07-30 10:29:44 +03:00
Florian Müllner
cd99fbae50 extensionBase: Add static lookupByURL() method
With convenience API like getSettings() now being provided by
the ExtensionObject subclass, extensions will need to access
their entry point more often.

Having to pass a pointer through the hierarchy can be annoying,
so add a static method that allows them to look it up:

```js
    const ext = Extension.lookupByURL(import.meta.url);
    this._settings = ext.getSettings();
```

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2838>
2023-07-30 10:29:44 +03:00
Florian Müllner
3e4fd4b67a extensions: Add Extension/Preferences base classes
Extensions now must export a class that conforms to a particular
interface both for the actual extension as well as for prefs:

enable()/disable() methods for the former, fillPreferencesWindow()
for the latter.

This is quite similar to the previous method-based entry points,
but it also gives us a more structured way of providing convenience
API in form of base classes.

Do that in form of Extension and ExtensionPreferences classes on
top of a common ExtensionBase base class.

getSettings(), initTranslations() and the gettext wrappers are
now methods of the common base, while openPreferences() moves
to the Extension class.

Based on an original suggestion from Evan Welsh.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2838>
2023-07-29 15:20:20 +03:00
Florian Müllner
6a34b2636d dbusServices/extensions: Include dir and path in metadata
As we did for extensions in the previous commit, pass the path and
dir properties alongside other metadata to extensions preferences.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2838>
2023-07-29 15:20:20 +03:00
Florian Müllner
1c98a95974 extensionSystem: Include dir and path in data passed to extension
Extensions often need to set up additional resources from their
directory, like settings, translations or image assets.

So far extensions have used getCurrentExtension() to access the
shell's internal extension object which contains path and dir
properties. That's far from ideal, first because it requires
generating a stack to figure out the current extension, and
second because the internal object also contains state that
extensions shouldn't meddle with.

Just include those properties in the metadata we pass to the
extension constructor.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2838>
2023-07-29 15:20:20 +03:00
robert.mader@collabora.com
63c3f3e7be status/camera: New indicator
Add a new status indicator following the system-status-indicators
mockup.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2840>
2023-07-29 13:55:15 +03:00
robert.mader@collabora.com
02f1952851 status/volume: Split indicator into output and input
Use the new privacy indicator class for the input one and move it next
to the other privacy indicators.

While on it move all privacy indicators to the front, following the
system-status-indicators mockup.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2840>
2023-07-29 13:55:15 +03:00
robert.mader@collabora.com
cbcb56972f style: Generalize sharing indicator class
To have a shared style for various privacy related indicators.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2840>
2023-07-29 13:55:15 +03:00
Florian Müllner
1354d2cf56 extensions: Unify how manager is injected into shared module
We unified most code paths earlier, but the common code will still
import Main locally if no extension manager was injected before.

Now that the old extensionUtils was split between extension and
preferences, each of those modules can simply import the manager
from its corresponding environment, and then inject it into the
shared module.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2837>
2023-07-15 13:16:42 +02:00
Florian Müllner
3006c05ea5 extensions: Simplify openPrefs()
The module is now only used inside the gnome-shell process, so
we don't have to handle the case where it is used from prefs,
and we can use regular imports for shell modules.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2837>
2023-07-15 13:16:42 +02:00
Florian Müllner
6a46d338e7 extensions: Provide separate implementations
For the time being this mostly means re-exporting functions
from the shared module. However openPrefs() is now only
available to extensions, and we stop exporting both
getCurrentExtension() and setExtensionManager() to either
extensions or prefs.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2837>
2023-07-15 13:16:42 +02:00
Florian Müllner
55cf8cf4bb extensions/internals: Port to ESM
We got rid of all uses of extension utils code in the gnome-shell
process itself, and everything that is now using it - including
extensions - is already loaded as module.

We can therefore quickly move the file to ESM, which will help
a bit with upcoming changes.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2837>
2023-07-15 13:16:42 +02:00
Florian Müllner
d3f662fbf2 extensionUtils: Split out extension convenience functions
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>
2023-07-15 13:16:42 +02:00
Florian Müllner
23f525785c extensionUtils: Use non-legacy style
The file already largely conforms to the new style. Quickly fix
up the remaining issues before making any major changes.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2837>
2023-07-15 13:16:42 +02:00
Florian Müllner
4a0b0e26c7 extensionUtils: Move isOutOfDate() into manager
It hasn't been used anywhere else since the old prefs-tool stopped
implementing its own extension loading.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2837>
2023-07-15 13:16:42 +02:00
Florian Müllner
df350cab0a extensionUtils: Always use manager to find current extension
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>
2023-07-15 11:07:12 +00:00
Florian Müllner
10672597c2 dbusServices/extensions: Add basic extension manager
ExtensionUtils' getCurrentExtension() method currently either
returns the extension that was injected with setCurrentExtension(),
or imports Main locally to access the extensionManager.

But local imports won't work anymore when we convert to ESM,
and setCurrentExtension() is only an option for prefs.

Instead of diverging the code paths even further, we'll unify
the two cases as much as possible.

As a first step, add a basic extension manager in the Extensions
D-Bus service that exposes the same lookup() API as the "real"
extension manager.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2832>
2023-07-15 11:07:12 +00:00
Florian Müllner
cdd19a7773 dbusServices/extensions: Save stateObj on extension
We don't need it for anything for the time being, but reducing the
differences between extension object in the gnome-shell process and
in preferences still seems a good idea.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2832>
2023-07-15 11:07:12 +00:00
Florian Müllner
9e4de6a005 dbusServices/extensions: Don't use getCurrentExtension()
The prefs dialog is created on behalf of a particular extension.
It's a bit silly to rely on getCurrentExtension() to access it,
instead of just keeping track of it ourselves.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2832>
2023-07-15 11:07:12 +00:00
Florian Müllner
b4c2901e47 dbusServices/extensions: Check earlier for existing dialog
There is no point in making a D-Bus call if we are going to bail
out anyway.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2832>
2023-07-15 11:07:12 +00:00
Florian Müllner
3451c5a182 extensionUtils: Slightly optimize current extension lookup
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>
2023-07-15 11:07:12 +00:00
Florian Müllner
3289b79433 extensionUtils: Stop using RegExp for stack parsing
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>
2023-07-15 11:07:12 +00:00
Evan Welsh
c2c4d84fc1 dependencies: Migrate to ES module and organize dependencies
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>
2023-07-15 02:35:56 +00:00
Evan Welsh
7a5f1e5c9e layout: Add catch when asynchronously setting up the startup animation
This ensures any errors that occur in this stage of startup are clearly
logged.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2822>
2023-07-15 02:35:56 +00:00
Evan Welsh
3f12f3a87c scripting: Convert to ES module and migrate tests
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2822>
2023-07-15 02:35:56 +00:00
Evan Welsh
9a2c3da868 environment: Port environment.js to be an ES module
Removes the init() function in favor of executing all environment
changes when the file is imported.

Additionally ports all unit tests using imports.gi.environment.init() to
use the updated module.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2822>
2023-07-15 02:35:56 +00:00
Florian Müllner
011ac6f83c dependencies: Specify versions of Shell/St
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>
2023-07-15 02:35:56 +00:00
Evan Welsh
e2e3694cbd environment: Split dependencies loading into a new file
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>
2023-07-15 02:35:56 +00:00
Evan Welsh
87d1248dc1 animationUtils: Group together various animation helpers
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>
2023-07-15 02:35:56 +00:00
Florian Müllner
7eafc248cd lookingGlass: Evaluate command asynchronously
This allows using await in the command (or the header we
add to it), for example when handling Promises or importing
a module dynamically.

The latter will be crucial when porting to ESM.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2842>
2023-07-14 12:36:53 +00:00
Florian Müllner
85a8a6f46c lookingGlass: Reformat command header
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2842>
2023-07-14 12:36:53 +00:00
Florian Müllner
c0fbd74d07 jsParse: Make getCompletions() asynchronous
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>
2023-07-14 12:36:53 +00:00
Florian Müllner
13e20e47bf jsParse: Replace eval()
The evil() function is considered eval, replace it like we
already did in looking glass.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2842>
2023-07-14 12:36:53 +00:00
Evan Welsh
a66ffcfc74 jsParse: Use JSDoc to document functions
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2842>
2023-07-14 12:36:53 +00:00
Florian Müllner
561d0d3758 lookingGlass: Handle completions asynchronously
They will actually become asynchronous in a following commit,
prepare for that.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2842>
2023-07-14 12:36:53 +00:00
Florian Müllner
03025d7cff lookingGlass: Handle unprintable object
We currently throw an error when encountering a result that cannot
be represented as string, with the prompt appearing somewhat stuck
(the input cannot be committed).

Showing a lame fallback instead at least avoids that issue. When
the object has a typeof 'object' but is not an instanceof Object,
we are likely dealing with an ES module, and can show a slightly
less lame fallback.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2842>
2023-07-14 12:36:53 +00:00
Lukáš Tyrychtr
a5cf08ac55 a11y: Don't create a parent loop for quick settings sliders
Rather than returning the parent container of the slider, which presents
itself as the slider, return the parent of the slider container.

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6686

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2762>
2023-07-13 18:15:16 +02:00
Carlos Garnacho
04aaa4b67b keyboard: Spawn "tecla" to show keyboard map
This is a modern replacement for gkbd-keyboard-display, stuck in gtk3
and X11 (libxklavier).

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2834>
2023-07-11 15:06:19 +02:00
Florian Müllner
d52b1576ac main: Replace custom log function with console
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>
2023-07-10 09:59:58 +00:00
Florian Müllner
f07bf7b1b6 main: Remove log compatibility
global.log() hasn't been used since 3.6. It seems extremely unlikely
that any extensions are still using it, not least because `log()` is
more convenient.

Time to move on.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2830>
2023-07-10 09:59:58 +00:00
Florian Müllner
b854c1bdbb extensionSystem: Fix signal disconnection
The ::shutdown signal is on Shell.Global, not Meta.Context 🤦️

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2831>
2023-07-09 22:45:03 +02:00
Evan Welsh
812378a00d dateUtils: Refactor so all utilities use cached local timezone
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2827>
2023-07-07 18:58:35 -07:00
Evan Welsh
8d48dc8c6f environment: Remove toLocaleFormat and add dateUtils for date formatting
`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>
2023-07-07 18:58:34 -07:00
Evan Welsh
88eb04a42c dateMenu: Fix lint errors prior to refactor
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2827>
2023-07-07 18:32:50 -07:00
Florian Müllner
e7d290bbfb tests: Stop bundling "perf" tests with gnome-shell
Now that scripts are loaded as external modules, there's no reason
anymore for bundling them with the gnome-shell executable. Just
move the scripts into a dedicated folder in tests/ and run them
from there.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2812>
2023-07-07 19:43:28 +02:00
Florian Müllner
bf9b9838c2 main: Pass script on CLI instead of via environment
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>
2023-07-07 19:43:28 +02:00