This is a singleton object inside libibus which means that if we
destroy it (e.g. because ibus-daemon got restarted) then, other
library users, like the ibus gtk+ IM module that we also use
in-process, will break.
https://bugzilla.gnome.org/show_bug.cgi?id=699189
Currently we simply set the gsettings key when activating an input
source. This obviously introduces a time window, between the event that
activates the switch and when the switch is complete, under which key
events are being delivered to applications and interpreted according
to the previous input source.
The patches in bug 696996 introduce a DBus API in g-s-d that allows us
to know when an input source if effectively active. Using that and
freezing keyboard events in the X server until we hear back from g-s-d
we can ensure that events won't be misinterpreted after an input
source switch.
https://bugzilla.gnome.org/show_bug.cgi?id=697007
Passkey is the proper name to be used when we are pairing with a Bluetooth
2.1+ device. PIN are only used for older devices which is not the case
here, the message is only shown when dealing with 2.1+ devices.
https://bugzilla.gnome.org/show_bug.cgi?id=697661
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
StLabel doesn't like that we set its properties after destructions,
and this would happen in currentInputSourceChanged() at the end,
when setting the ornament.
When we switch into an invalid input source we hide the panel
indicator and return early but we were not hiding the previously
active source label and its menu item dot and thus when switching
again to a third input source we would end up showing 2 overlapping
labels in the panel and the menu would have 2 entries with a dot.
https://bugzilla.gnome.org/show_bug.cgi?id=695841
SwitcherPopup relies on being able to pushModal(), setting the stage
input mode to FULLSCREEN, and then doing regular event processing on
the actor it adds to uiGroup. But MessageTray uses GrabHelper which
sets up a 'captured-event' handler on the stage and thus gets all
events itself.
This, of course, breaks the switcher if it's brought up in the message
tray so, for now, we'll just prevent it from being used there.
https://bugzilla.gnome.org/show_bug.cgi?id=693907
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.
While we handle the case where ibus_bus_get_global_engine() returns
NULL, this case actually generates an exception we have to catch to
avoid some (harmless) console spam.
https://bugzilla.gnome.org/show_bug.cgi?id=692995
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
