We have always defaults to an empty ornament, so that menu items
are always aligned, even when radio items are used.
However radio items are fairly rare, so most of the time we end
up with an extra margin with no purpose. The design team now
prefers radio items to only align with each other, so that regular
items get the expected margin.
Change the defaults accordingly.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2843>
Soon only radio items should use a visible ornament, to avoid
unnecessary extra margins in regular items.
Network items can act as both radio- and regular items, so
update the ornament accordingly.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2843>
Layout items use the ornament to indicate the active layout, so
their ornament should always be NONE or DOT.
The default is about to change to HIDDEN, so explicitly initialize
the ornament to NONE to keep the current radio item appearance.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2843>
Settings no longer exposes a slider for the keyboard brightness,
leaving keyboard shortcuts as the only way of adjusting it.
This is good enough in most cases, because devices with keyboard
backlight usually include corresponding keys on their keyboard.
However for devices without those keys, it would be good for the
settings to be exposed somewhere again. Quick settings seems like
a more appropriate place than "proper" Settings, since it gives
quick access that doesn't require a major focus change.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6765
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2820>
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>
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>
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>
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>
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>
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>
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>
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>
