If we get an error during device enrollment, the message might be
prefixed to indicate that the error came from the remote peer. We
are presenting that message to the user so strip that prefix away
if it was there.
The devices emitted (device, error) while the connected handler
was expecting (error, device). The former is more consistent
with the rest of the code (so change it to device, error).
boltd 0.2 gained a property that indicates if it is authorizing
devices or not. If it indeed is not authorizing then we wont
try to enroll new devices because that would otherwise lead to
and error.
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
imports.misc.ibusManager.IBus is declared as const, so referencing it
from another module triggers a warning with recent mozjs. As of commit
083d11a032 IBus is mandatory, so just make it a regular import to avoid
the warning.
We will now basically act as "policy provider" for thunderbolt
peripherals by using org.freedesktop.bolt service: when new
devices are connect and session is a unlocked user session
we will automatically enroll (authorize and store in the database)
them.
If new devices are connected but the session is locked a message
will be shown informing the user that the device needs to be
reconnected to properly work.
The org.freedesktop.bolt service is provided by the "bolt" daemon.
Currently the language options displayed pretty much mirror those of the
top bar keyboard layout selection popup. It may make sense in the future
to only list languages, and automatically switch to the enabled IMs that
the OSK can benefit from (eg. by filling in suggestions).
In the current code it could happen that we've menuItems and indicatorLabels
for sources that aren't anymore around, because in case a source is removed
we don't cleanup the their container objects.
Also, we should nullify InputManager's _currentSource when sources change
or it might point to some invalid data again.
So it could happen that we try to access an invalid menuitem or label
if a source change happens mentioning a source that has been deleted.
https://bugzilla.gnome.org/show_bug.cgi?id=788931
This D-Bus property was never been added here, which caused inconsistencies
under some scenarios (e.g. coming back from suspend) if some devices were
previously paired, since _sync() would then make the bluetooth menu visible
unconditially, because of the proxied property evaluating to 'false'.
Adding this to the D-Bus interface makes sure that it's no longer undefined
and returns the right value, fixing the bug.
https://bugzilla.gnome.org/show_bug.cgi?id=789110
The idea behind always showing the icon on the login screen is that
the users' needs aren't known at that point. However we can achieve
the same behavior by including the 'always-show-universal-access-status'
key in GDM's presets, so drop the special-case.
https://bugzilla.gnome.org/show_bug.cgi?id=788943
In anticipation of showing the system actions in
the search results, it is fit to move action
specific code to its own module in order to
reuse it.
https://bugzilla.gnome.org/show_bug.cgi?id=691900
The current behavior wasn't designed, but was introduced in commit
84efaac52b to work around technical limitations when we were still
using external tools like gnome-screensaver or gnome-session-quit
to handle the actions. Those limitations are long gone, so it makes
sense to make the actions consistent with the corresponding keyboard
shortcuts: Leave the overview when launching an application, and leave
it alone otherwise.
https://bugzilla.gnome.org/show_bug.cgi?id=691900
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
It is possible to use the scroll wheel to adjust the volume without
opening the system menu, but there is no feedback other than the
icon itself in that case. To provide a less coarse indication for
the volume level, display the OSD window when adjusting the volume
while the slider isn't visible.
https://bugzilla.gnome.org/show_bug.cgi?id=781028
Since commit 2c070d38, we add a ClickAction to the visible AltSwitcher
button to track long-presses. As a result, we now have two components
that will grab and ungrab the pointer for the button, so to make sure
we don't end up with a stuck grab, we need to release the second's
component grab when the first activates.
Currently we only drop the StButton grab on long-press, we also need
to cancel any initiated long-press on click.
https://bugzilla.gnome.org/show_bug.cgi?id=781738
It doesn't make sense to tie the proxy code for flatpak's permission
store to the location indicator, just because that was the first
component to use it, so split it into a separate module.
https://bugzilla.gnome.org/show_bug.cgi?id=780252
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
The display configuration now exposes a setting to automatically
shift the display color at nighttime. As there are cases where
disabling the filtering temporarily is useful, it makes sense to
expose the feature in the system menu for quick access.
https://bugzilla.gnome.org/show_bug.cgi?id=741224
On systems that support both shutdown and suspend, the latter operation
is currently only accessible via pressing the Alt key. As using the
keyboard may be inconvenient or simply not possible (e.g. on touch),
allow switching between alternatives via long-press as well.
https://bugzilla.gnome.org/show_bug.cgi?id=721173
The permissions hash is initialized after consulting the permission
store, however the lookup is skipped for requests that cannot be
resolved to an application, resulting in an error when accessing
the uninitialized hash for saving. Just make sure that the property
is always initialized to avoid that error.
https://bugzilla.gnome.org/show_bug.cgi?id=778661
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
If Bluetooth is on but there aren't connected devices, the status in the
menu reads "Not in Use". This is potentially confusing: it's a negative
statement, even though Bluetooth is on. It also sits uneasily (and looks
even more confusing) next to the submenu item "Turn Off".
Changing the string to "On" is better.
https://bugzilla.gnome.org/show_bug.cgi?id=756432
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
We currently show the orientation lock button when an accelerometer
is present, however gnome-settings-daemon's xrandr plugin only applies
rotation when a builtin monitor is present. Update the button's
visibility to match gnome-settings-daemon.
https://bugzilla.gnome.org/show_bug.cgi?id=765267
Let's make it really simple and ask user interactively, once. This
simplifies things for:
* Privacy panel of gnome-control-center as it doesn't have to filter
applications.
* Apps: If they are denied access, they can simply point users to
privacy panel of gnome-control-center since they can be sure location
access for the app can be enabled in there.
Also it's less annoying to user. Before this patch, if they denied
access to application, they had to keep doing that at least each time
they launched the application.
https://bugzilla.gnome.org/show_bug.cgi?id=762559
Alex told me that since it's not geoclue but rather GNOME-components
storing/accessing app permissions, it's better if we put it under
'gnome' rather than generic 'desktop' table.
While we could have implemented this already a while ago, this would
have been a completely false security mechanism since we had no way of
reliably identifying applications. Since now with xdg-app, we can at least
reliably identify bundled applications, let's give users a choice of
which applications in particular they are OK with giving location data
to.
While we still can't reliably identify system (non-xdg-app) applications,
it seems extremely unlikely we'll ever be able to do that (at least not
in the near future) so we'll have to trust them to not lie about their
IDs.
Next release of geoclue will take the ID of bundled application directly
from corresponding xdg-app metadata so bundled applications can't simply
lie about their IDs.
https://bugzilla.gnome.org/show_bug.cgi?id=762119
This class will be responsible for authorizing applications that try to
access location information. Since this is mainly targetted for xdg-app
applications, we make use of xdg-app's D-Bus API to store
per-application authorization.
https://bugzilla.gnome.org/show_bug.cgi?id=762119
Add a dialog that is used in a following patch, to ask user if they want
a requesting application to gain access to their location.
Co-author: Florian Müllner <fmuellner@gnome.org>
https://bugzilla.gnome.org/show_bug.cgi?id=762119
Any time estimates we can come up with are notoriously unreliable;
even on devices that report correct (dis)charging rates, any change
in workload, screen brightness etc. can throw our estimate off by
a huge amount. This is further compounded by bad firmware and battery
firmware which reports inaccurate data as neither Windows nor Android do
not use that data.
So instead, limit ourselves to only showing the current percentage
and leave its interpretation to the user.
As an added bonus, we end up with shorter strings that are less likely
to cause problems with ellipsization when translated.
https://bugzilla.gnome.org/show_bug.cgi?id=708472
If we detected that Bluetooth devices were setup, show the Bluetooth
menu so that users can easily turn Bluetooth back on.
This is a bit of a hack, as we cannot detect whether there is a
Bluetooth adapter at all when it's disabled, so we cannot tell whether
there were any Bluetooth devices setup, at some point. This state is
saved in the gnome-shell GSettings in the had-bluetooth-devices-setup
key.
Checking whether we saw Bluetooth devices at one point is a good
enough guess of whether there will be some in the future.
https://bugzilla.gnome.org/show_bug.cgi?id=723848
* 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
Instead of using gnome-settings-daemon's D-Bus interface's presence.
iio-sensor-proxy now offers a D-Bus interface, which will exported
"HasAccelerometer = true" when an accelerometer is present.
https://bugzilla.gnome.org/show_bug.cgi?id=749671
Instead of saving only the current input source when entering password
mode, let's save the whole MRU list so that we can restore it when
returning to normal mode.
This is closer to user expectations since password mode is a transient
and short lived state.
https://bugzilla.gnome.org/show_bug.cgi?id=746605
g-s-d has been taking care of this for us but in a very hackish way
that causes dconf writes on every startup and also doesn't handle
dynamic updates to locale1's properties which has become a problem now
that GDM keeps its greeter session running in parallel with users'.
To take care of this properly, this commit introduces a settings
abstraction with both system and session implementations. The session
implementation just wraps access to the existing gsettings while the
system one gets its values from org.freedesktop.locale1's properties.
https://bugzilla.gnome.org/show_bug.cgi?id=746288
The mode is never set after the removal of the bottom tray, so it
no longer makes sense to pass it to allowKeybinding(). We can also
safely remove it from the ActionModes flags altogether without
requiring a synchronized update with gnome-settings-daemon, as
the latter never used any flag value above LOGIN_SCREEN.
This used to be the style-class for status icons (i.e. icon-only
top bar items). It got unused a while ago when the class used
by status icons stopped using it - except for the keyboard indicator,
which set the class manually to appear as status icon despite not
being a real icon.
Now that the button highlight is provided by the .panel-button class
on a parent, the obsolete class results in a double border on the
keyboard indicator when active - just drop it from there as well
to fix.
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
