The IMEI was not being properly displayed in the UI; the code would load it
reading 'EquipmentIdentifier' from ModemManager, but the UI wasn't getting
refreshed properly when that happened. So at the end, the IMEI was stored but
not shown. This patch fixes the issue, by reloading the UI element when the IMEI
is retrieved.
The same issue was happening with the Operator Code, with the additional issue
being that this property is meant to change whenever the registration info in
the modem changes. Therefore, we now listen to the 'RegistrationInfo' signal to
detect the changes and update the Operator Name when that happens.
https://bugzilla.gnome.org/show_bug.cgi?id=688211
On some machines used for pre-press or animation the number of display-suitable
profiles is going to be large. We really don't want to have a GtkComboBox
several times bigger than the height of the screen to navigate.
Also, while we're here get some design feedback from the #gnome-design guys and
fix up some spacing and alignment issues.
Remove the use of gdk_threads_enter and gdk_threads_leave functions, as
they have been deprecated, and also replace gdk_threads_add_idle with
g_idle_add.
https://bugzilla.gnome.org/show_bug.cgi?id=688231
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
Rather than having an unusable switch (which wouldn't represent
the real state of the connection), show a spinner until the
connection is finished doing.
The only time we were looking at the powered state of the adapter
is when the killswitch state was changing. Except that we're fast enough
that bluetoothd didn't have time to power up the adapter, so its
state was unpowered, which we would set the switch to.
The switch was off, the adapter was on.
We fix that problem by tracking the powered state of the adapter
separately.
https://bugzilla.redhat.com/show_bug.cgi?id=841881
