Switch from GtkBuilder to using GtkTemplate.
Rename .[ch] and .ui files to standard names.
Rename widget IDs to be more readable.
Drop widget IDs that are not used.
Move code into the .ui file that can be.
Connect signals in swapped form.
The UmUserManager object could last longer than the panel. Use
g_signal_connect_object to do this automatically. Remove manual old method.
Connect signals in swapped form.
Users panel crashes with g_error() if some of libpwquality calls fails,
e.g. when pwquality.conf is broken. The default values should be used
instead of crash. Let's use g_warning() instead of g_error() in that
case.
https://gitlab.gnome.org/GNOME/gnome-control-center/issues/171
um_password_dialog_set_user() is called from on_permission_changed()
respective show_user(), which more or less means on every change in
the panel. It it pretty enough to call this before opening the password
dialog, which is already done over change_password() callback. Let's
remove the redundant call which may lead to unwanted failures among
others.
https://gitlab.gnome.org/GNOME/gnome-control-center/issues/171
"warning: passing argument 1 of ‘gtk_widget_destroy’ from incompatible
pointer type" is printed from g_clear_pointer, because it is more
type-safe now. See https://gitlab.gnome.org/GNOME/glib/issues/1425 for
more info. Add the necessary casts to suppress the warnings.
The commit targets to remove the behavior of implicit set of the language
when the user panel is clicked in g-c-c.
The behavior looks like introduced to partly resolve the bug [0] when the
gnome-initial-setup somehow did not set the language correctly. However the
gnome-initial-setup is able to handle the language nicely now.
Furthermore, the current user could not see its own language chooser in the
g-c-c User panel, instead the Region&Language panel is supposed to do the
task. And the Region&Language panel has already got a default locale set [1]
[2]. So even if the language is not set in the key file, it is less an issue
nowadays than when the issue was originally described in [0].
[0] https://bugzilla.gnome.org/show_bug.cgi?id=737216
[1] https://bugzilla.gnome.org/show_bug.cgi?id=767065
[2] https://gitlab.gnome.org/GNOME/gnome-control-center/commit/5e2ed8ehttps://gitlab.gnome.org/GNOME/gnome-control-center/merge_requests/161
The Password dialog uses "Verify New Password" and Add User dialog
"Confirm". Let's use "Confirm New Password" as it is on mockups to
be consistent in terminology.
The logic for the password mismatch warnings didn't handle the case where
you deleted both the passwords - it would still show them as not
matching.
Fix this by handling the three cases:
- Passwords are different
- Passwords are the same
- No passwords entered
If <tab> is pressed and password is not yet validated (ie. the verify
entry is not sensitive), focus skips the verify entry, even if the
password is strong enough. Let's validate the password when <tab> is
pressed (ie. before focus change) to prevent this <tab> breakage...
https://gitlab.gnome.org/GNOME/gnome-control-center/issues/38
A variable of label widget, used for a hint when wrong enterprise
user/password is used, is not properly initialized and thus criticals
are shown instead of the hint when user/password is wrong. Let's bind
the variable properly.
cheese_camera_device_monitor_new freezes the whole panel when opening
for a couple of seconds if external camera is connected. This is not
acceptable. Probably it is bug in kernel. Let's use GAsyncInitable if
available.
Bump the cheese dependency accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=783789
So that we can run Settings more than once in GNOME Builder.
Without the -f flag, ln errs out after these symlinks are
created, and Builder refuses to run after that.
Commit ffe5aac8 introduced new set of face images and removed the old
ones. Consequently, generic avatar is shown for people after update.
Add back legacy images, so people won't lose their current images on
update. Add them into the subfolder and create symlinks for them,
so it can be simply filtered out from the chooser widget, because just
the new images should be shown.
https://gitlab.gnome.org/GNOME/gnome-control-center/issues/5
We want to add back legacy images, so let's rename the new ones to not
be in a conflict. This unfortunately can cause another breakage for
people which uses development versions, but we can't do much about it.
https://gitlab.gnome.org/GNOME/gnome-control-center/issues/5
The faces that are included in the users panel are really old,
the style is outdated and they are too small for modern designs
as well as hidpi screens.
https://bugzilla.gnome.org/show_bug.cgi?id=792243
In a specific cases, current user doesn't have to be returned from
accountsservice, or can be skipped by act_user_is_system_account check.
System users should not be shown. This is expected for root account,
but should not happen with regular user accounts. It needs to be fixed
in accountsservice if you see this happening with regular user accounts.
We have to be just sure that Users panel doesn't crash in such cases
and show all non-system user accounts returned from accountsservice.
Empty page is shown currently only if act_user_manager_list_users
returns nothing, but it has to be also shown if only system accounts
are returned. To fix this issue, do not try to show current user, but
show first user account in carousel instead if there is any. First user
account is current user in normal case.
The patch also fixes problems that current user account is sometimes
selected instead of currently selected user account. This is because
of preselection of first item in um_carousel_add, which causes unwanted
signal emissions...
https://bugzilla.gnome.org/show_bug.cgi?id=773673
There are eventually corner cases where there's no user other than
root in the system and control-center can be launched by the root
user (not recommended). In this cases, the panel crashes without
any user to show (since accountsservice would just list normal
users).
This patch introduces an empty state[0] "No Users Page".
[0] https://wiki.gnome.org/Design/OS/EmptyStateshttps://bugzilla.gnome.org/show_bug.cgi?id=773673
Currently we get MAXNAMELEN from glibc's LOGIN_NAME_MAX, if available,
and sysconf otherwise. But the maximum username length supported by
glibc and the kernel is actually way larger than the maximum length that
actually works in practice. On Linux, anything larger than 32 characters
is not going to fit into utmp, and will therefore be rejected by
useradd. Then gnome-control-center will spit out a confusing error
message dialog.
Let's spare our users from that.
useradd (in shadow-utils) gets its max name size from the following
magic:
/* Maximum length of usernames */
#ifdef HAVE_UTMPX_H
# include <utmpx.h>
# define USER_NAME_MAX_LENGTH (sizeof (((struct utmpx *)NULL)->ut_user))
#else
# include <utmp.h>
# ifdef HAVE_STRUCT_UTMP_UT_USER
# define USER_NAME_MAX_LENGTH (sizeof (((struct utmp *)NULL)->ut_user))
# else
# ifdef HAVE_STRUCT_UTMP_UT_NAME
# define USER_NAME_MAX_LENGTH (sizeof (((struct utmp *)NULL)->ut_name))
# else
# define USER_NAME_MAX_LENGTH 32
# endif
# endif
#endif
It's more work than necessary. utmpx is standardized by POSIX (it's
actually an XSI extension), whereas utmp is not, so let's just use
utmpx. This ought to work on at least FreeBSD as well. And if any free
operating systems that care about GNOME don't have utmpx yet, no doubt
they'll send patches.
https://bugzilla.gnome.org/show_bug.cgi?id=724193
We assume that we only generate valid usernames, so make sure they're
short enough to be used, else we'll display a dialog with a meaningless
error message when useradd fails.
Note that this commit doesn't completely fix the bug, as our definition
of MAXNAMELEN is different from useradd's.
https://bugzilla.gnome.org/show_bug.cgi?id=766401
