The language input chooser is being created and destroyed every time
it is opened and closed. This is noticeably slow and is hardly
necessary as the values it contains should not change.
To fix this, these changes reuse the same instance of the input chooser
(by hiding and showing it) instead of renewing it.
The input chooser is also now shown using gtk_dialog_run to avoid having
it destroyed from the default delete event.
The first input source gets activated by default when users log in but
we don't currently allow users to set this (other than the awkward
remove all input sources and add them again in the right order).
Allowing user re-ordering of the input source list nicely allows users
to get the default input source they want.
https://bugzilla.gnome.org/show_bug.cgi?id=743400
Since we can't export IBus sources through the localed API we
shouldn't even allow users to choose them.
This allows us to stop having to show an apologising dialog which
makes us look a bit bad and was using deprecated gtk+ API that we're
trying to get rid of. Instead, we show the same information up front,
in the input chooser.
https://bugzilla.gnome.org/show_bug.cgi?id=740986
The notification is wider then window for some languages (e.g.
France). This patch allows wrapping, limits chars and changes
margin as a result of discussion on #gnome-design.
https://bugzilla.gnome.org/show_bug.cgi?id=703392
GtkListBox doesn't implement GtkScrollable so it needs to be added to
a GtkViewport. Instead of having to do this in all .ui files, add a
new helper function to setup the widget tree correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=732175
Missing org.freedesktop.locale1 means priv->permission will not be set
and will trigger a segfault when used by set_login_button_visibility().
Unconditionally not display the Login button if localed is not available
since it will be useless anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=723550
If the settings backends fail to give us valid values, show the
current environment instead of "None" since we do know which language
is actually being used.
https://bugzilla.gnome.org/show_bug.cgi?id=695535
Just like the system settings, the user's settings might be empty
because some other component failed before us. Still, we shouldn't
show an empty list since that looks broken.
https://bugzilla.gnome.org/show_bug.cgi?id=701871
On single account systems we don't show the login button but the user
should still be able to set system-wide locale settings. We can simply
export the user's own settings to the system in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=694922
1. Load region panel
2. Change language
3. Go back to overview
4. Load region panel
5. Change language
6. Crash
As the ActUser and ActUserManager object aren't reference counted,
we need to disconnect the signals ourselves when exiting the panel
otherwise we'll receive the signals from the old signal connection,
which will use the old panel object.
Instead of just making it sensitive/unsensitive. Quoting from the bug
report:
The problem is that it isn't clear to the user why the settings button is
insensitive for keyboard layouts - they'll be asking "why can't I ever use the
settings?"
https://bugzilla.gnome.org/show_bug.cgi?id=692006
This makes loading faster, with less I/O, avoids unnecessary
code duplication (around 1k lines shaved), and ensures that
all the panels link and work appropriately.
By the same token, it will stop external panels from being
created, and loaded.
https://bugzilla.gnome.org/show_bug.cgi?id=690036
