Space will be less of a concern when each sections becomes its own
menu, but it's still not infinite. To address this, enable MRU
tracking and limit the list to the eight most recently used items.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2407>
Devices do not have an associated timestamp, but as we can now
track the MRU order of their connections, it makes sense to consider
the time of the most recent succesful connection the timestamp
of the device item.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2407>
We always display items sorted by name, but there are cases where a
second order by recency is interesting. Add an option to ItemSorter
to keep such a list and allow accessing it with another generator
function.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2407>
Connections have a timestamp property, which records the last time
it was succesfully activated. This is useful information to us, as
more recently used connections are likely more relevant than ones
that haven't been used for a long time (or not at all).
To make use of it in the future, expose that timestamp as a property.
Only connections support it, but we will soon provide a reasonable
value for devices as well, so add the property to the base class.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2407>
Eventually each section will turn into its own menu, which should
include a single settings item.
This also removes the odd duplication of items, now that we avoid
using submenus where possible.
In general this is straight-forward, except for modems: Some
models are now supported by a dedicated wwan panel, while others
still use the generic network one.
Address this by adding items for either panel, but only show one
at a time. The new panel is used if *any* modem is supported,
only when all modems require it, the legacy panel is used.
Hopefully that shouldn't be an issue for many users, as using many
different modems with different capabilities should be fairly rare
(except for Aleksander Morgado, but I think he can handle it)
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2407>
We currently stopped using submenus altogether, but that only works
- if there is a single connection that represents
the device as a whole
- if there is just one device, so it is unambiguous
what device items belong to
To implement that behavior, add a 'single-device-mode' property that
NMDeviceSection can set on its items, and have items update their
'use-submenu' property based on that.
For wireless devices it's a straight mapping, as its items represent
wireless networks that can appear and disappear by just walking around
(multiple wifi adapters also sounds rather fringey).
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2407>
Now that device sections manage a list of items, and the VPN section
manages a list of items, it's time to split out a shared base.
The class will get more involved over time, and eventually become
the base of all network quick items.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2407>
We got the indicator out of the business of tracking connections,
now it's time to do the same for devices.
Let sections track device additions and removals, and create device
items for them as it sees fit.
It also allows the sections to handle the ::activation-failed signal
by themselves, instead of passing it on from device items.
With this, the indicator is now solely responsible for global state:
Manage the top bar indicators, notify on connection failures, and run
the portal helper when NetworkManager detects a captive portal.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2407>
As mentioned when doing the same for VPN connections, it is currently
the indicator itself that keeps track of added and removed connections.
It then has to figure out the correct section, and iterate through all
its device items so each item can check whether the connection
corresponds to its device.
Stop that mess, and let each device item keep its connections updated
by itself. That is actually way easier, as NM.Device already exposes
available connections through a property, so we can get rid of all
the checkConnection() shenanigans.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2407>
We currently wait until we got a connection to NetworkManager.
That's possible because the old PanelMenu indicator API takes
a menu, so it is possible to add or remove items dynamically
later.
That won't be the case with quick settings, where `quickSettingsItems`
is a plain array that is only read once when adding the indicator.
Prepare for that by moving section initialization into the constructor.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2407>
Now that wi-fi devices will be handled by a separate menu toggle
instead of as part of a combined system menu, there is no longer
a need of delegating network selection to a separate dialog.
To keep the menu from growing too much, the (sorted) list of
displayed networks is kept at a limit of eight. There is always
Settings for a complete list…
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2407>
In terms of UI, this means that in the common case where we have
a single (or no) connection, the device can be represented as a
single menu item rather than a submenu.
But more importantly, all our menu items inherit from the same
GObject class now, so we can use bindings where appropriate.
This will later extend to quick toggles as well.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2407>
The class implements a menu item that contains a section which
can be collapsed into a submenu.
It is very common for network devices to only have one associated
connection, so hiding away a single item in a submenu is fairly
inconvenient.
This class will address this, by only using a submenu when it is
actually needed.
Although the main issue it addresses is that menus (including
sections) aren't GObjects. This gives us a GObject that can
be added to a menu, and that can itself contain other menu
items.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2407>
The class only provides the GObject properties that are currently
defined by NMConnectionItem, plus a way to set the active connection
that should be used for the item's :is-active state.
Its sole purpose is to provide a shared base for both device- and
connection items, and to have that base be a GObject so we can
start linking properties via bindings rather than manual fiddling.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2407>
Let's keep things simple and use the same appearance regardless
of the number of configured VPNs. Also unlike for device items,
every connection item in the VPN section is a toplevel item, so
there isn't a real need for different presentations.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2407>
The NMConnectionSection class is used - surprise - to manage a
list of related connections. And while the presentation of VPN
items is slightly different from connections associated with
devices (switches vs. ornaments), it makes perfect sense for
the VPN section to share the nitty-gritty with the base class.
But…
Right now it is perfectly fine for NMConnectionSection to be
used both as a child element in a device section, and as toplevel
item of the VPN section. Any nesting of sections is entirely
transparent to the user, and all connection sections appear as
submenu items in the toplevel menu.
That won't work for quick settings.
There's no PopoverMenuSection that allows invisible grouping, so
adding items dynamically would either need to happen at the end,
or require some tricky cross-component code to impose a particular
order.
And last but not least, quick toggles are very much unsuited for
a potentially large number of items. The whole point is to provide
quick direct access to system features, not to compete with menus
over the number of items they can hold.
That is, we need to get from the current state where each device
appears as a toplevel item, to a state where we have one quick
toggle for each device type plus one for VPN.
The decoupled VPN section still behaves largely as it did as a
subclass, with the notable difference that it no longer uses
a submenu item, so all VPN connections now appear at the toplevel.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2407>
Right now the indicator itself tracks all devices and connections,
creates and destroys the corresponding menu items, matches them
to a section and updates the connection/device arrays that are
attached to the section.
Sounds messy?
It is slightly less effective to connect multiple handlers to the
same NMClient, but let's assume that devices and connections aren't
added/removed at 60 frames/s, and we can add some readabilty by
moving the code into different classes that only have to care about
the bits that are relevant to them.
The VPN section is a good starting point, because its handling is
already quite different from device sections.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2407>
At its core, it's the sort order tracking from NMConnectionItem
with a bit of sugar on top to provide access to the ordered items
and the ability to provide a custom sort function.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2407>
You could argue that the item name is closer to what is displayed
to the user, but it doesn't really matter: Connection items will
always use the connection ID when there is more than one, which
is the only case where sorting matters.
However sorting by items will allow us to generalize the code, and
use it for items that do not represent a connection.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2407>
When not in radio-mode - that is, when the connection is the only
connection for its device - we want the item to represent the
device as a whole.
Achieve this with a small ConnectionItem subclass that adds a
:device-name property for that purpose.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2407>
When not in radio-mode - that is, in the single-connection
case - the item currently uses a plain 'Connect' label.
That is OK while the item is inside a submenu that describes
the device, but we will soon stop using a submenu when a single
item can describe the device as a whole.
Prepare for that by adding an icon that is shown when in non-radio
mode, and include the device name in the label in that case.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2407>
Newer versions of IBus (> 1.5.26) have the IBUS_CAP_OSK capability
which can be used to hint the active IM about an OSK driving input as
opposed to a physical keyboard. This may be used by IMs to tweak their
behavior to suit OSKs better.
Add the GNOME Shell side handling for this capability, and toggle it
on whenever the OSK is visible.
Since this is a far too new enum value and we don't want such new
IBus dependency, this change plays fast and loose with JS guarantees,
since a logical OR with an undefined value results in the other operand
unmodified it will work for older versions where the capability does not
exist and thus we want nothing extra enabled.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2415>
We are calling _loginScreenSessionActivated() even in cases where this is
not required. For example, there are cases where the Active property is
already `true` and properties like `IdleHint`, `IdleSinceHint` and
`IdleSinceHintMonotonic` change. In this cases _loginScreenSessionActivated()
is called and will reset the authPrompt when not necessary.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2411>
We do want to update the best AP on strength change, in case we
can switch to a better one.
But even if we can't and the AP is unchanged, the icon should
be updated to reflect the change.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2414>
Right now DeviceCategory is a small section wrapper that shows
a summary instead of its content if it contains too many items.
It will eventually eventually turn into the base class for
network device quick toggles. Who would have thought that
when it was added for the "there's a computer with 32 ethernet
cards" fringe case?!
For now, give it a more appropriate name and use device types
instead of our made-up categories, now that the two map neatly.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2406>
It's odd to swap out a switch with a status label, and the
information isn't that helpful to begin with: It's either
transient (connecting, deactivating, ...), or too little to
be meaningful (unknown, failed, ...).
We're also perfectly happy to not show it in "label mode"
(i.e. when there's just one VPN).
Just get rid of it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2406>
Stop providing detailed state descriptions, instead use a name
that best represents the device at the moment (like a wifi SSID,
the carrier name, or the device name as determined by network manager).
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2406>
The _devices property is another case of overloading the
"device" term.
Fun fact:
this._devices[device._delegate.category].devices
uses three different meanings of "device" (section, NM.Device, item).
The devices array in sections won't be around for much longer,
but the property that tracks the sections is worth renaming.
While at it, use a map instead of a plain object, which has a
guaranteed order when iterating (which will come in handy later).
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2406>
Different access points can belong to the same wireless network. As
NetworkManager doesn't handle this for us, we need to track networks
ourselves, and we currently do this using ad-hoc object literals and
monkey-patching.
Clean this up by factoring out a proper WirelessNetwork class, and
associate them to items with a map.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2406>
Interpreting the different flags is better left to the domain
experts at NetworkManager. It is also much more likely that
NM's own functions will handle newly added flags than our own
code.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2406>
There is a straight mapping between running/enabled and visibility,
so bind them instead of using a signal handler.
_syncConnectivity() is called both from _syncMainConnection() and
on connectivity changes, which should cover any running/enabled
changes.
That just leaves updating the icon on state changes.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2406>
We would want the signals to be disconnected if we ever happened to
destroy the indicator. Even if we don't, connectObject() is simply
nicer when connecting half a dozen handlers at once.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2406>
There is only one case where we show a notification: When activating
a connection failed.
There is therefore no reason for a generic wrapper around the
notification API. Likewise, tracking the source is a bit pointless,
given that the notification is transient. In fact, as we destroy
an existing notification *before* checking for the source, any
previous source will be gone by that point.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2406>
The function is a handler for the `notify::state` handler, so
the state and reason parameters used in the checks are always
undefined.
In addition, `DEACTIVATED` is not (just) a failure state. We
clearly don't want to complain about a failed connection when
the change happened on request of the user.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2406>
We never used it, so after more than ten years, it seems safe to
assume that we never will.
Plus different items pass different types, which makes it pretty
much impossible to use, even if we wanted to (which apparently
we don't 🤷️)
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2406>
When deciding on whether to show the 'no-route' icon, we check
for the client's connectivity *and* whether the devices's active
connection is used as primary connection.
This is currently masked by the indicator updating the icon on
connection changes anyway, but items should still notify the
change themselves.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2406>
The wireless device item tracks the active access point in order
to update its icon on signal strength changes.
However we currently don't synchronize the initial state, so we
miss strength changes until the first access-point change.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2406>
Otherwise any unrelated errors in that function are hidden,
because exceptions in async functions are turned into promise
rejections (and JS cannot know that we won't handle it at a later
point).
It wouldn't happen to me of course 😉
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2406>
I wasn't genuiously going to touch those lines, but I ran into
a limitation of the run-eslint script:
It currently bases changed lines on a diff between HEAD and main
instead of the commit-by-commit log.
The two can vary quite a bit when shuffling code around, and those
are the lines the tool kept complaining about.
I'll look into improving the script, but for now it's quicker to
just shut it up by fixing up the complaints.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2406>
There isn't always a serviceName when we set a message. Furthermore we
are passing the serviceName only to decide if we want to wiggle or not.
Pass the wiggle parameters instead. If they are missing, we don't want
to wiggle.
This fixes the following error:
JS ERROR: Exception in callback for signal: login-format-changed: Error: Wrong type number; string expected
setMessage@resource:///org/gnome/shell/gdm/authPrompt.js:542:13
_showRealmLoginHint@resource:///org/gnome/shell/gdm/loginDialog.js:931:26
_emit@resource:///org/gnome/gjs/modules/core/_signals.js:114:47
_updateLoginFormat@resource:///org/gnome/shell/gdm/realmd.js:85:18
_reloadRealm@resource:///org/gnome/shell/gdm/realmd.js:57:14
_onRealmLoaded@resource:///org/gnome/shell/gdm/realmd.js:64:14
_makeProxyWrapper/</<@resource:///org/gnome/gjs/modules/core/overrides/Gio.js:245:34
Fallout from 526f0711f1.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5547
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2404>
Now that the old system menu has been ported over, we can move
the power toggle to its intended place. The main difference to
the stand-alone toggle is that the button now uses its natural
size rather than the fixed size of regular quick items.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2393>
This port is a bit messier than the previous ones, because the
existing menu section translates less directly to the new UI,
which uses a row of individual toggles for settings, lock and
shutdown.
In order to not complicate the grid layout further by supporting
rows with a different number of columns than the overall grid and
children at their natural size, create a custom, non-reactive
SystemItem item that spans an entire row, and contains the individual
toggles.
This works quite well, even with the shutdown item that uses a menu
for the various actions.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2393>
With menu support in place, this is now a straight-forward port:
Just add the existing profiles section to a QuickToggleMenu instead
of a submenu item.
The toggle itself now switches between 'balanced' and the last used
non-default profile.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2393>
Now that the QuickSettingsMenu supports child menus, it is time
to add menu support to quick toggles.
Do that by introducing a QuickSettingsItem parent class with a
construct-only :has-menu property, as that will allow including
menus in items that aren't following the standard icon+label
pattern of QuickToggle (yes, we'll have some of those).
A common parent class also allows us to control the type of
menu that is created. That's important, as we need another
custom menu type to
- constrain the menu's y position to place it underneath
the source actor
- use open/close animations taylored for this use case
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2393>
This is where it gets hairy.
Some quick settings items will have an associated menu. When
opened, the main menu should grow to make room for the child
menu, as it would do if it contained the child.
At the same time, the child menu will attach to its parent, and
block all input there while it is open.
Menu-modal menus so to speak.
Implement this as follows:
- change the QuickSettingsMenu actor to a stack that holds
- the boxpointer (a.k.a. the actual menu)
- an overlay actor to hold child menus
- use constraints to bind the overlay's position and width
to the boxpointer; the y position is offset to align the
overlay with the grid inside the actual menu
- add a placeholder actor to the main grid, whose height is
bound to the overlay height; using a "clone" instead of
the actual overlay means that layout changes are not triggered
from outside the grid hierarchy, which would be prone to
allocation warnings
- update the layout manager to not allocate the placeholder as
a regular grid child, but instead include its height in the
space underneath the row with an open menu
- apply a dim effect to the boxpointer when a child menu is
open, to indicate that input is blocked
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2393>
WorkspaceBackground's allocate is a hot function called every frame
during overview animations. Port it to C.
While we're at it, cache the work area and the monitor geometry, which
do not need to be re-fetched on every allocation.
This reduces the average WorkspaceBackground allocation time from
0.134 ms to 0.017 ms. With four workspaces, scrolling the overview sees
an average WorkspacesView allocation time improvement from
1.104 ms to 0.678 ms.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2394>
The aggregate menu with its submenus isn't well-suited for simple
on-off actions, so we didn't expose the global color-scheme support
that was introduced last cycle.
Quick settings on the other hand are a natural fit for actions like
this, so add a corresponding toggle.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2392>
The power indicator should not be a regular quick toggle, but
instead be part of a "system area" row at the top of the menu.
But as in the end it is still a simple button, we can do the
port to quick settings now, and move it later when the system
row is implemented.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2392>
For now, this is another simple toggle. The icon, state and
visibility reflect what the old menu did, and the top bar
icon is still only shown when devices are currently connected.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2392>
Another simple toggle. Unlike the old menu, it is always shown
if airplane mode is supported, not just while airplane mode is
active.
We still only show the top bar icon while airplane mode is on.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2392>
Night-light is now a simple, always visible toggle that directly
controls the underlying setting. No change to the top bar icon,
which is still only shown while night-light is active (read: at night).
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2392>
Like the aggregate menu currently, the quick settings menu will
eventually contain some items that should dismiss the menu. And
as those items may appear in child menus or otherwise be nested,
a public method on a global object is more convenient than handing
the main menu down the hierarchy.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2392>
The new indicator will eventually expose all the system status
items that are currently provided by the aggregate menu, but in
a more accessible form than the current submenu-heavy menu.
Right now this just adds the new empty indicator to the top bar,
alongside the existing aggregate menu.
We can then move items over one-by-one.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2392>
The quick settings menu is a popover that arranges items in a
reflowing, homogeneous grid. Grid children may span multiple
columns, but not rows.
For now the QuickSettingsMenu that contains the grid is just a
convenience wrapper around the layout manager that does the heavy
lifting. The two will become more intertwined when we add support
for menu toggles though, so the custom menu type is unfortunately
needed.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2392>
Multiple booleans - both in arguments and return values - are almost
always problematic API, because people have to memorize (or more likely
look up) the meaning of each position.
Instead, return a JS object so each value has a name attached to it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2370>
After porting the more complex cases - in particular those that
affect a module's API - we are left with straight-forward D-Bus
method calls that can be moved to promise-based wrappers in one
go.
For consistency, this also switches from Remote to Async where
the call result is ignored.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2344>
The LoginManager abstraction is still mostly callback-based, not
least because the methods are thin wrappers around logind D-Bus
calls.
However as gjs' dbus wrapper now generates promised-based wrappers
as well, we can implement a proper async API just as naturally.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2344>
Thanks to recent gjs changes - namely the ability to promisify
interface prototypes and promise-based D-Bus wrappers - we can
modernize the ContentTypeDiscoverer API to use an async function
instead of a callback.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2344>
Our search provider API has to be asynchronous to support remote
providers. It doesn't have to be based on callbacks though, now
that async functions provide a nicer alternative.
That is particularly true after gjs's D-Bus wrapper started to
generate promise-based method variants.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2344>
Provider loading has been synchronous since 2013, so we can
just as well return the results directly instead of passing
them to a callback.
Even if we returned to asynchronous loading in the future,
we wouldn't want to use a callback, but make the function
itself async.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2344>
There are a couple of places left where we still use the old
indentation style, update them before making code changes.
After that, there are only a couple of non-type-safe comparisons
left of legacy style, so change those as well while we're at it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2344>
The latest mockups move the screen sharing indicator into a
separate control, similar to the existing indicator for built-in
screen recordings.
As this removes the submenu and only keeps the top bar icon (for
external screen recordings), this will smooth the transition to
quick settings.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2391>
Location services aren't expected to change frequently: They are
either disabled globally, or permissions are granted on a per-app
basis.
This is less of a concern while the setting is exposed in a small
submenu, but as we moving to quick settings, it does not deserve
the prominence of a quick toggle. Just the top bar icon and Settings'
privacy panel should be enough.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2391>
Other than connecting stream when necessary, the volume menu
only forwards slider events to the indicator, and method calls
from the indicator to the appropriate slider.
Just cut our the middle-man and let the indicator handle the
slider items directly.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2391>
On error, we currently print a warning and bail out early. That
means we don't hide the slider, despite it being non-functional
without the proxy.
Fix this by making sure _sync() is called in any case. While at
it, use an appropriate log level for the warning message.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2391>
Properties are null while a proxy has no owner. Javascript helpfully
coerces that into `Number(null)` (a.k.a. 0), so we end up with a
broken slider.
Explicitly check that the value is an integer before doing the
comparison to catch that case.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2391>
The new class abstracts away the nitty-gritty of bluetooth- and
airplane-mode handling, and exposes just what the UI needs.
This will become more important with quick settings, where there's
a stronger separation between top bar icon and quick toggle.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2391>
There's no good reason for waiting for the proxy to be initialized
to connect signals. In fact, connecting the signal beforehand
ensures that the handler is in place when the proxy fetches the
properties, so we don't have to call the handler explicitly.
That in turn allows us to rely on the signal parameters to only process
changed properties.
To achieve that, construct the proxy manually, and then initialize
it asynchronously in a Promise.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2391>
There's no good reason for waiting for the proxy to be initialized
to connect signals. In fact, connecting the signal beforehand
ensures that the handler is in place when the proxy fetches the
properties, so we don't have to call the handler explicitly.
That in turn will allow us in a follow-up to rely on the signal
parameters to only process changed properties.
To achieve that, construct the proxy manually, and then initialize
it asynchronously in a Promise.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2391>
Don't try to initialize and then enable an extension if it is not supported
in the current mode. Otherwise the extension will not be initialized, and the
initial ERROR state is not cleared. Once it is in ERROR state we can't enable
it anymore when we switch mode. Instead, leave the extension in INITIALIZED
state, so that it will be initialized when appropriate. This happens for
extensions that support the unlock-dialog mode but not the user mode.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2378>
Screenshots use `%Y-%m-%d %H-%M-%S` for the timestamp, which has the
advantage of allowing proper lexicographical sorting.
The screencast file name pattern, on the other hand, uses
locale-dependent expansions, which break sorting based on file name, and
introduces the chance of potentially invalid characters on different
file systems.
Fixes: #5115
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2300>
`ShouldShowAirplaneMode` only considers whether airplane mode
should be shown for the form factor, not whether there are
any actual kill switches available.
That's tracked in a separate property, `HasAirplaneMode`.
Take that into account for our `:show-airplane-mode` property,
so that it reflects when airplane mode should and *can* be shown.
Right now we only show airplane mode when it is enabled (and
therefore available), but this will change in the future.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2385>
There's no good reason for waiting for the proxy to be initialized
to connect signals. In fact, connecting the signal beforehand
ensures that the handler is in place when the proxy fetches the
properties, so we don't have to call the handler explicitly.
That in turn will allow us in a follow-up to rely on the signal
parameters to only process changed properties.
To achieve that by constructing the proxy manually, and then
initialize it asynchronously in a Promise.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2385>
In case where there are multiple in- or output devices, pulseaudio
or pipewire can pick the "wrong" one by default.
Allow users to change devices without opening sound settings by
adding a submenu to the sliders when there is more than one device.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2380>
Since IBus does not provide this information right away, we
so far cannot do much about providing a truthful anchor position
for the preedit text. But with the Mutter API in place it will
be up to this object to do so in the future.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2384>
This behavior dates back all the way to the original gnome-shell
release, and it did make sense at the time:
- we were first to make notifications persistent instead of
closing them after a timeout; apps were therefore used to
treat notifications as fire-and-forget instead of closing
them when no longer relevant
- neither web notifications not portals did exist yet, so the
D-Bus API was only used directly, instead of as a backend
for other APIs; as a result, focusing the app was more likely
than not to put the source of the event that the user was
notified about into view
Nowadays both persistent notifications and web notifications
are wide-spread, so the original reasons no longer apply.
This change helps web notifications in particular, as it reduces
the differences between XDG and portal-based implementations.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2332>
GNOME Shell will only update extensions if the org.gnome.Extensions
app is present. This commit adds alternative support for
com.mattjakeman.ExtensionManager to the extension updating mechanism.
It enables updates to occur when extension-manager is the sole installed
tool on the system. When both applications are installed,
org.gnome.Extensions is preferred at all times.
Fixes#5564
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2358>
The logging function cannot be asynchronous, so move the override
into main.js where ExtensionUtils can be imported at the top level.
Importing ExtensionUtils in environment.js at the top level is not
possible because it would import Main prematurely.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2363>
ES modules do not allow exports to be overriden, in anticipation
of the ESM port add a `setCurrentExtension` utility which will
throw if used in the shell. This is tested using a conditional
import of Main.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2363>
We considered any ConnectFlag value major than SWAPPED as invalid, while
it's technically not fully true as we need to ensure that the passed
value is respecting the whole flags mask.
In fact, per se SWAPPED|AFTER (> SWAPPED) is a valid value (even if we
don't support the AFTER value).
But this makes the check more future-proof.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2366>
While untracking an object we used to compute it's proto for each signal
we were disconnecting from, while this is not needed when we're just
iterating over all the same owner signals, so let's add few more
functions to compute an object prototype, and repeat the disconnections
in the simplest way we can.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2366>
We used to create a temporary array of signal tracker keys and then to
iterate through them in order to untrack the objects, but the Map's can
be iterated directly so let's just use their native forEach.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2366>
Introduce a new class, EventEmitter, which implements signal
handling for pure JavaScript classes. EventEmitter still
utilizes GJS' addSignalMethods internally.
EventEmitter allows static typechecking to understand the
structure of event-emitting JS classes and makes creating
child classes simpler.
The name 'EventEmitter' mirrors a common name for this pattern
in Node and in JS libraries.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2043>
If we only raise screenshot UI to top, ibusCandidatePopup can still
cover screenshot UI because each time ibusCandidatePopup updates it's
visibility it will raise it to top and this also happens if we open
screenshot UI via keybinding. This commit fixes it by only raising it
above keyboardBox, because keyboardBox is above all entries in modal
dialogs.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2331>
ibusCandidatePopup actually works as a top chrome because it always
raises itself above top_window_group when updating visibility, so just
initing it as a top chrome instead of initing it below top_window_group.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2331>
The overviewGroup's size is currently determined by the coverPane
actor. That actor is only shown during transitions, so we rely on
ClutterFixedLayout including hidden children in its size request.
That odd behavior is about to change, so we need to make sure the
overview still requests the correct size.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2351>
When a window with a modal dialog gets minimized and at the same time
the dialog is closed, the WindowDimmer undim animation starts and gets
cancelled when the minimize animation is done, because that unmaps the
window actor.
In this case we want ensure the dimming effect still goes into a
proper state instead of being stuck mid-animation, so listen to
onStopped instead of onComplete for syncing state of the window dimmer.
While at it, clean things up a little and move the check for the
attach-modal-dialogs pref inside the _syncEnabled() function.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5581
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2349>
Right now, we don't pay much attention to visibility hints from IBus
about the candidates list for the OSK suggestions bar. Since some
IMs rely on this visibility being honored, do that.
To fix this, the visibility hints for the lookup table are now
propagated to the keyboard, so the Suggestions actor hides its
internal candidate buttons. Since the Suggestions actor gets its
minimum height from CSS, this does not result in OSK size jumps.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5601
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2347>
There is no hint about the currently selected language, but this exists
in the mockups. Add a dot ornament on the language that is currently
selected at the time of showing the OSK languages popup.
Since this popup is created from scratch every time it is shown, and
the popup is torn down with the OSK during replacement. This also
works for further times the languages popup is shown.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5598
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2346>
When calculating the on screen coordinates of events from the window
relative coordinates, using the frame rect will include the decorations
added by the WM for SSD windows. This was causing the calculated
coordinates to be slightly off. Fix this by using the client rect for
SSD windows.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2319>
Absolute screen coordinates are impossible for Wayland clients to
provide, because the clients don't know where the window is positioned.
Some clients, such as the ones using GTK 3 were providing window
relative coordinates even when screen coordinates were requested,
while others, such as GTK 4 clients, were just returning an error for
caret events or also window-relative coordinates for focus events.
So for this to work on Wayland we have to request window-relative
coordinates and translate them to the current focus window.
To ensure the correct coordinates, we have to only consider events
coming from the current focus window. All other events are filtered out
now. As a side effect this also fixes the magnifier always jumping
to a terminal cursor whenever there was some output, even if the window
was not focused.
This also needs some special handling for events coming from the shell
itself, which should not be translated to the focus window either. As
another side effect this fixes another bug that was caused by these
events already including scaling and getting scaled again.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5509
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2301>
If we don't set the height property to -1 before requesting the
preferred height, get_preferred_height() will just return us the fixed
height that has been set before. We don't want this behavior here, so
set the height to -1 before calling get_preferred_height().
This fixes a resizing issue where the keyboard is sized incorrectly
after switching the monitor into portrait mode and back.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2306>
Both bluetooth and screencast support are based on build checks
right now. However in both cases, the dependency is only consumed
at runtime via the typelib, so let's actually check for that.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2297>
We currently decide at build time whether to include screencast
support, based on whether the required gst/pipewire library headers
are installed.
That check is imprecise, because having the library headers available
at build time doesn't necessarily mean that the libraries are there
at runtime, or that the corresponding typelibs are installed.
It makes more sense to check the requirements at runtime, so prepare
for that by installing the screencast service unconditionally, but
bail out early if the dependencies aren't met.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2297>
The problem is that " 9:59 AM" (notice the space at the beginning) and
"12:59 AM" strings, when centred, look misaligned —
strings padded with a space look off to the right by nearly
half a character. This happens because the font feature "tnum",
used to make numbers monospace, doesn't work on spaces.
The commit overcomes this by aligning time labels to the end.
However, this won't work for locales with AM/PM strings of different
lengths, so they are aligned to the start instead to minimise offset.
It's too complex to know whether the used locale has different
AM/PM string lengths. Instead, every time the time changes, it
determines whether all the time labels have the same amount of characters.
Fixes#5438
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2294>
We update the visibility on state or stream changes, but those
changes may never happen if pipewire-pulse/pulseaudio isn't
available (for example when running as root).
Hiding the sliders is preferable in that case to showing non-working
controls.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2295>
When selecting the largest possible icon size for restricted vertical or
horizontal space the options for low resolution icons were rather coarse
grained. This could often result in seemingly too small icons being
chosen in the app grid on systems with low vertical resolution, because
the next larger size would exceed the limit by a few pixels.
This adds two more commonly used sizes for application icons to have
some more options with restricted space.
Helps: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2173
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2289>
Commit 7419674b changed some grabs from requiring both mouse and
keyboard grabs to be considered successful to only requiring either of
them.
Due to this it was possible for example to open the overview or the
screenshot UI with a client (such as Chrome when opening a menu) holding
the mouse grab. This then made it impossible to interact with the UI
using the mouse (or keyboard) and if attempted could result in an
unresponsive UI.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5414
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2287>
Commit ca4f6e0123 was supposed to show the
"cellular-disabled" icon when wwan is disabled. For wwan, just like for
bluetooth wwan networks, we probably want this to include the "not
connected" state, because disconnecting from cellular service de-facto
means disabling it.
So switch the check to show the "cellular-disabled" icon to also use the
icon whether there's no active connection, not only when the wwan device
is turned off.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5401
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2283>
The swipeTracker wants the distance between two pages passed to it in
confirmSwipe(). In case of the app grid, the correct distance is not the
size of the scrollView (which has the width of the whole screen), but
instead the allocation size of the iconGrid (which is the actual size
of a page in the grid).
So pass the allocation size of the iconGrid to the swipeTracker, this
makes sure the pages move perfectly in sync with the pointer when
dragging using the mouse or touchscreen.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2275>
With commit c29e0cf6e6 the grabHelper
already started using a similar mechanism to funnel events to the osk
while a ClutterGrab is in effect. ModalDialog, the unlockDialog and
lookingGlass don't make use of the grabHelper though, they use
Main.pushModal() themselves, so those need to funnel the events to the
OSK themselves.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2263>
We currently complete the animation using an onComplete handler,
which only runs if the corresponding transition was stopped when
finished.
While it is unexpected that the transition is interrupted, it can
apparently happen under some circumstances (like VMs with qlx).
The consequences of that are pretty bad, mainly due to the cover
pane that prevents input during the animation not getting removed.
Address this by always completing the animation when the transition
is stopped, regardless of whether it completed or not.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5337
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2269>
If one of these libraries breaks its GIR API in future, then upgrading
packages unrelated to gnome-shell might pull in the newer version,
causing gnome-shell to crash when it gets a newer GIR API that is
incompatible with its expectations. For example, this seems to be
happening in Debian testing at the moment, when GNOME Shell 41.4
imports GWeather and can get version 4.0 instead of the version 3.0 that
it expected.
Adding explicit API versions at the time the newer version is released
is too late, because that will still let the newer version of the GIR API
break pre-existing GNOME Shell packages. Prevent similar crashes in
future by making the desired versions explicit.
This is done for all third-party libraries except GLib, similar to the
common practice in Python code; if GLib breaks API, then that will be
a disruptive change to the whole GLib/GObject ecosystem, regardless.
Gvc, Meta, Shell, Shew, St are not included because they're private
(only exist in a non-default search path entry).
Clutter and Cogl *are* included, because we need to import the fork of
them that comes with Meta, as opposed to their deprecated standalone
versions.
Signed-off-by: Simon McVittie <smcv@debian.org>
Bug-Debian: https://bugs.debian.org/1008926
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2261>
MetaWindow.move_to_monitor() can no longer be assumed to have updated
the monitor on return, as under wayland, if the move involves a size
change, the monitor state will only be updated after the new size has
been synced with the client.
If that happens, trying to change the workspace of the moved window
fails, as it is still considered on-all-workspaces until it leaves
the secondary monitor.
It's possible to work around this by waiting for the window to actually
enter the requested monitor. That's finicky enough to warrant a helper
funtion, so add one.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/893
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2259>
If the timezone offset calculation in the World Clocks contains non-zero
minutes, then a decimal Hours value is being displayed. Limit the Hours value
to integers by using Math.floor().
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2255>
On some hardware combinations the display can be known, then unknown again. Meaining that
when the update monitors function is called it will have a value, then be called again
setting this.primaryMonitor to null. If the timing is just right gnome shell will
loadBackground, then by the time the animation is ready the monitor will be gone,
thus methods will be called on a null value. This adds more checks for a valid
primary monitor, and wont play the animation until the system is idle AND has a valid
priamry monitor.
Fixes: #5003
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2144>
