Input method preedit text needs to be disabled on password entries
for security and usability reasons.
IBus 1.5.7 provides the signal set-content-type so that panel UIs can
handle these special purpose input entries:
https://github.com/ibus/ibus/commit/6ca5ddb302c9
Unfortunately IBus versions older than 1.5.10 have a bug which causes
spurious set-content-type emissions when switching input focus that
temporarily lose purpose and hints defeating its intended semantics
and confusing users. We thus don't use it in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=730628
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
Normally users switch xkb input sources and ibus input sources.
But currently the first input source only is running. It's also good
to preload all ibus engines in the logging session so that users switch
input sources quickly without the launching time of input sources.
The following is the ibus change:
https://github.com/ibus/ibus/commit/cff35929a9https://bugzilla.gnome.org/show_bug.cgi?id=695428
Most of the code handles the sources setting being empty and
InputSourceManager.currentSource being null because previously the
"model" (i.e. the sources list) was kept in gnome-settings-daemon.
But this is fragile and since we're now the canonical place where the
list lives we can force it to never be empty even if the gsetting is
empty or contains only invalid entries. Adding the default keyboard
layout in that case is the safest thing to do.
https://bugzilla.gnome.org/show_bug.cgi?id=738303
All other submenus link to the corresponding settings, so we should
do the same for location - the privacy panel in this case, which now
sports a "Location Services" switch ...
https://bugzilla.gnome.org/show_bug.cgi?id=736542
Instead of calling out to gnome-settings-daemon we'll just implement
the switching logic ourselves and use mutter APIs that allow this
functionality to work both in X sessions and when we're a Wayland
compositor.
Switching IBus engines is done transparently as well just like g-s-d
used to do.
https://bugzilla.gnome.org/show_bug.cgi?id=736435
We don't really need this step as a separate method since all
implementations are supposed to be created and shown immediately. This
also ensures that we have items to show in all subclasses.
https://bugzilla.gnome.org/show_bug.cgi?id=735976
The enums values of geoclue have gaps in them (so more levels could be
added in future) but enum values of settings don't have such gaps so we
gotta translate between them.
Since desrt says that enums as integers in gsettings are bad, we now
treat accuracy level settings as string.
This fixes the recent regression of geoclue only allowing geiop level
accuracy to apps.
https://bugzilla.gnome.org/show_bug.cgi?id=736479
Users can now toggle geolocation off/on from privacy panel of
gnome-control-center so we don't need to clutter the menu with a
settings that most users won't touch most of the time.
https://bugzilla.gnome.org/show_bug.cgi?id=731122
All derived classes are already checking explicitly for action names
(FOO and FOO_BACKWARDS). mutter used to have a META_KEY_BINDING_REVERSES
flag for keybindings which required special handling of "shift"+FOO as
FOO_BACKWARDS, but this has been removed now, so this special handling
is no longer necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=732296
When this flag is set on a MetaKeyBinding, mutter will know that
the keybinding has an associated reverse keybinding triggered with
the shift modifier. However, an undesirable side-effect is that
gnome-control-center keyboard panel does not know that this 'shift'
is reserved for these reverse keybindings and cannot detect
conflicting bindings in this case.
This 'reverse' logic can now be handled at a higher level (in gcc keyboard
panel) so this commit removes it from gnome-shell so that they do not
conflict.
https://bugzilla.gnome.org/show_bug.cgi?id=732296
Now that mutter gives a way to check if a MetaKeyBinding was marked as
'reversed' or not, gnome-shell does not have to hardcode that a
MetaKeyBinding using a shift modifier is reversed, it can directly check
if the appropriate flag is set.
https://bugzilla.gnome.org/show_bug.cgi?id=732296
Since these settings are now going to be accessed by
gnome-control-center as well, its more appropriate for them to live in
gsettings-desktop-schemas.
https://bugzilla.gnome.org/show_bug.cgi?id=734483
Having the on/off setting be backed by a boolean in dconf makes sense
anyway but this is mainly to be able to remember the max accuracy set
before user disabled geolocation so that when they enable it next time,
we have the max accuracy level on same value as before.
There hasn't been a real need for this but now we are about to add
geolocation settings in control center and it'll be easiser for
control-center to simply toggle a boolean property rather than to have
to know about and deal with accuracy levels.
Later we might also want to add accuracy level settings to privacy panel
so keeping the accuracy level setting around still. However we no longer
support 'off' accuracy level as the new boolean property covers that.
This also implies that we no longer track available accuracy level,
which made the code a bit hard to follow/maintain.
https://bugzilla.gnome.org/show_bug.cgi?id=734483
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
We translate 'On' to available accuracy level but if available accuracy
level later changes, we don't update available accuracy level accordingly
and hence limit the accuracy of apps.
E.g if available accuracy level is 'city' and geolocation is enabled,
the max accuracy level would be 'city' and apps can't get higher than
that. Now if user plugs in GPS, the available accuracy level will change
to 'exact' but without this patch max accuracy level will remain to be
'city' and apps will not be able to use the GPS.
https://bugzilla.gnome.org/show_bug.cgi?id=731882
The code currently tries to use Meta.KeyBindingFlags.REVERSED. Since
this constant is |'ed with Meta.KeyBindingFlags.REVERSES, gjs silently
ignores the unknown flag.
https://bugzilla.gnome.org/show_bug.cgi?id=731619
When switching between alternatives in AltSwitcher, the currently
visible child is replaced with the alternative. If the original
child has the key focus when it is removed from the stage, the
focus is lost. Detect this case and manually move the focus to
the new child.
https://bugzilla.gnome.org/show_bug.cgi?id=727259
If geoclue reports that we can't aquire location, we hide the menu. This
will typically happen when user is offline (and doesn't have a 3G
modem). This is likely not what we want since this like a temporary
situation and user would want the ability to toggle geolocation still
even if its currently not possible any applications to query the
location.
https://bugzilla.gnome.org/show_bug.cgi?id=727398
* 'Turn On' -> 'Enable'
* 'Turn Off' -> 'Disable'
* 'Off' -> 'Disabled'
* 'On' -> 'In Use' or 'Enabled' depending on whether or not service is
in use.
https://bugzilla.gnome.org/show_bug.cgi?id=726498
In addition to BluetoothAirplaneMode, we need to check also
BluetoothHasAirplaneMode, which is indicative of bluetooth rfkill
devices (and by extension bluetooth adapters).
This prevents showing the menu if there is no adapter present.
https://bugzilla.gnome.org/show_bug.cgi?id=725057
Most system menu entries are disabled on the lock/login screen;
there is no good reason why users should be allowed to turn bluetooth
on/off (but not e.g. Wifi), so disable the entry as well.
https://bugzilla.gnome.org/show_bug.cgi?id=726319
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
