Braces are optional for single-line arrow functions, but there's a
subtle difference:
Without braces, the expression is implicitly used as return value; with
braces, the function returns nothing unless there's an explicit return.
We currently reflect that in our style by only omitting braces when the
function is expected to have a return value, but that's not very obvious,
not an important differentiation to make, and not easy to express in an
automatic rule.
So just omit braces consistently as mandated by gjs' coding style.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/608
We are currently inconsistent on whether case labels share the same
indentation level as the corresponding switch statement or not. gjs
goes with the default of no additional indentation, so go along with
that.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/608
We are currently inconsistent with whether or not to put a space
after catch clauses. While the predominant style is to omit it,
that's inconsistent with the style we use for any other statement.
There's not really a good reason to stick with it, so switch to
the style gjs/eslint default to.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/607
We can use that newer method where we don't care about the actual position
of an element inside the array.
(Array.includes() and Array.indexOf() do behave differently in edge cases,
for example in the handling of NaN, but those don't matter to us)
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/152
In practice this has been seen to fail:
JS ERROR: TypeError: active.get_devices(...)[0] is undefined
ensureActiveConnectionProps@resource:///org/gnome/shell/ui/status/network.js:73:22
_getMainConnection@resource:///org/gnome/shell/ui/status/network.js:1791:13
_syncMainConnection@resource:///org/gnome/shell/ui/status/network.js:1809:32
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1406
Make the dialog a widget itself, removing the `_group` property used for
handling the actor.
Update all the inherited classes to be also GObject implementations, moving all
the signals to proper object ones.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/55
The interface name when a device is added may not be the final one. For
example when using USB tethering, it will first appear as 'usb0' before
being renamed to something like 'enp0s20f0u1' depending on the port the
phone is plugged in.
As a result, we will ignore the new interface name in that case and fail
to associate the correct connection with the device: Instead of the
correct "USB Ethernet" (or user-customized name), it will show up as
"Ethernet".
Fix this by updating names and connections when a device's interface
property changes.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/534
NetworkManager added support for a new device - NMDeviceWifiP2P - but
did not add the corresponding enum value in NMDeviceType. The return
value for nm_device_get_device_type() is therefore "illegal" for the
newly added device, and gjs throws an exception.
This should ultimately be fixed in libnm, but as errors when adding
one device shouldn't interfere with adding any other devices, catching
exception is a good idea anyway, so do just that.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1023
The dialog doesn't change the `destroyOnClose` property from its default,
so it is already destroyed automatically on close. So if we also destroy
it explicitly, we end up (rightfully) with one of gjs' infamous "invalid
access" warnings.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/430
In order to replace GTK+'s GtkPolicyType. It's bit-compatible with it, too.
All callers have been updated to use it.
This is a purely accessory change in terms of X11 Display usage cleanup,
but helps see better what is left.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/317
ES6 finally adds standard class syntax to the language, so we can
replace our custom Lang.Class framework with the new syntax. Any
classes that inherit from GObject will need special treatment,
so limit the port to regular javascript classes for now.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/361
In recent Fedora 29, connecting to wifi access points from the
user menu (top-right menu) does not work. Clicking the 'Connect'
button just animates it but does nothing else. The logs show an
error "JS ERROR: Error: Expected type utf8 for Argument
'specific_object' but got type 'undefined'".
Looking into this, it seems the problem is these uses of the
`path` property of an NMAccessPoint. NMAccessPoint inherits
from NMObject, and NMObject *does* have a path property:
https://developer.gnome.org/libnm/stable/NMObject.html#NMObject--path
so at first glance this seems fine. But I poked around a bit
using libnm via Python (which goes via introspection, just like
this JS code does), and found that indeed AccessPoint objects
don't seem to have a `path` property there either.
Looking at the libnm code, this actually makes sense, because
the property is marked "(skip)":
https://github.com/NetworkManager/NetworkManager/blob/master/libnm/nm-object.c#L1291
and the introspection docs suggest that means it should be left
out of introspected output:
https://wiki.gnome.org/Projects/GObjectIntrospection/Annotations#Symbol_visibility
I'm a bit concerned that this was only found recently - whereas
the change to use `.path` in gnome-shell dates from October 2017
(d71af5e5) and the property has been marked (skip) in NM since
at least 2016 - but this all seems to add up. The obvious fix is
to replace use of `.path` with `.get_path()`, which returns the
path and is *not* marked (skip) and so *is* available via
introspection. I tested that this works in Python and also did
a test build of gnome-shell with this change and installed it on
an affected system, it does seem to fix the bug.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
`NMConnectionDevice._sync()` is responsible for setting up the active
connection that we'll end up displaying. It expects the active
connection to already be in a map `_connectionItems`. If it isn't in
there, we get a null dereference and the indicator can get into a weird
state where it doesn't display devices / connections properly.
Let's change this expectation. If there is an active connection,
`_deviceAdded()` will eventually get to it and call `_sync()` to set up
the active connection state. We make `_sync()` tolerate there being no
active connection when it's called.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/140
When the actor that has the key focus is destroyed, Clutter moves
the focus to the stage. In case the destroyed actor was inside a
ModalDialog, this breaks any keyboard interaction: keynav is broken
because the stage isn't in any focus chain, and access keys like
Escape because they are handled on the dialog's parent.
The only dialog that may destroy a child without recreating the dialog
buttons (and thus moving the key focus there) is the WirelessDialog,
fix it by keeping the key focus within the dialog when removing networks
from the list.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/76
Similar to what it's done when the main connection changes, we need
to make sure that the icon in the panel gets updated before calling
_syncConnectivity(), so that the icon gets always updated if needed,
regardless of whether there's an active connection or not.
This is needed because there's at least one case when an icon should
be shown when the computer is not connected to any network: when a
hotspot has been enabled, which can be useful even if there's not
an internet connection to share (e.g. to easily allow connecting
other devices to the computer.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/214
When not using arrow notation with anonymous functions, we use Lang.bind()
to bind `this` to named callbacks. However since ES5, this functionality
is already provided by Function.prototype.bind() - in fact, Lang.bind()
itself uses it when no extra arguments are specified. Just use the built-in
function directly where possible, and use arrow notation in the few places
where we pass additional arguments.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/23
As in commit b2b2f65 and furthermore it doesn't make much sense to
change the menu item according to the number of connections since all
connections here are of the same type.
https://bugzilla.gnome.org/show_bug.cgi?id=786520
The new control-center shell split wifi configuration from the network
panel, and moved all other devices into a flat list. So instead of
manually spawning the app with the 'show-device' subcommand, we can
now simply launch the appropriate settings panel.
https://bugzilla.gnome.org/show_bug.cgi?id=786520
Any symbols (including class properties) that should be visible
outside the module it's defined in need to be defined as global.
For now gjs still allows the access for 'const', but get rid of
the warnings spill now by changing it.
https://bugzilla.gnome.org/show_bug.cgi?id=785084
While we've always considered it good style to initialize JS properties,
some code that relies on uninitialized properties having an implicit
value of 'undefined' has slipped in over time. The updated SpiderMonkey
version used by gjs now warns when accessing those properties, so we
should make sure that they are properly initialized to avoid log spam,
even though all warnings addressed here occur in conditionals that
produce the correct result with 'undefined'.
https://bugzilla.gnome.org/show_bug.cgi?id=781471
Currently when the wifi selection dialog is open when the screen lock is
activated, the dialog remains visible above the shield. This is clearly
broken, so close the dialog automatically on session mode changes if the
mode doesn't allow settings (as changing the access point is arguably a
user setting).
https://bugzilla.gnome.org/show_bug.cgi?id=780054
Items were inserted correctly but the synchronisation was lost if the
name of a connection was changed. Simply making sure the position is
correct after a connection is updated fixes the issue.
Reported-by: Oliver Haessler <ohaessle@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=778686
If the call to settings.get_connection_by_path in
ensureActiveConnectionProps returns null, we'll hit a JS error here.
Seems to happen always when activating a VPN connection. Avoid that.
Giovanni says:
"I believe this is papering over an existing bug, but it's possible for
settings.get_connection_by_path() to legitimately return null (if the
connection is owned by a different user and invisible to the current
one), so the fix is correct anyway."
https://bugzilla.gnome.org/show_bug.cgi?id=759793
The top bar's network menu only supports a subset of device types
supported by NetworkManager. While not having lesser used options
in the menu itself is perfectly reasonable, not showing any network
icon at all in the top bar when the system is fully connected is
weird.
https://bugzilla.gnome.org/show_bug.cgi?id=773890
Any network devices appear as top level items in the system status
menu, so on system with an unusually high number of devices, the
menu can end up exceeding the available screen height. While this
is a corner case, leaving important system actions unreachable is
bad. The system menu does not lend itself to scrolling, so handle
this case instead by summarizing sections ("n connections") where
the number of devices exceeds a threshold.
https://bugzilla.gnome.org/show_bug.cgi?id=773892
And adapt existing callers to the new API. This will allow us to
implement a way to launch applications on the discrete GPU for systems
where an "Optimus" system exists.
https://bugzilla.gnome.org/show_bug.cgi?id=773117
NM upstream would like to reduce periodic scanning, and that means
that clients should request scans themselves while their WiFi list
is open. Similar to the Windows and macOS WiFi dialogs/lists.
https://bugzilla.gnome.org/show_bug.cgi?id=767918
We only connect to the corresponding property notifications after both
Client and RemoteSettings are ready, so we may miss the initial signal
emission. Make sure to pick up the connections in this case to fix the
network indicator not showing up.
https://bugzilla.gnome.org/show_bug.cgi?id=772249
* switch to a one-column layout (and adjust strings/widths
accordingly
* remove separator before system menu
* add link to account settings to user submenu for consistency
https://bugzilla.gnome.org/show_bug.cgi?id=751377
Follow the design we have in gtk+ for buttons dialogs,
which are at the bottom and they expand full width, having
the same amount of space for each one.
Also, since this removes any space for non-button widgets
in the button area, move the spinner present in the auth prompt
dialog next to the password entry.
https://bugzilla.gnome.org/show_bug.cgi?id=746108
Due to a typo we were always removing the first (index 0) connection
from the global list of connections instead of the correct one.
This resulted in some connections remaining in the shell's connection
list long after they were removed. In particular, this resulted in
multiple copies of a bluetooth connection appearing after suspend/resume
(when the device was readded and the cached connection list was
rescanned).
https://bugzilla.gnome.org/show_bug.cgi?id=740227
Listen to changes in connectivity, and ask our helper to authenticate
when needed.
We don't have a URL to connect to yet (we will have when
the new NM API lands), so we use the default of trying
www.gnome.org (which is also more reliable because we can
recognize when the login is done)
https://bugzilla.gnome.org/show_bug.cgi?id=704416
Icons inside the menu are updated only for device state change,
but for the main device they also depend on connectivity (which
is a global property).
Add a public method to force an update of the icon, and call it
when connectivity changes.
https://bugzilla.gnome.org/show_bug.cgi?id=726401
NMApplet will call removeConnection() unconditionally on all sections,
including those that had nothing to do with the connection in the first
place.
Fixes:
Gjs-WARNING **: JS ERROR: TypeError: this._connectionItems.get(...) is undefined
NMConnectionSection<.removeConnection@resource:///org/gnome/shell/ui/status/network.js:323
wrapper@resource:///org/gnome/gjs/modules/lang.js:169
NMApplet<._connectionRemoved@resource:///org/gnome/shell/ui/status/network.js:1885
wrapper@resource:///org/gnome/gjs/modules/lang.js:169
https://bugzilla.gnome.org/show_bug.cgi?id=725958
The profile name is most often not useful (because it's an
autogenerated string like "Wired Connection 1"), and even when it
is, it's already available in the submenu.
https://bugzilla.gnome.org/show_bug.cgi?id=725586
Multiple connections for the same device are mutually exclusive, so
a switch is not the appropriate UI metaphor. Use a radio item instead,
and provide a separate "Turn off" item to disconnect.
Behavior when there is only one connection is not changed, there
is a single Connect/Turn off item.
https://bugzilla.gnome.org/show_bug.cgi?id=723570
We don't watch for timestamp changes, and sorting by name keeps
the order consistent and predictable. In practice, there should
be at most 3 or 4 elements, so the user will always read all them
at once and sorting is irrelevant.
https://bugzilla.gnome.org/show_bug.cgi?id=723570
If the connection name is changed, the UUID doesn't necessarily,
so checkConnection would take the early return path. Make sure
we update the existing menu item too.
https://bugzilla.gnome.org/show_bug.cgi?id=723570
The active_connection might be null, but the NMApplet code might
still belive the device wrapper is the primary connection (because
dbus signals are emitted one after the other).
(Also, remove an old and wrong comment about bluetooth in wwan code)
Fixes:
(gnome-shell:22511): Gjs-WARNING **: JS ERROR: Exception in callback for signal: icon-changed: TypeError: this._device.active_connection is null
NMDeviceWired<.getIndicatorIcon@resource:///org/gnome/shell/ui/status/network.js:475
wrapper@resource:///org/gnome/gjs/modules/lang.js:169
NMApplet<._updateIcon@resource:///org/gnome/shell/ui/status/network.js:1790
wrapper@resource:///org/gnome/gjs/modules/lang.js:169
_emit@resource:///org/gnome/gjs/modules/signals.js:124
NMConnectionSection<._addConnection/<@resource:///org/gnome/shell/ui/status/network.js:265
_emit@resource:///org/gnome/gjs/modules/signals.js:124
NMConnectionItem<._sync@resource:///org/gnome/shell/ui/status/network.js:137
wrapper@resource:///org/gnome/gjs/modules/lang.js:169
NMConnectionItem<.setActiveConnection@resource:///org/gnome/shell/ui/status/network.js:169
wrapper@resource:///org/gnome/gjs/modules/lang.js:169
NMConnectionDevice<._activeConnectionChanged@resource:///org/gnome/shell/ui/status/network.js:327
wrapper@resource:///org/gnome/gjs/modules/lang.js:169
https://bugzilla.gnome.org/show_bug.cgi?id=723570
This reverts commit a36bfced47.
get_available_connections() returns the connections that are
available right now, ie, with the currently visible APs, but
that might change while the dialog is open, so we can't use it.
https://bugzilla.gnome.org/show_bug.cgi?id=709128
To distinguish the bluetooth network menu from the bluetooth
menu proper, use the device name as the label.
Also, replace Connect with "Use as Internet connection"
https://bugzilla.gnome.org/show_bug.cgi?id=709353
The design says "when a network cable is connected", not
"When a network cable is connected and the link is up and we
have an IP etc. etc." (which is what ACTIVATED would imply).
https://bugzilla.gnome.org/show_bug.cgi?id=723570
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
NMClient recently got more heavyweight, with a property holding supported
connections. As fully initializing a NMObject is a recursive operation
and requires multiple DBus calls, switch to async initalization for NMClient
and NMRemoteSettings.
https://bugzilla.gnome.org/show_bug.cgi?id=683288
LTE-only modems need to be treated as GSM/HSPA modems, as they all are 3GPP
modems and they all need the same kind of configuration (APN, user, password,
PIN...).
https://bugzilla.gnome.org/show_bug.cgi?id=688144
ModemManager >= 0.7 comes with a new DBus interface. This patch makes the shell
work with the new interface if the modem is detected as being exposed by the new
ModemManager (based on the device.udi string reported by NM).
https://bugzilla.gnome.org/show_bug.cgi?id=687359.
Some notifications, despite being emitted by shell code, should appear
to be from application or "separable" system components. Do that by
associating them with a notification-daemon policy.
Note that for this to look really good, empathy should rename itself
to Chat.
https://bugzilla.gnome.org/show_bug.cgi?id=685926
syncSectionTitle looks at device list for the section, to understand if
the section should be visible or not, so obviously it needs to see the
new device.
I wonder when this broke.
https://bugzilla.gnome.org/show_bug.cgi?id=692749
NM 0.9.7 is still not released even as a tarball, so fix this to work
with 0.9.6 again for now (although it doesn't do any device name
disambiguation in this case now).
https://bugzilla.gnome.org/show_bug.cgi?id=691720
If present, InfiniBand devices show up with the ethernet devices (and
the presence of an InfiniBand connection will cause "Wired" to be
renamed to "Ethernet").
https://bugzilla.gnome.org/show_bug.cgi?id=677150
Remove section titles for ethernet and mobile broadband, and replace
them with device status items that recognize if multiple devices are
installed in the same section, and if so automatically disambiguate.
https://bugzilla.gnome.org/show_bug.cgi?id=677142
Stop pretending that VPN is a NMDevice, and split the useful bits into
a NMConnectionBased interface.
Make each connection have its own switch menu item and handle its own
status, and remove the VPN section title, which is no longer needed.
https://bugzilla.gnome.org/show_bug.cgi?id=682929
The selector for insensitive popup menu items was wrong (a PopupMenuItem is
a ShellGenericContainer, not a StButton). Fixing it showed that previous
:insensitive tracking was manual for a reason: we have many items that are
not reactive, but don't want the insensitive styling (for example those in
the battery menu).
Fix it by adding a new style-class, popup-inactive-menu-item, that is added
to all new PopupMenuItems that are not activatable.
https://bugzilla.gnome.org/show_bug.cgi?id=683988
