Instead of changing from "Account Type" buttons to label, set the
sensitivity of the buttons according to the current users' permission.
Now we hide the "Account Type" for a single user account.
https://bugzilla.gnome.org/show_bug.cgi?id=767065
When comparing the keyboard shortcut's default and current
values, we double-check what kind of variant the default
value is, but don't check that for the user value.
This ends up throwing lots of variant-related warnings, as
the user value may not be a plain string.
Fix that by checking the variant types both for the user and
the default value of the shortcut's settings.
https://bugzilla.gnome.org/show_bug.cgi?id=769310
Based on the latest mockups, the Keyboard panel would
benefit from a search functionality.
This patch add all the necessary UI and functions to
make the search work. Worth noticing that the current
implementation still doesn't work with search-as-you-type,
which'll be addressed on a future fix.
https://bugzilla.gnome.org/show_bug.cgi?id=769063
In order to simplify the porting to the new UI, the
reverse item functionality was removed. Now that all
the necessary code landed, it is time to bring it back.
This patch adds back the ability to manage reverse items.
https://bugzilla.gnome.org/show_bug.cgi?id=769063
Following the proposed mockups, the shortcut list must
have the ability to reset modified to non-default shortcuts
right from the listbox.
After adding the necessary API in CcKeyboardItem, adding
the user-visible elements to enable that is easy.
To make that happen, add a button that resets the
keyboard shortcut.
https://bugzilla.gnome.org/show_bug.cgi?id=769063
The current keyboard item API does not track whether the
keyboard shortcut is the default value or not. In order to
properly implement the Reset operation, the keyboard item
must receive this API and ideally handle it internally.
This patch adds the necessary API to CcKeyboardItem to track
whether the shortcut is the default value or not.
https://bugzilla.gnome.org/show_bug.cgi?id=769063
The collision detection code was removed in commit a0a155884e
as the cleanup was happening because the previous code was closely
tied to the user interface components.
Because that code wasn't appliable to the new listbox UI, it was
temporarily removed.
This patch re-adds this feature to work with the new code orgazination.
https://bugzilla.gnome.org/show_bug.cgi?id=769063
Instead of having CcKeyboardPanel managing both UI and backend code,
factor the backend code to a new CcKeyboardManager class and drop
backend management from the panel itself.
The new backend class handles the loading, creation and removal and
search of keyboard shortcuts. It also resolves reversible shortcuts
when searching.
This patch moves the code to this new class, and updates the rest of
the Keyboard panel to use it instead.
https://bugzilla.gnome.org/show_bug.cgi?id=769063
While using the Keyboard shortcut editor dialog under
Wayland, the user receives a <Meta> key even when this
key isn't present in the physical keyboard nor in the
keymap.
This is probably the result of Wayland inheriting from
X's xkb.
To work around that, simply filter out this modifier.
https://bugzilla.gnome.org/show_bug.cgi?id=769063
The current CcKeyboardPanel used to manage keyboard
editing through GtkCellRendererAccel, which was replaced
when we moved to use a GtkListBox. Because of that,
the ability to edit shortcuts is now missing.
Re-add shortcut editing capabilities through a new dialog,
which is done according to the latest mockups available.
https://bugzilla.gnome.org/show_bug.cgi?id=769063
After porting the shortcuts management entirely to
GtkListBox, the current treeview is not necessary
anymore.
This patch removes the shortcuts treeview and all
the related functions, and separates the treeviews
from the underlying models.
https://bugzilla.gnome.org/show_bug.cgi?id=769063
The accelerator formatting method itself is copied from
GtkCellRendererAccel, and will be used throughout the code
to format the accelerators just like they used to be before
moving to the listbox.
https://bugzilla.gnome.org/show_bug.cgi?id=769063
To allow a much easier porting to the new layout, the keyboard
panel is now a template class. That has various implications on
the code organization:
- The keyboard-shortcuts.c was responsible for filling the shortcuts.
Because it relied on the GtkBuilder of the panel, most of its code
was moved to the CcKeyboardPanel class.
- The unused code from the keyboard panel class had to be removed in
order to make it work again.
- All the hash tables and widgets are now part of the CcKeyboardPanel
structure.
- The interface elements have a single entry point.
https://bugzilla.gnome.org/show_bug.cgi?id=769063
Commit eb9c110 removed add-remove-toolbar, however, some leftovers are
in the code which causes the following errors:
Gtk-CRITICAL **: gtk_widget_get_style_context: assertion 'GTK_IS_WIDGET (widget)' failed
Gtk-CRITICAL **: gtk_style_context_set_junction_sides: assertion 'GTK_IS_STYLE_CONTEXT (context)' failed
https://bugzilla.gnome.org/show_bug.cgi?id=767065
When a touchpad supports it. When the option is set, it will
automatically disable two-finger scrolling.
The scrolling method used by each individual touchpad is implemented in
mutter, not here.
https://bugzilla.gnome.org/show_bug.cgi?id=761461
gettext can extract strings from xml file formats with the help of
.its files. Provide appropriate rules so modules that install
keybinding descriptions don't need to depend on intltool to
extract translatable strings.
https://bugzilla.gnome.org/show_bug.cgi?id=769066
This also introduces a change to the Lock/Unlock logic. From now
on, Unlocking the panel causes the "Lock" button to turn into the
"Add User" button.
https://bugzilla.gnome.org/show_bug.cgi?id=767065
The headerbar buttons with arrows were moved sidebyside by the commit
a70888f. The buttons have a slightly different size, which looks pretty
weird currently. Fix this by setting valign on GtkButton and not on
GtkImage inside.
https://bugzilla.gnome.org/show_bug.cgi?id=767065
These classes are deprecated by Gtk+ and should be replaced
by vertical and/or horizontal GtkBoxes.
This commit replaces the usage of the deprecated box classes.
https://bugzilla.gnome.org/show_bug.cgi?id=769063
After introducing the autocleanup function to
CcPanel, it is now possible to remove a lot of
boilerplate code from the panels.
This commit ports CcKeyboardPanel to be a final
type, removing all the old boilerplate code in
the proccess.
https://bugzilla.gnome.org/show_bug.cgi?id=769063
Currently if control-center is already running with privacy panel in
foreground and user authorizes a new application to gain access to
location information from gnome-shell dialog, this change doesn't get
reflected in the privacy panel to user until they exit privacy panel.
This change fixes this by reacting to changes to permissions store.
https://bugzilla.gnome.org/show_bug.cgi?id=765006
Since we are setting the "Account Activity" title by prepending
the user real name ("%s - Account Activity") in um-history-dialog.c,
there's no need to set the title property for the dialog elsewhere.
https://bugzilla.gnome.org/show_bug.cgi?id=767065
This code will be reused in the future to retrieve information
stored in /etc/os-release file and, as preparation for the next
patch that retrieves and displays the build-id of the OS.
https://bugzilla.gnome.org/show_bug.cgi?id=768693
The Mouse & Touchpad panel has a horizontally centered
list, which is centered pixel-counting the list width and
hardcoded margins.
This approach has various issues. It resizes the window
needlessly when e.g. the font changes the size, dpi or
family. This is specially visible when dealing with low
resolution screens, where the hardcoded margins are too
much to fit a 720x480 screen with the Large Font accessibility
setting on.
Fix that by removing the margins and setting the horizontal
alignment of the list to center. Since the list itself doesn't
expand to fill the available space, there won't be any user-
visible changes except that the panel is now able to scale
down.
https://bugzilla.gnome.org/show_bug.cgi?id=768529
Instead of using only hardcoded height requests, it's better
if we give more flexibility for the content to grow up to
a certain amount of pixels.
Also, this patch slightly reduces the maximum size by 20px, so
that in the tested scenario (Adwaita with Large Font settings on)
the panel is still able to size down.
https://bugzilla.gnome.org/show_bug.cgi?id=768529
