We add a toolbar view containing a scrolled window.
- We set the margins to 12 instead of 18
- Use AdwHeaderBar
- Set minimum size and default size
- Make resizable so it fits on small screens
See https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/2624
At the moment the search entry is consuming the Escape key press, so we
have to manually tell it what to do with it.
We clear the search on the first press, if there is input, and close the
window otherwise.
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
AdwNavigationView is a new widget meant to be used specifically
for navigation, unlike AdwLeaflet which was multipurpose.
AdwNavigationView provides a cleaner API, and when used in
conjuction with the new AdwToolbarView widget we get automatic
titles, back buttons, gestures, actions, and window controls.
In addition, AdwToolbarView provides a new style with flat headers
and an undershoot.
This commit ports the keyboard shortcut dialog to use both of
these new widgets, allowing us to simplify our navigation.
As described in #2565, the "Move Up" and "Move Down" popover menu options
are currently displayed for all input rows in the list, doing nothing if clicked
when a row is at the top or bottom of the list respectively. This commit adds
checks when creating and moving the input rows and disables these options at the
top and bottom of the list respectively, removing a useless menu option.
Fixes#2565
When editing shortcut key combination and this new combination already
exists in another shortcut, a message (new_shortcut_conflict_label) is
shown, but when clicking on the reset button (reset_custom_button) the
elements Name, Command and Shortcut skip.
It turned out that these jumps were due to the current values of the
width_chars and max_width_chars properties of the new_shortcut_conflict_label
element. So by setting these properties to zero the jumps don't occur.
The class Gtk.MessageDialog is deprecated in gtk 4.10.
This change remove class deprecated and uses the new class
AdwMessageDialog for view the message of 'reset all shortcut'.
keyboard: fix white space in function
keyboard: align arguments
keyboard: fix alignment of arguments in function
Clicking on the 'Custom Shortcuts' row when there are no custom
shortcuts causes the 'Add Custom Shortcuts' dialog to be shown for
all subsequent sessions. This is because the first stack defined was
'Add Custom Shortcuts', it would always be visible, as it was no
longer defined which stack was going to be shown.
Fixes (https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/2479)
Meson extracts them by itself and add them as dependencies for the target.
It means one less location to keep track of files, and a lot less boilerplate
around the meson files
Error building template class 'CcSearchPanel' for an instance of type 'CcSearchPanel': .:0:0 Invalid object type 'CcListRow'
Error building template class 'CcDisplayPanel' for an instance of type 'CcDisplayPanel': .:0:0 Invalid object type 'CcListRow'
Error building template class 'CcMousePanel' for an instance of type 'CcMousePanel': .:0:0 Invalid object type 'CcIllustratedRow'
Error building template class 'CcKeyboardPanel' for an instance of type 'CcKeyboardPanel': .:0:0 Invalid object type 'CcListRow'
Error building template class 'CcRegionPanel' for an instance of type 'CcRegionPanel': .:0:0 Invalid object type 'CcListRow'
Error building template class 'CcUaPanel' for an instance of type 'CcUaPanel': .:0:0 Invalid object type 'CcListRow'
Error building template class 'CcUserPanel' for an instance of type 'CcUserPanel': .:0:0 Invalid object type 'CcAvatarChooser'
Error building template class 'CcUserPanel' for an instance of type 'CcUserPanel': .:0:0 Invalid object type 'CcListRow'
Error building template class 'CcDateTimePanel' for an instance of type 'CcDateTimePanel': .:0:0 Invalid object type 'CcTzDialog'
cc_tz_dialog_get_selected_location: assertion 'CC_IS_TZ_DIALOG (self)' failed
dumped core
Error building template class 'CcDateTimePanel' for an instance of type 'CcDateTimePanel': .:0:0 Invalid object type 'CcListRow'
Error building template class 'CcInfoOverviewPanel' for an instance of type 'CcInfoOverviewPanel': .:0:0 Invalid object type 'CcHostnameEntry'
It isn't possible to open the Keyboards panel by searching for "Compose".
Compose key is an important feature, so this change adds a "Compose" keyword to improve the discoverability of this setting.
Since the main view is not visible, there is no point in updating
search results when we are in a sub-view. This will happen as we
always listen to keyboard events for the whole window - regardless
of whether the search entry has focus or not.
