Many users are confused by what external software is installed. Linking
to some documentation provides a chance to understand.

As usual, feel free to add your distro here.

The change to the password page is to avoid problems if the username
contains XML markup.

Fixes #182

Part-of: <https://gitlab.gnome.org/GNOME/gnome-initial-setup/-/merge_requests/253>

Part-of: <https://gitlab.gnome.org/GNOME/gnome-initial-setup/-/merge_requests/253>

Update versions & CI image for 47 development branch

See merge request GNOME/gnome-initial-setup!253

This reverts commit 7383e1d3.

Update CI image

See merge request GNOME/gnome-initial-setup!254

This, in between the things, ensures that the icon is loaded by Gtk
at proper scaling level when using HiDPI scaling

Since long time (e.g. GTK4 beginnings [1]) the GtkEntry's are never
focused while their GtkText child is, so check for that other than the
entry focus itself (that shouldn't ever happen, but kept for clarity).

This restore the logic for avoiding changing the user once it has
been customized.

[1] https://blog.gtk.org/2019/03/15/entries-in-gtk-4/

This is an issue that can be caused by switching between languages, that
ibus might receive "connected" signal after IBusBus is freed by the
language switch in the Language page, which will rebuild all other pages
in the assistant including keyboard selection.

keyboard: fix ibus signal race when language page causes page rebuild

See merge request GNOME/gnome-initial-setup!257

account-page-local: Properly check if the entry has focus

See merge request GNOME/gnome-initial-setup!256

summary: Use embedded themed icon as status page icon

See merge request GNOME/gnome-initial-setup!255

Dan Nicholson authored Apr 22, 2024 and Will Thompson committed Jun 27, 2024

Rather than moving the files from the gnome-initial-setup homedir, copy
them. In practice the files will almost always be copied anyways since
the g-i-s user's homedir is on a tmpfs in `/run` and the target user's
homedir is most likely to be on real storage. Always making it a copy
means it will behave the same way in all scenarios including testing.
Moving the file also means the file is deleted from the g-i-s homedir,
which just causes a bunch of journal spam during initial setup.

Dan Nicholson authored Apr 23, 2024 and Will Thompson committed Jun 27, 2024

This will make it much easier to test than having to monkey around with
the environment. I don't believe this is a security hazard since if you
can execute the program as the user with arbitrary arguments, you might
as will just do whatever you want to the files.

Dan Nicholson authored Apr 23, 2024 and Will Thompson committed Jun 27, 2024

Now that it's possible to run the copy worker with the source and
destination paths specified, it's possible to test the behavior without
going through a full initial setup. Test which files are copied as well
as their content and metadata.

Dan Nicholson authored Apr 22, 2024 and Will Thompson committed Jun 27, 2024

It's nice to copy the files with GFile since all the complexity is
hidden behind a single `g_file_copy` call. However, this brings in GVfs,
which makes it very difficult to start early in the session before D-Bus
is available.

Instead, use plan GLib/libc to copy the files. The semantics of what
metadata is copied should match what GFile was doing. This is hopefully
portable enough, but it does use a couple Unix specific APIs without the
full portability of GLib.

Fixes: #217

Rewrite copy worker without GIO

Closes #217

See merge request GNOME/gnome-initial-setup!251

This reverts commit 7eae913a:

> password: Keep old password page UI if parental controls are disabled
>
> While this means we are essentially maintaining three versions of the
> password page, it does mean that if parental controls are disabled,
> gnome-initial-setup doesn’t change its UI or translatable strings at
> all, i.e. doesn’t break UI freeze.
>
> This commit can be dropped in the next unstable development cycle.

This message was written in February 2020. The “next unstable
development cycle” it refers to was the cycle leading to GNOME 3.38.

The effect of this change is that, when setting up a system in the name
of Jane Bloggs, the password page for the user password (as opposed to
the parent password) will now always be titled:

> Set a Password for Jane Bloggs

regardless of whether Initial Setup was compiled with parental controls
support, and regardless of whether parental controls are being enabled.

::leave signal handlers do not return a value.

Previously, the first password entry would have the red “error” state,
even though the message explaining the error – “The passwords do not
match” – is below the confirmation field.

Instead, mark the confirmation field as in error in that case. (Of
course we can never know which of the two fields is the one that has the
typo from the user's point of view.)

Previously, the primary password entry field would be considered to be
in error even if it is empty, and marked in red. This looks awkward
because the user has done nothing wrong.

The password strength meter, however, correctly treats the "no password"
case differently to the state where the password is weak.  Do the same
for the field itself. Eliminate the valid_password field of the struct,
which is never checked outside this function.

Fixes https://gitlab.gnome.org/GNOME/gnome-initial-setup/-/issues/162

This matches Settings, which adopted this style together with its GTK 4
port.

Previously the password_changed() callback did not reset valid_confirm
before calling update_page_validation(), and update_page_validation()
checks valid_confirm and sets the page to complete or incomplete based
on its value.

There is still one residual difference between the handling of the
::changed signal between the two fields – typing in the primary password
field clears any error state in the confirmation field, but not
vice-versa – but I think this is clearer with an explicit condition in
a single callback, rather than two callbacks with one subtle difference.

This was accidentally checked in in commit
71c9e9e5, back in 2013, when the account
page was split in two.

password: Don't mark empty password field as error

Closes #162

See merge request GNOME/gnome-initial-setup!258

software: link to documentation of what is provided by external repo

Closes #182

See merge request GNOME/gnome-initial-setup!229

Mozilla Location Service was shut down earlier this year.

There are other ways that Geoclue can determine your location, so the
privacy toggle remains; but remove references to Mozilla Location
Service and its now-nonexistent privacy policy.

Fixes https://gitlab.gnome.org/GNOME/gnome-initial-setup/-/issues/214

privacy: Remove reference to Mozilla Location Service

Closes #214

See merge request GNOME/gnome-initial-setup!259

This is not ideal because the message is probably something like:

> Failed to create user 'a':
> GDBus.Error:org.freedesktop.Accounts.Error.PermissionDenied: Not
> authorized

But it is better than showing nothing.

summary: Show error when save_data fails

See merge request GNOME/gnome-initial-setup!260

When creating the user account, offers the user a way to hint what
is the password, in case they don't remind it later.

Based on an original patch by Alessandro Puccetti in Endless OS.
Reworked by Philip Withnall to use `g_auto*` and make the reminder
optional.  Reworked further by Will Thompson to use AdwEntryRow.

See https://gitlab.gnome.org/GNOME/gnome-initial-setup/-/issues/56

Currently the login screen does not show password reminders, so asking
users to set a reminder would give them false hope.

This patch can be reverted as and when the login screen can show
password reminders.

https://gitlab.gnome.org/GNOME/gnome-initial-setup/-/issues/56

password: Add password reminder

See merge request GNOME/gnome-initial-setup!261

(cherry picked from commit 9b472793840a92e91caa0c97aaaf6bd511cf0382)