| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
| |
Add a few more vCard tests to make sure we're not regressing on our
vCard import feature.
One of the design desicions at the time was to make the
`Contacts.Io.Parser` take a `GLib.InputStream` so we can make it
agnostic of what kind of input was given. We can now use this to make
the vCard tests a bit simpler in general by using a constant string
inside the test file rather than having to deal with environment
variables to pass on a path.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Rather than building a big if-else block in the `Contacts.Io` namespace,
it's much more interesting to move the GVariant serialization into the
`Contacts.Chunk` objects themselves. That allows us to keep the
serialization logic for a specific field in one place and makes sure we
don't forget about any properties as they're not part of that big
if-else block that checks on property name.
This commit also make sure a lot of the functionality here is now unit
tested, to make sure we're not accidentally regressing.
|
| |
|
|
|
|
|
|
| |
We weren't sending out a property notification for `is-empty` when the
underlying `Folks.PostalAddress` changed, which meant that editing a
contact would only allows for a single address.
Also add a test to make sure we're not regressing on this.
|
| | |
|
| |
|
|
|
|
| |
They're quite simple at this point, but the idea is to extend them as we
put some of the serialization code in there, as well as more advanced
logic.
|
| |
|
|
|
| |
It's not really a complex thing, but this is basically laying the
foundations for properly unit testing the classes in core
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit adds the experimental functionality in Contacts to import
VCard (*.vcf) files.
Since importing a contact means we have to take in untrusted/unvalidated
input, let's give a high-level view of what happens:
* Contacts starts a native file chooser dialog so the user can choose
which file to import
* According to the chosen file, Contacts will launch a subprocess to do
the actual parsing using a `Contacts.Io.Parser`. At this point, we
only have a single subclass, which allows importing VCards.
* The helper process serializes the result to a `GLib.Variant`, and
sends it to the main process, which will receive the result and
parses it again.
* After the parsing operation is done, we can then start up a
`ImportOperation`, which will import the contacts using libfolks' API.
Exporting contacts is quite a bit easier, since we don't have to deal
with untrusted input: we serialize the list of selected contacts and
asynchronously write each to the given output stream. In the app, that's
a user chosen file; in tests, that can be a string.
Fixes: https://gitlab.gnome.org/GNOME/gnome-contacts/-/issues/1
Fixes: https://gitlab.gnome.org/GNOME/gnome-contacts/-/issues/38
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit removes all remaining occurrences `using Gtk;`, `using Gee;`
and `using Hdy;`. There's a number of reasons why we're doing this, but
to list a few:
* The `Gtk` and `Hdy` namespaces have had issues before with types
having the same name (ie HdyHeaderBar and GtkHeaderBar) which could
suddenly break the build.
* By omitting namespaces, it's harder to see for new contributors what
the actual type is of a certain variable when they want to look up the
API
* In the long term, we want to get rid of Gee, as it's clear that it's
not really maintained, and has some serious performance drawbacks.
|
| |
|
|
|
|
| |
Use Emmanuele's script for GLib to parse the meson JSON-formatted
testlog to turn it into a JUnit XML which GitLab understands and cnn
report to the user in the web UI.
|
|
|
* Have a very basic test that calls something from Contacts.Utils, so we
know that it was able to properly compile and link.
* Some function access modifiers had to be changed to public, or they
wouldn't be recoginzed outside of the static library.
* Also make sure our CI actually runs the tests.
|
