Rather than just showing "No networks", inform the user if airplane
mode is on or if wifi is off, and allow the user to change that
from the dialog (if possible).
https://bugzilla.gnome.org/show_bug.cgi?id=709128
Ideally, we should keep scanning while the dialog is open, and
stop (or reduce the frequency) when it's closed. Forcing a new
scan when the dialog is opened empty is a close approximation
and increases the probability that the user will find the AP
he needs.
https://bugzilla.gnome.org/show_bug.cgi?id=709128
It's a lot simpler and doesn't require us routing the NMRemoteSettings
all the way through. It's still a bit complicated to do this for the
usual connections, so let's drop it for now.
Their use blocks activation of the default button by keyboard, which
is important for accessibility. Use a Clutter.ClickAction instead,
which doesn't have this problem as it only considers mouse events.
https://bugzilla.gnome.org/show_bug.cgi?id=710144
Show "Hardware Disabled" when disabled by HW switch, and
generically "Disabled" when airplane mode is active, as
indicated by v4 mockups.
Note that bluetooth is not affected by NM handling of airplane
mode (and generally the firmware makes the USB bluetooth
adapter disappear when rfkilled), so this is in NMDeviceModem
instead of NMConnectionDevice.
https://bugzilla.gnome.org/show_bug.cgi?id=709043
The property is on the NMClient, not NMDevice. Also, make sure
we disconnect the signal when the item is destroyed.
Also, connect to wireless-hardware-enabled, which we'll use soon.
https://bugzilla.gnome.org/show_bug.cgi?id=709635
If the active connection for the device is not the primary or
activating globally, it won't have the _connection and _primaryDevice
expando properties, so grab them from the settings object.
https://bugzilla.gnome.org/show_bug.cgi?id=709043
The patch fixes the following warning, and along with it, the proper
destruction of the NMConnectionSection is performed so that items get
correctly removed from the menu.
(gnome-shell:24528): Gjs-WARNING **: JS ERROR: TypeError:
this.statusItem is undefined
NMConnectionSection<.destroy@/home/aleksander/gnome/install/share/gnome-shell/js/ui/status/network.js:173
wrapper@/home/aleksander/gnome/install/share/gjs-1.0/lang.js:213
_parent@/home/aleksander/gnome/install/share/gjs-1.0/lang.js:175
NMConnectionDevice<.destroy@/home/aleksander/gnome/install/share/gnome-shell/js/ui/status/network.js:292
wrapper@/home/aleksander/gnome/install/share/gjs-1.0/lang.js:213
_parent@/home/aleksander/gnome/install/share/gjs-1.0/lang.js:175
NMDeviceModem<.destroy@/home/aleksander/gnome/install/share/gnome-shell/js/ui/status/network.js:448
wrapper@/home/aleksander/gnome/install/share/gjs-1.0/lang.js:213
NMApplet<._removeDeviceWrapper@/home/aleksander/gnome/install/share/gnome-shell/js/ui/status/network.js:1421
wrapper@/home/aleksander/gnome/install/share/gjs-1.0/lang.js:213
NMApplet<._deviceRemoved@/home/aleksander/gnome/install/share/gnome-shell/js/ui/status/network.js:1416
wrapper@/home/aleksander/gnome/install/share/gjs-1.0/lang.js:213
https://bugzilla.gnome.org/show_bug.cgi?id=709248
For extremely silly reasons with how the class framework works, the wrapper
method requires "this" to be bound in order for it to work, or else we'll
emit errors in strict mode.
https://bugzilla.gnome.org/show_bug.cgi?id=707892
We watch changes in the VPN state, not the active connection state,
so if we use the active connection state, we might miss an update
(because the VPN property is notified before the other one)
https://bugzilla.gnome.org/show_bug.cgi?id=706262
Descriptions are only added after all devices are read (thanks
to the disambiguation in libnm-gtk), but we use them immediately
when we call _sync() in various points (such as checkConnection())
https://bugzilla.gnome.org/show_bug.cgi?id=706262
If we don't have a connection at startup or we transition from
having a connection to not having a connection, we need to make
sure we hide the correct indicators.
There's only two uses of the parameter left, which can easily be added as a
separate line below. Since it's really a private interface meant for the
indicators, make it private as well so external users are less likely to
use it.
https://bugzilla.gnome.org/show_bug.cgi?id=705845
We can't silently replace the old behavior of separate status
icons into a new system. Replace SystemStatusButton with a new
SystemIndicator class which will allow for the flexibility we
need. For now, make it a subclass of Button so that it mostly
feels the same, but we'll soon be swapping it out with a dummy
implementation that the aggregate menu will use.
I think the code cleanup here is worth it.
https://bugzilla.gnome.org/show_bug.cgi?id=705845
Remove the Wi-Fi chooser from the menu and put it in a dialog instead.
This frees up the submenu to simply have three items: an rfkill toggle,
a button to show the dialog, and a button to show network settings.
Ideally, we'd autodetect the "needs network" case by user initiation
and automatically show the dialog if needed, but lower-level plumbing
is neccessary, so the menu item to show the dialog is an acceptable
compromise instead.
This is a part of the new system status design, see
https://wiki.gnome.org/GnomeShell/Design/Guidelines/SystemStatus/
for design details.
https://bugzilla.gnome.org/show_bug.cgi?id=704670
Since the network section of the aggregate menu will be shown in the lock
screen, we need to ensure that users can't tweak with network settings or
anything like that.
https://bugzilla.gnome.org/show_bug.cgi?id=704670
Replace NMNetworkMenuItem with NMConnectionItem, based on
NMVPNConnectionItem, and replace NMDevice with NMConnectionSection
and NMConnectionDevice.
Since this rips apart NMDevice, and since wi-fi should not be
connection-based, we'll temporarily remove NMDeviceWireless. We'll
add it back in a later commit, along with the new Wi-Fi dialog.
https://bugzilla.gnome.org/show_bug.cgi?id=704670
Instead, just add them after they're constructed. This allows us to
not have to pass the connections to each device, and prevents issues
with having to enumerate the connections in the middle of construction.
https://bugzilla.gnome.org/show_bug.cgi?id=704670
This is a part of the new system status design, see
https://wiki.gnome.org/GnomeShell/Design/Guidelines/SystemStatus/
for design details.
Note that this does have an interesting side effect of not showing
network connectivity status on wired. This is intentional, and error
states will still be shown in the top bar when they happen.
This also means that if you're connected to both wired and wireless,
even though wired is the default route, we'll first notice the wireless
active connection, and we'll show that in the top bar. New NM API that
will help figuring out the active connection of the default device is
being implemented to stop this from happening.
https://bugzilla.gnome.org/show_bug.cgi?id=704670
The code is complicated by requiring overflow, and in order to incrementally
improve the code to match the designs, remove overflow.
In the new design, we'll have a fixed number of menu items, and Wi-Fi
will be done by a separate design, so we can't be too concerned with
the menu not fitting on the screen.
This is a part of the new system status design, see
https://wiki.gnome.org/GnomeShell/Design/Guidelines/SystemStatus/
for design details.
https://bugzilla.gnome.org/show_bug.cgi?id=704670
According to Dan Williams, if firmware is installed the device
will disappear and reappear, and this is unlikely to change any
time soon. Just make our lives easier by removing the tracking.
https://bugzilla.gnome.org/show_bug.cgi?id=704670
I intended to make a few code cleanups, but I apparently forgot
to hook up _updateAccessPoint. Merge it with _activeApChanged,
which is where the notify::active-access-point signal is actually
hooked up to.
https://bugzilla.gnome.org/show_bug.cgi?id=704670
_updateIcon should not attempt to sync any active connections, as the
icon-changed signal can be emitted in response to something done during
_syncActiveConnection. In the case of VPN, removeActiveConnection would
cause an icon-changed signal to be emitted immediately, but the state
would not be updated, causing us to call removeActiveConnection over and
over.
Explicitly sync all active connections when we know it needs to be done,
and simply make _updateIcon synchronize with the current device's icon.
https://bugzilla.gnome.org/show_bug.cgi?id=703565
The status item will go away soon, so make sure the one-time
fire is given its own function. At the same time, only connect
to the signal when the situation actually matters.
https://bugzilla.gnome.org/show_bug.cgi?id=701954
No class in here has this.carrier as a property. Presumably, this was
meant to be this.device.carrier, but since this code is going to be
rewritten soon anyway, might as well just junk the never-working
code for now.
https://bugzilla.gnome.org/show_bug.cgi?id=701954
This can be more easily achieved by listening for changes to the
device's active-connection property. VPN will still need support to
track active connections, as it does not have an associated
device. But as VPN can track multiple active connections, the names
"set" and "clear" don't quite fit. Rename them to the more-standard
"add" and "remove".
https://bugzilla.gnome.org/show_bug.cgi?id=701954
As multiple-connections for a Wi-Fi AP won't fit in the new design,
remove submenus right now. Simply make a simple item that connects
to the first known connection for the AP, which should be the common
case.
https://bugzilla.gnome.org/show_bug.cgi?id=698918
This is technically a smidge slower due to the constant bisect insert,
but since this should only happen when we make a Wi-Fi dialog, it's
insignificant.
https://bugzilla.gnome.org/show_bug.cgi?id=700322
Only ACTIVE or ACTIVATING connections are important when deciding
what icon to show, don't fallback on any, possibly invalid or deactivating,
active connection object.
https://bugzilla.gnome.org/show_bug.cgi?id=676285
We put these "access point objects" in "this._networks" and
"this._activeNetwork", so let's rename it. This also makes
the fact that each "access point object" can contain multiple
access points a tiny bit less confusing.
https://bugzilla.gnome.org/show_bug.cgi?id=698918
NM is now a lot smarter about dealing with automatic connections, so just
create an empty connection and pass it to it. The only places where NM
requires connection settings is where we require explicit setup: Bluetooth
DUN, WPA-Enterprise and WWAN/VPN. These cases are already handled by
gnome-control-center, where complex configuration is handled, so remove
the automatic connection management for now and just let NM handle it.
https://bugzilla.gnome.org/show_bug.cgi?id=698918
