Create a derived workspaces adjustment using the new API, and
bind it to the 'progress' property. This is only done by the
MonitorGroup representing the primary monitor.
The progress value that WorkspaceAnimation operates on
represents the percentage within the workspaceIndices array
we are, so make sure to transform the percentage to the
correct workspace index.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2881>
The getter of the MonitorGroup's 'progress' property sets
some values based on it, but doesn't notify the property
change.
Fix that by calling this.notify('progress') when the setter
is called.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2881>
Derive the workspaces adjustment used by OverviewControls (and
shared with WorkspacesView) from the main workspaces adjustment
using the new Main.createWorkspacesAdjustment() method.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2881>
And a way to derive "sub"-adjustments from the main one.
The main and private StAdjustment properly represents
workspaces, and has all relevant properties (lower, upper,
and value) set by the workspace manager.
The main adjustment is not bound to any particular actor,
which means we cannot call the 'ease' method directly.
Consumers of this API should create adjustments using
Main.createWorkspacesAdjustment(), and this new adjustment
is bound to the actor that the consumer passed. Consumers
must not change any property of the derived adjustment other
than the 'value' property.
The 'value' property is synchronized between all adjustments
created, which guarantees that all elements that represent
workspaces can have a shared and up-to-date understanding of
where in the workspace layout we are.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2881>
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>
Out of the members of the notification daemon(s), these are the most
necessary and flexible to override. The daemons are used as singletons
and notifications are rather temporary, while the sources are more
flexible and make the most sense to override (and revert).
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2869>
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>
We sometimes obtained the current event through the general machinery
just so we could pass it along as a ClutterEvent instead of a specialized
subtype.
We now get that out of the box, so may avoid getting the current event
which is just a cast of the same current event we already have.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2872>
These traditionally got the various ClutterEvent subtype structs as their
argument, so it was not allowed to use ClutterEvent generic getter methods
in these vfuncs. These methods used direct access to struct fields instead.
This got spoiled with the move to make ClutterEvent opaque types, since
these are no longer public structs so GNOME Shell most silently failed to
fetch the expected values from event fields. But since they are not
ClutterEvents either, the getters could not be used on them.
Mutter is changing so that these vmethods all contain an alias to the
one and only Clutter.Event type, thus lifting those barriers, and making
it possible to use the ClutterEvent methods in these vfuncs.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2950
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2872>
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>
The custom setter used by the slider item isn't emitting change
notifications, so the property binding that uses it as source
never propagates the new value.
Fix this by emitting proper change notifications.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2856>
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>
