Button labels with ellipsis indicate that extra user input is
required to complete the action. However, the "Clear Cache" button
from the Storage dialog doesn't require any extra user input.
Closes https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/2627
The "Other Media" row from the Removable Media subpage has some problems:
- The row label has ellipsis, but the "Configure action" button label should
have ellipsis instead, because the later triggers further input from the user
to complete the action[1]
- "Configure action" label doesn't use header capitalization
This change addresses the two issues above.
[1] https://developer.gnome.org/hig/guidelines/writing-style.html?highlight=ellipsis
This has some advantages:
- Removes the conditional compilation requirement, which makes testing easier.
- Allows all distributed versions of Settings to have snap support without them supporting snapd-glib.
- Makes it faster to update Settings for Snap features without waiting on snapd-glib releases.
Note that the snap support is only invoked if you have snaps installed.
Downsides:
- Some additional code in Settings. This is manageable as Settings doesn't need much snap information.
libsoup2 didn't support HTTP over Unix domain sockets and would have been too much to support in Settings.
libsoup3 does support this which makes this possible.
- We no longer share code with snapd-glib, so any future changes will have to be made in multiple places.
snapd has a stable API and multiple active clients so this is not likely to be a major concern.
For example, fix adding new VPN connections.
In 60b4956c05 I correctly observed that we
need to not run code that requires a device when there is no device.
NetConnectionEditor is a multipurpose dialog and self->device is
optional when creating the dialog. E.g. when modifying VPN
configuration, we update just the configuration, not an NMDevice.
However, I added this check too soon, before updating the connection
configuration. We need to update the configuration first, then only bail
before proceeding to update the device, not sooner.
Fix#2668
Commit d980e0ffee fixed an issue when the "Left" button would appear
at the right side for RTL languages given that GtkBox would reorder
its horizontal children to RTL direction.
The solution at the time was to force the primary-button box to stay
in LTR direction when the rest of the interface is shown in RTL.
This introduced a regression where the CSS "linked" style of the
buttons used was the LTR one, breaking the "linked" styling.
This fix will manually reorder the Left/Right buttons rather than
calling gtk_widget_set_direction on the primary-button-box.
Fixes#2649
When starting the panel, it was necessary to add the sensitive
property to 'number_of_workspaces_spin', because when doing the
'g_settings_bind' it was leaving it visible even with the dynamic
workspaces option active.
Currently setting's panel list is over-populated. We can fix this by
moving some of the settings inside other panels as sub-panels.
Created a new row in applications panel for removable media and
default apps. On selecting the row we show the respective settings
which is same as before.
Removed default app and removable media from sidebar
Closes: #1092#1096
Related to: #1090
As a part of moving removable media panel under applications, we create
a function `cc_removable_media_panel_new` which return a GtkWidget
that can be added to GtkStack inside applications panel.
This allows for local translation teams to change the presentation
format of the battery level percentage string accounting for local
guidelines and standards for displaying percentage values.
See https://en.wikipedia.org/wiki/Percent_sign#Correct_style for
more information.
Fixes#2637
This is the battery charge percentage. Showing number without a space
between the percent sign is the English style.
The ISO-31-0 standard prescribes a space between the number and the
percent sign.
See #2637
!1331 (merged) introduced a custom logger as a workaround for
a not ideal design choice, but the workaround is using g_printerr,
which is not adding linebreaks, so the logs were unreadable.
This doesn't fix the whole architecture of this part, but simply
adds a line-break so that at least the logs can be read by humans.
The panel tries to keep track of the icon theme in use
when HighContrast isn't. For that, it stores in
self->old_icon_theme. That is, however, always updated
when org.gnome.desktop.interface is touched, regardless
of whether HighContrast is already turned on.
Thus, it makes sense to check whether HighContrast is
selected in org.gnome.desktop.a11y.interface, and only
store the old_icon_theme under the condition
high-contrast wasn't selected.
fixes#2640
Signed-off-by: Markus Göllnitz <camelcasenick@bewares.it>
As discussed in #2636, the value label for the CcInfoEntry was made
selectable in order for screen readers to work. However, this selects
the first label by default when opening the system details.
This is caused by gtk#4377, for which gnome-software found a workaround.
The same workaround is adapted here to unselect the label after
presenting the system details window.
Since the error message label provided at the bottom only says that
the newly provided password is weak, it can be consfusing for the
users as they might not understand why they can't press 'Accept'
button. This could be especially true for color blind people.
Fix it by allowing modification of new password entry only if the old
provided password is correctly entered.
If the NMDevice is not active (i.e. if we are editing a connection that
is not active) then don't warn when failing to reapply changes to the
device. That's expected and not something we should warn about.
We could perhaps not even try, but the device could become inactive
between the time of our check and this error, so better ignore the error
regardless.
All of the following code assumes that self->device is valid, so we need
to skip over it. It's confusing, but this is a multipurpose dialog and
self->device is optional when creating the dialog. E.g. when modifying
VPN configuration, we update just the configuration, not an NMDevice.
If the operation is cancelled (because the dialog was closed, because
the Apply button was pressed), then trying to make further use of the
source_object is a use after free, which is bad. At first I tried to fix
this by simply avoiding the use after free when the operation is
canceled, but then I realized it is ridiculous to always try committing
connection changes when closing the dialog, then immediately cancel the
operation by destroying the dialog.
So instead I've decided to not pass the cancellable along to these
operations, and instead ref the dialog to keep it alive until the
operations complete. Instead, let's just hide the window.
This commit also removes an inaccurate comment /* Leave the editor open
*/ placed right before the call to the function that hides the editor.
There's no need to leave the editor open when updating the device fails.
The connection properties at least are still saved.
Fixes#2618
QR codes for Wi-Fi networks can only be generated for Wi-Fi networks
that have one of these security settings:
- no security
- WEP security
- WPA security
This is why the button to show these QR codes should only be visible
if the Wi-Fi network in question has one of these security settings.
I used the wrong value here.
This should have been caught by an unused variable warning, but
gnome-control-center has so many build warnings that nobody will ever
notice a new one....
Fedora's anaconda wants to know the current input source separately from
the configured input sources. Installing the configured input sources in
the order they are configured is good, but not good enough because only
the currently-active input source at the time the LUKS passphrase is
entered can be used to decrypt the disk post-install, so anaconda needs
a way to know what the active input source is. Currently, there is no
way to find this. For example:
* User has English (US) input source configured by default
* User adds Czech input source
* User reorders Czech input source to be first in the list
In this scenario, the Czech input source is first in the list, but
English is still the currently-active input source, and there's no way
to know this. Only the mru-sources setting can indicate the active input
source, but because the active input source has never been changed,
mru-sources still has its default value.
The key to fixing this is that if mru-sources holds its default value,
then the user has never changed input sources before, and the first
input source that is previously configured is therefore the most recently
used. So we can copy the previous value of the sources setting to
mru-sources, and then applications can trust that either (a) mru-sources
will indicate the current input source, or (b) the current input source
is the first configured input source if mru-sources is empty.
https://bugzilla.redhat.com/show_bug.cgi?id=2231085
