Commit Graph

8877 Commits

Author SHA1 Message Date
Florian Müllner
ad1a32749e status/network: Add NMSectionItem subclass
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>
2022-08-10 12:17:19 +00:00
Florian Müllner
b4da69d474 network/status: Split out NMMenuItem base class
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>
2022-08-10 12:17:19 +00:00
Florian Müllner
9002344ec6 status/network: Always use toggles in VPN section
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>
2022-08-10 12:17:19 +00:00
Florian Müllner
7357a80d2b status/network: Merge NMConnectionSection and NMConnectionDevice
Now that the VPN section isn't using NMConnectionSection anymore,
NMConnectionDevice is the only subclass.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2407>
2022-08-10 12:17:19 +00:00
Florian Müllner
0d259d62b2 status/network: Decouple NMVpnSection from NMConnectionSection
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>
2022-08-10 12:17:19 +00:00
Florian Müllner
df354fc0d4 status/network: Handle VPN connections in VPN section
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>
2022-08-10 12:17:19 +00:00
Florian Müllner
e84ab815d2 status/network: Factor out ItemSorter class
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>
2022-08-10 12:17:19 +00:00
Florian Müllner
be950d5c4a status/network: Sort items, not connections
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>
2022-08-10 12:17:19 +00:00
Florian Müllner
a62ac495a3 status/network: Split out NMDeviceConnectionItem
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>
2022-08-10 12:17:19 +00:00
Florian Müllner
64ae6ae7b3 status/network: Update appearance of connection items
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>
2022-08-10 12:17:19 +00:00
Florian Müllner
9e3cb0b797 status/network: Make NMConnectionItem a menu item
Instead of the current radioItem/labelItem shenanigans, implement
a custom menu item with a :radio-mode property to switch between
the different presentations.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2407>
2022-08-10 12:17:19 +00:00
Alessandro Bono
b63c6ac0ef cleanup: Use deepUnpack() intead of deep_unpack()
deep_unpack() is just a backwards compability alias for deepUnpack()[1].
The new name makes it more clear that this is not a C function, start to
use it.

[1] 13e662a29d

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2416>
2022-08-10 10:29:24 +00:00
Alessandro Bono
ade4b23796 cleanup: Minimize deep_unpack() usage
deep_unpack()[1] will unpack a variant and its children, but only up to one level.
lookup_value()[2] will directly search for a value with a linear scan.

Performing a deep_unpack() + lookup can be a more expensive operation when we are
looking for just a single value compared to just perform the lookup_value() directly
in C. Avoid the deep_unpack() usage when we perform a single check presence.

[1] https://gjs.guide/guides/glib/gvariant.html#deepunpack
[2] https://docs.gtk.org/glib/method.Variant.lookup_value.html

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2416>
2022-08-10 10:29:24 +00:00
Carlos Garnacho
23bfd08b3c misc: Toggle IBus OSK capability on OSK visibility
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>
2022-08-10 10:14:40 +00:00
Alessandro Bono
4871eba8bf loginDialog: Don't call _loginScreenSessionActivated() when not required
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>
2022-08-10 09:48:35 +00:00
Alessandro Bono
20c84bf9a6 gdmUtil: Fix ShellUserVerifier retry logic
Don't call the _retry() function if we are done trying.

Fallout from 8cfd4c969b.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2412>
2022-08-09 16:42:59 +00:00
Alessandro Bono
dd97a2589b gdmUtil: Refactor on no-more-messages case
There are few places where we want to perform an action when no more
messages are present. Create a function that covers this use case
and use it.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2412>
2022-08-09 16:42:59 +00:00
Florian Müllner
f6e889626b status/network: Always notify icon-name on strength change
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>
2022-08-09 12:55:48 +00:00
Florian Müllner
c050002021 status/network: Add section classes for each device type
Those will eventually become quick toggles, and as there'll be small
differences like menu headers or which settings panel to launch, it
makes sense to give each its own class.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2406>
2022-08-07 22:41:09 +02:00
Florian Müllner
cad3ec1ecd status/network: Rename DeviceCategory and base on device type
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>
2022-08-07 22:41:09 +02:00
Florian Müllner
73f4bb13d0 status/network: Give bluetooth its own category
In the quick settings future, each device type will use a separate
toggle. We still have a long way to go, but start with giving
bluetooth its own section/category. Baby steps …

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2406>
2022-08-07 22:41:09 +02:00
Florian Müllner
714c0eaea5 status/network: Remove WireguardItem
Wireguard connections are now covered by the VPN item.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2406>
2022-08-07 22:41:09 +02:00
Florian Müllner
79f6ee25bd status/network: Use ActiveConnection:state in VPN item
The separate :vpn-state property is more fine-grained, but as
we aren't using anything beyond what :state provides, we can
just as well use that.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2406>
2022-08-07 22:41:09 +02:00
Florian Müllner
9bca544dd6 status/network: Remove status from VPN item
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>
2022-08-07 22:41:09 +02:00
Florian Müllner
b5fabedd4f status/network: Simplify device item labels
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>
2022-08-07 22:41:09 +02:00
Florian Müllner
58d29f95a7 status/network: Track device sections as device sections
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>
2022-08-07 22:41:09 +02:00
Florian Müllner
586bb29b9c status/network: Rename setDeviceDescription()
It is used to pass the disambiguated device name to device items,
so call it "name" rather than "description".

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2406>
2022-08-07 22:41:09 +02:00
Florian Müllner
02bbc830fb status/network: Rename device menu items
NMDeviceWireless sounds an awful lot like NM.DeviceWifi.

