When adding a custom shortcut, the header mode was set to be
only "Cancel". Per mockups, the "Add" button should also be
visible but insensitive.
Fix that by correctly setting the header mode on creation mode.
https://bugzilla.gnome.org/show_bug.cgi?id=777824
When creating a new shortcut, we currently assume the entries are
sensitive and just show the dialog. This, however, may not be, for
example after previously canceling the editing of a custom shortcut,
leading to a state where the name and command entries are insensitive.
Fix that by always making sure the entries are sensitive when
setting the dialog to creation mode.
https://bugzilla.gnome.org/show_bug.cgi?id=777824
When canceling the editing of a custom shortcut, the "Edit" button
keeps pressed, causing inconsistencies when editing future custom
events.
To reproduce that:
- Open a custom shortcut and click "Edit"
- Start typing the new shortcut; the "Cancel" button will appear
- *Before* completing the new shortcut, click "Cancel"; the dialog will hide
- Open a custom shortcut again; the "Edit" button is still toggled
Fix that by properly untoggling the Edit button when cancelling
the editing.
https://bugzilla.gnome.org/show_bug.cgi?id=777824
The empty string is not too useful as an SSID, an attempt to create a
hotspot fails:
(gnome-control-center:19371): network-cc-panel-WARNING **:
Failed to add new connection: (2)
A 'wireless' setting with a valid SSID is required if no AP path was given.
Users are not familiar with term 'banner', so it is replaced with
term 'popup'. Also description has been added to the notifications
and popups switches, which explains why someone might want to disable
popups but leave notifications enabled.
https://bugzilla.gnome.org/show_bug.cgi?id=751369
With gtk+ >= 3.22 trackpoints are classified separately from mice so
we need to handle them here. Also, remove the default case so that we
get a compilation warning in case this happens again.
In the future we might want to expose this further if we start adding
trackpoint specific UI.
https://bugzilla.gnome.org/show_bug.cgi?id=776660
This commit starts moving the contents of the add account dialog
class to the panel itself, by adding a providers listbox below
the list of available account as per the new mockups. As a side effect,
this commit temporarily makes removing an account non-functional.
The next commits are focused on finishing this move and removing
the add account dialog.
https://bugzilla.gnome.org/show_bug.cgi?id=774222
The current implementation of the Online Accounts panel allows only
the account list to scroll. To prepare ouselves for the future
changes, let's make the entire panel scrollable.
https://bugzilla.gnome.org/show_bug.cgi?id=774222
Instead of selecting an account, this commit makes the account
editor dialog only visible through explicit activation of the
account row.
As a side effect, this commit temporarily makes removing an
account non-functional.
https://bugzilla.gnome.org/show_bug.cgi?id=774222
We want to check the IsLocked property whenever we call
show_page_account. ie. when we show an account for the first time, and
also when the displayed account emits account-changed. Hence it is
better to have them together.
https://bugzilla.gnome.org/show_bug.cgi?id=774222
