Set a margin for the username label instead of using the container
spacing property. In doing so the labels are not so far apart from
each other, but still distant from the profile icon/image.
https://bugzilla.gnome.org/show_bug.cgi?id=767065
UmCarousel is an horizontal container that contains UmCarouselItem
children. These items are paginated 3 at 3 at the time.
UmCarousel intents to act as controller for content containers. It
emitis the "item-activated" signal whenever an UmCarouselItem gets
activated (clicked).
It automatically activates the first UmCarouselItem of the current
vsible page.
The visibility of the go-back and go-next button is automatically
set based on the number of children.
These changes are according to the new User Accounts panel mockups
at https://wiki.gnome.org/Design/SystemSettings/UserAccountshttps://bugzilla.gnome.org/show_bug.cgi?id=767065
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
