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
Due to the fact that leaving the overview is an old
behavior it is not deprecated and unnecessary for
most actions, except the settings one. The settings
system action opens an app, therefore leaving the
overview makes sense.
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
