!44 (comment 1597981)

Jan Alexander Steffens (heftig) authored Nov 09, 2022 and Lubomir Rintel committed Jan 09, 2023

This one needs to be relocatable, otherwise creating a new VPN
connection will fail with:

    settings object created with schema 'org.gnome.nm-applet.eap'
    and path '/org/gnome/nm-applet/eap/<uuid>/',
    but path '/org/gnome/nm-applet/eap/' is specified by schema

Fixes: https://bugs.archlinux.org/task/76490

!44

!50

If there's a very small provider database or iso-codes not installed or
anything like that, don't bother the user with a country picker.

!49

!48

!47

!46

!45

We use the iso-codes database to get a nice country name for a level 1
(country) alpha-2 (two-letter) code used in the mobile-broadband-database.
This generally works well, as the areas where mobile providers operate
generally have ISO 3166-1 codes assigned. That is, all but Kosovo.

The mobile-broadband-database uses the "user-assigned" "xk" code for
Kosovo, like many countries and international organizations alike use.
This, unfortunatelly, means that we can't use iso-codes to get the full
name.

We could, in theory, use the level 2 code "rs-km", which places the area
inside the Republic of Serbia. That would not affect how we structure
things, but would require us to load the level 2 (districts) database that
is considerably larger than level 1 (countries). Also, the naming in the
iso-codes database is a little confusing at the moment (see
https://salsa.debian.org/iso-codes-team/iso-codes/-/merge_requests/29).

Instead, let's allow including a human-readable name in the database itself
like this:

  <country>
    <name>...<name>
    <provider>
    ...

The name serves as a fallback. It stays in English and is not
translated, but still better than nothing I suppose.

Related mobile-broadband-providers change:
mobile-broadband-provider-info!90

We use the iso-codes database to get a nice country name for a level 1
(country) alpha-2 (two-letter) code used in the mobile-broadband-database.
This generally works well, as the areas where mobile providers operate
generally have ISO 3166-1 codes assigned. That is, all but Kosovo.

The mobile-broadband-database uses the "user-assigned" "xk" code for
Kosovo, like many countries and international organizations alike use.
This, unfortunatelly, means that we can't use iso-codes to get the full
name.

We could, in theory, use the level 2 code "rs-km", which places the area
inside the Republic of Serbia. That would not affect how we structure
things, but would require us to load the level 2 (districts) database that
is considerably larger than level 1 (countries). Also, the naming in the
iso-codes database is a little confusing at the moment (see
https://salsa.debian.org/iso-codes-team/iso-codes/-/merge_requests/29).

Let's just make sure Kosovo is always there until ISO makes its mind up.

This helps us ensure the mobile wizard returns the correct results.

We were looking for them in /usr/locale instead of /usr/share/locale.

That said, /usr/share/locale still might not be an entirely correct path
for the iso-codes installation, because the iso-codes files are looked
for in other directories than the global /usr.

Let's look for the translations in the same prefix as the xml files
themselves.

This helps us make check that the translations work properly.

This makes Robert happy:
gnome-control-center!1461 (comment 1593727)

Conditionalize it on minimal version requirement, so that we don't
accidentally step on toes of anyone who'd have hooked the cleanup
function themselves. Also makes sure someone who'd want their code to
build against older libnma won't use that accidentally.

To be used by autoptr macro guards.

Use double underscores so that it is absolutely clear to everyone it's
not to be used or relied on as a part of a public API or anything.

This saves disk space of over 0.001302083 times the capacity of a standard
IBM-formatted (the one with 9 sectors per track, not 8) double-sided
double-density 5.25" floppy disk.

It's probably an uphill battle against translator tast to keep this
too tidy, but let's at least obviously wrong things. These include:
bogus copytight notices, untemplated things, wrong project name.

The motivation behind this is that some of the gunk left behind (such as
old branch names) don't meet our conscious language standards.

Done with "msgattrib --no-obsolete".

This drops a fairly large amount of strings inherited from
network-manager-applet.

The motivation behind this is to get rid of strings that don't meet
our conscious language standards.

Newer gcr pre-release removed the widgets and therefore the library is
not reliant on Gtk anymore, no matter which version. That's good -- we
were only using the GcrCertificate, not the widgets.

Details here:
gcr#100

In fact, we weren't even needing the UI part of gcr-3, just the
gcr-base-3 part. That would've not conflicted with Gtk4.

This allows use to simplify things considerably: both gcr-base-3 and
gcr-4 are fine for use for either Gtk3 or Gtk4.

!43

In commit 50cda26a ('gschema: move "org.gnome.nm-applet.gschema.xml"
from network-manager-applet to libnma'), this schema was moved over from
nm-applet even though all we need is "org.gnome.nm-applet.eap".

That's rather unfortunate, because it's sort of difficult to undo
without breaking some versions of nm-connection-editor.

Let's split off the part we need (org.gnome.nm-applet.eap), but keep the
other half (org.gnome.nm-applet) in place for now, until we give
nm-applet users a chance to upgrade to a version that has has it.

Packagers can just choose to remove the file (e.g. %ignore in RPM) and
ensure their nm-applet is new enough.

!42

This pops up the chooser even if nobody pressed the button.
This reverts commit 7d58bf85.

It's not maintained or useful for anything.

NorwayFun authored Sep 07, 2022 and Lubomir Rintel committed Sep 08, 2022

!40

!38