After temporarily removing the ability to delete accounts in
4e197b491f, let's start bringing it back again by adding a Remove
Account button to the account editor dialog, as per the recent mockups.
https://bugzilla.gnome.org/show_bug.cgi?id=774222
When adding an account, the old proccess was: use the (removed) toolbar
to open the New Account dialog, select a provider in that dialog, add
the account and see the newly created account in the panel itself.
That approach had issues, e.g. the user would have to close the dialog
if she mistakenly selected a provider. After moving the provider list
to the panel itself, it doesn't make sense anymore to have another
provider list inside the dialog.
Fix this by moving the new account view to the accounts dialog.
https://bugzilla.gnome.org/show_bug.cgi?id=774222
After successfully editing a default shortcut (and making sure the
"Set" button is sensitive), if the user clicks the '+' row to create
a new custom shortcut, the "Add" button is sensitive even with all
fields empty.
Fix that by ensuring the "Add" button is always insensitive whenever
we add a custom shortcut.
https://bugzilla.gnome.org/show_bug.cgi?id=777842
The "Add Printer" dialog should be smart enough to know whether
an item listed in the dialog is a samba server or just a printer.
If it is a samba server, it should go for the authentication page
instead of emitting a GTK_RESPONSE_*.
https://bugzilla.gnome.org/show_bug.cgi?id=778277
As described in the proposed mockups [1], the Keyboard panel
should have a Reset All button above the list of shortcuts that
allows the user to quickly reset all the shortcuts to their
default keybinding. The current implementation, however, lacks
this button.
Fix that by adding a "Reset All" button, and implementing the
reset all action. A message dialog is shown in order to confirm
the action, and custom shortcuts are not reset (unless the conflict
with the default keybinding of another standard shortcut).
[1] https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/system-settings/keyboard/keyboard-wires.pnghttps://bugzilla.gnome.org/show_bug.cgi?id=777840
The current shortcut editor state is managed by setting and
comparing the page name directly, making the code look more
complicated than it should.
Fix this by introducing the concept of pages, and using this
to set and get the current shortcut editor dialog state.
https://bugzilla.gnome.org/show_bug.cgi?id=777845
After introducing the reset button to match the mockups [1], the
shortcut editor dialog had some issues exposed. This is visible
e.g. when the user tries to edit a custom shortcut's name and
the shortcut is disabled.
This happens because we assume there is always a shortcut set.
When we open the dialog to edit a custom shortcut, however, nothing
is actually set, and we end up saving the disabled shortcut when
editing the shortcut's name or command.
Fix that by initializing the shortcut's accelerators when editing a
shortcut, and correcting the logic to validate the shortcut.
[1] https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/system-settings/keyboard/keyboard-wires.pnghttps://bugzilla.gnome.org/show_bug.cgi?id=777845
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
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
Following the mockups, the Online Accounts panel shall use a modal
dialog to edit online accounts.
This commit moves the current widgets to a dialog, and shows this
dialog whenever an account is selected.
Some changes by Debarshi Ray.
https://bugzilla.gnome.org/show_bug.cgi?id=774222
This regression has been introduced by commit 52da4da. The
info panel crashes if prettify_info() returns NULL. This happens
if Renderer property from SessionManager is empty.
https://bugzilla.gnome.org/show_bug.cgi?id=774240
List a printer in the "Add Printer" dialog as soon as it is
discovered. The header subtitle "Searching for Printers"
denotes that the Search is not done yet.
https://bugzilla.gnome.org/show_bug.cgi?id=760783
As part of the port to the redesigned Online Accounts panel,
the main widget to be displayed is a GtkListBox, so we can have
finer control of the UI elements and eventually be able to put
real widgets instead of using cell renderers.
This commit, then, makes the Online Account panel use a listbox
widget in the sidebar. The behavior of the panel was not changed.
Since its using a listbox now, we can drop the custom GoaPanelAccountsModel
class.
https://bugzilla.gnome.org/show_bug.cgi?id=774222
Calling gtk_style_context_set_junction_sides makes no visual
difference. We are using stock GTK+ containers, which should already
be taking care of this.
https://bugzilla.gnome.org/show_bug.cgi?id=774222
