Whether the device is used as a hotspot is currently only
used internally for the name and icon-name properties.
But hotspots need special treatment in the toggle as well,
so turn the method into a GObject property.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2408>
As the sections are about to turn into quick toggles, they need
to be able to perform an action on click.
Add an activate() method for that purpose, which either disconnects
all active items, or connects the primary item.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2408>
DeviceItems are sections, and therefore not actually activatable.
However when we port to quick settings, those toggles will need
to do *something*.
For that reason, provide an activate() implementation that
1. deactivates the device if currently connected
2. delegates the action to the most-recently used item,
the first visible item or the auto-connect item (in that
order)
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2408>
The primary indicator is a bit tricker than the VPN one: The source
of the binding can change depending on the connection, and we still
want to show it when there is a network connection we don't know
about (either because we don't handle the device type, or the
device isn't managed by NetworkManager).
Bindings still make the whole thing a lot nicer though.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2408>
This is the last property that will be needed by the future
betwork quick toggles.
It maps to the same item as :icon-name, except when more than one
item is active. In that case, we overrule the binding and return
a generic name and count (like "VPN (2)").
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2408>
Again no big surprise, a property that will soon correspond to the
quick toggle's icon.
It is more involved than the :checked property though, which is just
a simple boolean.
To keep it as simple as possible, we set up a binding group and use
that to bind the :icon-name property.
As state changes, we then update the group's source with the item
we deem to best represent the section as a whole at the given
moment.
That is (in that order):
- the first active item
- the most recently used item
- the top-most visible item
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2408>
Instead of subclassing PopupMenuSection, it is now a plain GObject
that has a `menu` JS property.
That brings it a tad bit closer to QuickMenuToggle, which is another
GObject with a `menu` property.
We are on the final stretch now. Over the next couple of commits,
we'll add some (fake) properties so we can hook everything up,
and then it's finally time for the big switch.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2408>
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>
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>