Rename all device menu items to make it clear that they are indeed
menu items, not the device they represent.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2406>
2022-08-07 22:41:09 +02:00
Florian Müllner
4622a68100 status/network: Split out WirelessNetwork class
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>
2022-08-07 22:41:09 +02:00
Florian Müllner
1aa01fc8ca status/network: Use NM utility function for classifying security
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>
2022-08-07 22:41:09 +02:00
Florian Müllner
54a1c34f6e status/network: Use property bindings for global visibility
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>
2022-08-07 22:41:09 +02:00
Florian Müllner
f411228fa0 status/network: Use connectObject() to connect client signals
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>
2022-08-07 22:41:09 +02:00
Florian Müllner
c33b5de174 status/network: Simplify notification code
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>
2022-08-07 22:41:09 +02:00
Florian Müllner
3113e6ee21 status/network: Fix error notification for wireguard
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>
2022-08-07 22:41:09 +02:00
Florian Müllner
44f0a9560c status/network: Remove reason param from ::activation-failed
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>
2022-08-07 22:41:09 +02:00
Florian Müllner
de175dfca4 status/network: Make connectivity queue a Set
It's better suited than an array.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2406>
2022-08-07 22:41:09 +02:00
Florian Müllner
ca2d39f6fb status/network: Emit 'icon-changed' on primary connection changes
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>
2022-08-07 22:41:09 +02:00
Florian Müllner
5e533e5f77 status/network: Notify icon change after access-point update
We call sync() which updates our own label and icon, but does
not notify the indicator about the icon change.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2406>
2022-08-07 22:41:09 +02:00
Florian Müllner
7bfd4fe148 status/network: Sync active access point from constructor
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>
2022-08-07 22:41:09 +02:00
Florian Müllner
af132dd884 status/network: Catch errors when fetching client
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>
2022-08-07 22:41:09 +02:00
Florian Müllner
d9d70c162d status/network: Some minor style fixes
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>
2022-08-07 22:41:09 +02:00
Alessandro Bono
32248e8226 authPrompt: Don't propagate serviceName to setMessage
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>
2022-08-06 23:30:55 +00:00
Florian Müllner
0fdca0d21a quickSettings: Bind menu arrow's reactivity to parent
When a QuickMenuToggle is made insensitive, then it is unexpected
that its menu can still be opened despite the appearance.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2405>
2022-08-06 21:27:15 +00:00
Florian Müllner
ce19849c09 status/power: Merge with system indicator
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>
2022-08-03 12:41:05 +00:00
Florian Müllner
ea00da7fd7 status/system: Port to quick settings
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>
2022-08-03 12:41:05 +00:00
Florian Müllner
62c62eced0 status/volume: Port to quick settings
Thanks to the preparations and QuickSlider, this is again
straight-forward.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2393>
2022-08-03 12:41:05 +00:00
Florian Müllner
7bbd59838a status/brightness: Port to quick settings
Using QuickSlider, this is another easy port.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2393>
2022-08-03 12:41:05 +00:00
Florian Müllner
1f178e83d3 status/powerProfiles: Port to quick settings
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>
2022-08-03 12:41:05 +00:00
Florian Müllner
c2e8f41bdf quickSettings: Add QuickSlider
Between input/output volume and brightness, we have enough use
cases for a common slider QuickSettingsItem, in particular as
the items can have a menu.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2393>
2022-08-03 12:41:05 +00:00
Florian Müllner
4b9dcb3f89 quickSettings: Add QuickMenuToggle
This is a convenience subclass for a quick toggle with a menu.

The menu can be disabled dynamically and if enabled, an arrow
is displayed that allows opening the menu.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2393>
2022-08-03 12:41:05 +00:00