There probably won't be a stable ModemManager 0.7 release before GNOME
3.8, so make support for it optional
(Mostly based on Aleksander's original patch.)
https://bugzilla.gnome.org/show_bug.cgi?id=688238
The control-center will automatically detect whether the modems exposed by
NetworkManager are from the old or the new interface, and if they are from the
new one it will use the libmm-glib support to gather the required information
from them.
The new ModemManager1 interfaces are exposed by ModemManager >= 0.7; and provide
lots of new functionalities, like:
* Improved connection bearer handling (e.g. multiple bearers at the same time)
* Location support (GPS, LAC/CI, CDMA BS...)
* Full SMS support through the new 'Messaging' interface.
* ...
In bug 689638, the designers only asked for the list icons
to be symbolic, not the big icons in the page headings. The
current code was failing on both ends: virtual devices like
vlan still had non-symbolic icons in the list, and several
pages (e.g mobile and proxy) had symbolic icons in the headings.
https://bugzilla.gnome.org/show_bug.cgi?id=693001
This is consistent with the guideline to use symbolic icons for
classes and reserve full color icons for "things" like apps, people,
documents, pages, etc.
It is also consistent with how these devices are displayed in the
network menu, notifications, and dialogs.
https://bugzilla.gnome.org/show_bug.cgi?id=689638
Bond, bridge, and VLAN devices may not actually exist until their
connections are brought up. So for those types, create device items
(of type NetVirtualDevice or a subclass) as soon as we see the
NMConnection, and then watch for the NMDevice being added later.
https://bugzilla.gnome.org/show_bug.cgi?id=677145
Unfortunately, the VPN plugins provide their own .ui files for their
editor pages, so we can't make them look competely GNOME-3-ish. But
the code does try to fix them up a little bit by realigning the
labels.
vpn-helpers.[ch] is nearly identical to network-manager-applet's,
but eventually this code will move into libnm-gtk.
https://bugzilla.gnome.org/show_bug.cgi?id=691285
This makes loading faster, with less I/O, avoids unnecessary
code duplication (around 1k lines shaved), and ensures that
all the panels link and work appropriately.
By the same token, it will stop external panels from being
created, and loaded.
https://bugzilla.gnome.org/show_bug.cgi?id=690036
Done with:
sed -i -e 's/RfkillGlib/CcRfkillGlib/g' \
-e 's/RFKILL_GLIB/CC_RFKILL_GLIB/g' \
-e 's/rfkill_glib/cc_rfkill_glib/g' \
-e 's/RFKILL_TYPE_GLIB/CC_RFKILL_TYPE_GLIB/g' \
rfkill-glib.[ch] cc-network-panel.c
This would need to be done when we reset the copy/paste from
gnome-bluetooth.
And not just wireless. We need to use /dev/rfkill directly
to make sure that all the devices (3G, GPS, Bluetooth, etc.) get
switched off correctly when airplane mode is on.
https://bugzilla.gnome.org/show_bug.cgi?id=675778
Conflicts:
panels/network/cc-network-panel.c
Because it's not just about disabling the network, it needs
to disable a host of other wireless devices, and those need to
be blocked even if you end up plugging them into your computer.
Conflicts:
panels/network/cc-network-panel.c
Rename NetDeviceWired to NetDeviceEthernet, but split out most of the
code into a new NetDeviceSimple superclass that can later be used for
other device types that we provide only minimal UI/support for.
https://bugzilla.gnome.org/show_bug.cgi?id=677143
gnome-shell relies on being able to call
gnome-control-center network connect-8021x-wifi <DEVICE> <AP>
This was broken in the big refactoring of the wifi panel
last cycle. Bring it back.
