summaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
* avatar: set pixbuf to null if avatar is removednielsdg/avatar-buttonNiels De Graef2023-02-211-1/+3
| | | | | This fixes an issue where removing an avatar from a contact would not update the UI, as the current pixbuf would still keep being displayed.
* Add EditableAvatar custom widgetNiels De Graef2023-02-214-24/+83
| | | | | | | | | Rather than awkwardly shoehorning an `AdwAvatar` into a button, let's be a bit more helpful and just overlay 2 buttons, one for editing and one for deleting the avatar. Fixes: https://gitlab.gnome.org/GNOME/gnome-contacts/-/issues/217 Fixes: https://gitlab.gnome.org/GNOME/gnome-contacts/-/issues/26
* Stop using GtkDialognielsdg/no-more-gtkdialogNiels De Graef2023-02-205-160/+74
| | | | | GtkDialog is going to be deprecated in the next version of GTK, so stop using it upfront to avoid the deprecation warnings.
* general: Shorten tooltipsAutomeris naranja2023-02-191-1/+1
| | | | | | | | This change shorten tooltip texts (using header capitalization), following the tooltip examples provided by HIG. Tooltip examples can be seen at: https://developer.gnome.org/hig/patterns/feedback/tooltips.html
* main-window: Add a menu item to export all contactsNiels De Graef2023-02-122-4/+17
| | | | Fixes: https://gitlab.gnome.org/GNOME/gnome-contacts/-/issues/285
* Add shortcuts for saving/canceling contact editNiels De Graef2023-02-121-7/+23
| | | | | Allow saving a contact by pressing `<Ctrl>Enter` or cancelling by pressing `Escape`.
* editor: Allow removing a birthdayNiels De Graef2023-02-121-13/+32
| | | | | | | Add a little trash button at the end of the row so we can actually unset a birthday too. Fixes: https://gitlab.gnome.org/GNOME/gnome-contacts/-/issues/280
* Add Ctrl+F shortcut for searching contactsNiels De Graef2023-02-111-0/+5
| | | | Fixes: https://gitlab.gnome.org/GNOME/gnome-contacts/-/issues/268
* Use less return_val_if_fail checksNiels De Graef2023-02-114-39/+38
| | | | | | | | | | | | | In C, we often check preconditions in our functions using `g_return_if_fail()` or `g_return_val_fail()`, which are macros that expand to the condition they're checking for so the logs clearly show what might be going wrong. Vala also exposes these functions, but given that Vala compiles to a lot of jibberish temp variables, the output is not quite vague. Try to use the Vala equivalent `requires` to do something similar (unfortunately, we can't use this everywhere as it can only be used at the beginning of a mehod).
* contact: Add QR code to share individual contactsHendrik Müller2023-02-113-10/+135
| | | | | | | | | | | Sharing contacts in an easy and offline way is currently not possible. Most mobile phones have a camera and are capable of scanning QR codes. The vCard format is widely used to easily exchange contact information. A contact can be saved in vCard format into a QR code. A button with a QR code icon is added next to the "favourite" and "edit" buttons. When the user presses this button, a dialog opens up, which shows a QR code containing the current contacts data in vCard format.
* primary-menu: Rename IDs and tooltipHari Rana2023-02-091-2/+2
| | | | | | | | This replaces the standard popover menu's ID to primary_menu, and renames the tooltip to "Main Menu" Per the GNOME HIG, the standard popover menu is called Primary Menu, and tooltip/accessibility label is "Main Menu" Source: https://developer.gnome.org/hig/patterns/controls/menus.html#primary-menus
* Show leap day birthdays on February 28th in non-leap yearsRuben Schmidmeister2023-01-122-4/+26
|
* application: Fix "Send an Email to %s" tooltip seems untranslatedsabriunal2022-12-021-1/+1
| | | | | | | | "Send an email to " tooltip seems untranslated. This patch corrects closing bracket. Fixes: #281
* application: Add shortcut support for preferencessabriunal2022-12-021-0/+1
| | | | | | | | Ctrl+comma is a standard shortcut for Preferences across GNOME. Add support for it to comply GNOME HIG. More information: https://developer.gnome.org/hig/reference/keyboard.html
* Make goa an optional dependencyNiels De Graef2022-10-233-3/+11
| | | | | | | GNOME Online Accounts has some pretty big changes on its roadmap and doesn't make any promises on API stability. The only use of the API at this point is to fetch the icon for a GOA-backed address book, so it isn't really problematic if users disable support for it
* store: Make sure we don't add individuals twiceNiels De Graef2022-10-111-1/+1
| | | | | | | | | | | | | | | | | | | | | An individual can appear several times in the `changes` argument of the `IndividualAggregator`'s `individuals-changed-detailed` signal, in the case of linking. When 2 Individuals are linked -let's call them A and B- into a single Individual C, then the signal will be emitted with the following map: ``` A -> C B -> C ``` In other words, C will show up twice in the list of values. Since we weren't checking whether an individual already existed before adding it to the `to_add` list, duplicates were a possibility. This should no longer be the case (and from a quick check, it doesn't have any non-negligible performance impact either). Fixes: https://gitlab.gnome.org/GNOME/gnome-contacts/-/issues/247
* contact: Copy the chunks before applying changesNiels De Graef2022-10-111-4/+7
| | | | | | | | | | | | | | | When applying the changes of certain fields, we've seen that this leads to a `individuals_changed_detailed()` being called with the same individual in the `removed` and `added` set. The signal callback propagates to several layers, until it lands in the `Contact:on_individual_personas_changed()` function. There, all chunks related to the persona are removed, even when we still might be applying changes of some of the other chunks. The `apply_changes()` method in other words should keep its own copy to prevent that. Fixes: https://gitlab.gnome.org/GNOME/gnome-contacts/-/issues/271
* Keep track if a chunk has changedNiels De Graef2022-10-1116-23/+330
| | | | | | | | | | | | | | | | | | | Introduce a property `dirty` which signifies if a `Contacts.Chunk` chagned compared to its original value. That way, we can make sure we don't try to save a property that didn't change, saving us some necessary work. Although normally folks does a similar check, it's still good to prevent going into folks (or anything similar) in the first placE. As a side effect, it solves a problem we currently had with the `NicknameChunk`: when calling `save_to_persona()`, it erroneously represented an empty value as both `""` and `null`. Since those are different, it would try to save them and the E-D-S would time out in that case (and throw an appropriate error). As a consequence, when editing a contact, Contacts would always get blocked on the "nickname" property. Fixes: https://gitlab.gnome.org/GNOME/gnome-contacts/-/issues/271
* pane: Select the new individual after saving changesNiels De Graef2022-10-092-3/+27
| | | | Fixes: https://gitlab.gnome.org/GNOME/gnome-contacts/-/issues/271
* editor: Don't use null propertiesNiels De Graef2022-09-291-0/+3
| | | | | Since we had to add an explicit null-terminator for Vala, we have to make sure we guard against it in our code .
* editor: make sure properties have null terminatorNiels De Graef2022-09-131-0/+2
| | | | | | | | We thought that Vala would properly know about a normal `string[]` and null-terminated `string[]`, but apparently it doesn't. Worse, it seems that on systems it knows how to deal with this, but not on other systems where it just crashes. Fixes: https://gitlab.gnome.org/GNOME/gnome-contacts/-/issues/266
* ContactEditor: show property with an animationNiels De Graef2022-09-081-10/+16
| | | | | | As of the port to `Contacts.Chunk`, we had a minor regression that new properties that were being added were not shown with an animation. This is now fixed.
* store: Fix ignoring newly added individualsNiels De Graef2022-09-081-2/+4
| | | | | | | | Apparently, Vala isn't smart enough to be able to deal with a `foreach` statement and remove elements at the same time, leading to some unexpected results. This commit fixes it by just using a classic index-based `for`-loop.
* utils: Ensure pure key-file individuals are ignoredNiels De Graef2022-09-081-12/+10
| | | | | | | | Since linking is done by creating entries in the `relationships.ini` file which end up as a Persona, we can have an individual which consists of multiple Personas, all from the key-file backend. This is not something we accounted for in the `Utils.is_ignorable` function, so this commit fixes that.
* Create a "core" static libraryNiels De Graef2022-09-084-23/+58
| | | | | | The mainly useful thing about this is that we now have a way of testing our core logic which got added as we created the `Contacts.Chunk` concept.
* Move link suggestions to Contacts.StoreNiels De Graef2022-09-083-37/+37
| | | | | That way, the Utils namespace doesn't need to know about `Contacts.Store` which is not part of "core".
* Move primary address book logic to Contacts.StoreNiels De Graef2022-09-084-8/+13
| | | | | | It already contains most of the logic of the primary store due to it containing the `Folks.IndividualAggregator` which holds this too, so it makes sense to pull it out of Utils and move it there instead.
* Remove AddressbookDialogNiels De Graef2022-09-083-87/+0
| | | | | This is no longer used now that we have ported this to be part of the preferences window
* utils: Cleanup and remove all Gtk/Adw related methodsNiels De Graef2022-09-086-59/+16
| | | | | | | | | We had quite a few functions that were no longer being used or had only one specific user (so we can remove it from the generic `Utils` namespace). Finally, by removing all UI-related functions (those using GTK or libadwaita) we allow moving it into the "core" library
* Make sure `BinChunkChild`ren are sortedNiels De Graef2022-09-083-79/+48
| | | | | | | | | | | | Certain child properties should be sorted differently from others, namely the ones tagged as the "preferred" value (like the vCard PREF attribute) and any empty ones (which we would like to keep at the bottom). This means we can also remove the `AbstractFieldSorter` class, as that stopped being used when we ported everything to use the `Chunk` class (but we did forget to port its logic, which is now done with this commit)
* Move TypeDescriptor related items to coreNiels De Graef2022-09-084-4/+3
| | | | And remove an unused reference to `Gtk.TreeIter` in `TypeDescriptor`
* contact: Don't use Gtk.INVALID_LIST_POSITIONNiels De Graef2022-09-081-3/+3
| | | | | | | Try to avoid using GTK in the core logic. Since we know it's not really realistic we'll get an overflow for the properties on a specific contact, we can just solve this case by using a signed integer and returning -1.
* contact: Don't keep a reference to the storeNiels De Graef2022-09-082-24/+13
| | | | | | | | | | | | | | | First, we're only using the `Contacts.Store` to get to the aggregator's primary store, which we can just get from the `Folks.PersonaStore.is_primary_store` property itself. Second, this means we can make the constructor for a `Contact` a bit simpler, as we don't have to actually pass on a `Contacts.Store` reference. Third, this parameterizes `apply_changes()` so that it can choose which PersonaStore to save new details into, which is a step towards being able to configure the address book when you're editing/creating a contact.
* contact: Avoid ChunkFilter for finding chunksNiels De Graef2022-09-081-18/+27
| | | | | | | | The ChunkFilter class is an easy way of filtering out properties. However, it's not part of "core", so we probably shouldn't using it from within `Contacts.Contact`. This is also a slight performance optimization since we can avoid some of the overhead from using a `GtkFilterListModel`, as well as some unnecessary refcounting.
* Contact: allow the contacts store to be nullNiels De Graef2022-09-061-9/+17
| | | | | | | | | | | | | | | | We need to know about the primary store in a `Contacts.Contact` for 2 reasons: 1. To find out which persona is the "primary" persona (if there is one) 2. To save any new properties (which are not linked to a persona) in the primary store However, in some cases we do not have a special need for these 2 properties: in unit tests, and when we want to port our (de-)serialization code to work with an array of `Contacts.Contact` objects (especially with the importer being in a separate process). In those cases, it should be allowed to pass `null` instead.
* main-window: Drop the current contact after the transitionAdrien Plazas2022-09-031-0/+1
| | | | | | This avoids the current contact to instantaneously disappear as the transition is running or as we the user is swiping back, and close the contact only once the contact pane is hidden.
* Emit a log message if no address books are foundNiels De Graef2022-09-031-0/+12
| | | | | | | | | On a well configured system, this shouldn't happen since we expect something like E-D-S to be running. Of course, distro bugs can happen, and people can always screw up their system, so at least put a log message asking them if something like E-D-S is running. Related: https://gitlab.gnome.org/GNOME/gnome-contacts/-/issues/179
* Mark some import/export related strings as translatableNiels De Graef2022-09-032-3/+3
| | | | | | | | | When adding the feature to import and export contacts, we forgot to make some strings translatable. Piotr found these, so let's mark them as such (we're already in string freeze, but the alternative is that these won't be translated anyway). Fixes: https://gitlab.gnome.org/GNOME/gnome-contacts/-/issues/263
* Introduce the concept of Contacts.ChunkNiels De Graef2022-09-0335-2200/+3084
| | | | | | | | | | | | | | | | | | | | | | | | | | This commit introduces a new class `Contacts.Chunk`. Just like libfolks, we see a contact as a collection of data, or to word it differently: a collection built up from "chunks" of information. The net result of adding this concept adds quite a bit of lines of code, but it does have some major benefits: * Rather than stuffing new properties into yet another if-else spread out over multiple places in contacts-utils (and quite a bit of other files), we can create a new subclass of `Contacts.Chunk` * This also goes for property-specific logic, which we can consolidate within their appropriate classes/files. * All of our logic is now unit-testable In the future, this would allow for more cleanups/features: * We can put the serialization code for each property inside the `Contacts.Chunk` * We can extend ContactSheet to show a vCard's information, before actually importing it into a Folks.Individual. * We can write unit tests on the set of chunks, rather than regularly having to deal with yet another regression in e.g. the birthday editor.
* query-filter: Optimize for empty SimpleQueryNiels De Graef2022-08-271-0/+4
| | | | | | | | | When starting the application (or when the user removes the input from the search entry), the `QueryFilter` object we use to filter our contacts will match any item. GTK allows us to specify this in the `get_strictness()` method by returning `Gtk.FilterMatch.ALL`, which is a performance improvement, as it doesn't have to iterate over all the items in the list anymore.
* Fix typo (founds->found)Anders Jonsson2022-08-261-1/+1
|
* Create a custom sorter for AbstractFieldDetailsNiels De Graef2022-08-175-65/+109
| | | | | | This allows us to split off the logic for filtering and sorting personas from the generic `Utils` namespace, and allows us to expand on our GListModel usage, which allows for some bigger cleanups planned ahead.
* utils: Remove some unused functionsNiels De Graef2022-08-171-24/+0
|
* Add a GtkFilter and GtkSorter for PersonasNiels De Graef2022-08-176-80/+170
| | | | | | This allows us to split off the logic for filtering and sorting personas from the generic `Utils` namespace, and allows us to expand on our GListModel usage, which allows for some bigger cleanups planned ahead.
* query-filter: Optimize for SimpleQueryNiels De Graef2022-08-171-4/+44
| | | | | | | | | | | | Before this commit, the QueryFilter used a very naive implementation where it would just re-filter all contacts if something change (like a query string). This wasn't of course the most performant thing to do, and after some investigation we found out that on each search bar change, we were using quite some CPU. This commit adds some optimizations by avoiding unnecessary refiltering of contacts where possible. This shaves off quite a few percentages of CPU usage when doing some searching in the side bar.
* main-window: Unselect sidebar item in a less janky wayAlexander Mikhaylenko2022-08-121-3/+4
| | | | | Don't wait for the animation to end, just do it on visible-child changes instead. Do it when folding while on the contact list pane as well.
* Fix unselecting sidebar itemAlexander Mikhaylenko2022-08-124-14/+23
| | | | | | | | | | | Multiple things here. - The selection model state was mever synced back to the list - The selected == null codepath didn't work - unselect_all() does nothing with GtkSingleSelection - gtk_list_box_unselect_all() does nothing with BROWSE selection mode Fixes https://gitlab.gnome.org/GNOME/gnome-contacts/-/issues/262
* contact-sheet: Set wrap mode for the name labelAlexander Mikhaylenko2022-08-121-0/+1
| | | | Don't go offscreen with too long names.
* contact-sheet: Set title-selectable property directlyNiels De Graef2022-08-091-3/+1
| | | | | We depend on libadwaita 1.2 now, so we no longer have to check whether the property exists already.
* accounts-list: Don't autoselect an address bookNiels De Graef2022-08-081-1/+3
| | | | | | | | | | | | | There's 2 reasons why we don't want the AccountsList widget to automatically select an address book: 1. In the initial setup, we want a user to explicitly choose which address book they'd like to use for storing contacts 2. We haven't setup the selection_changed handler yet, meaning the "selected-store" property will not get notified of the initial selection. Fixes: https://gitlab.gnome.org/GNOME/gnome-contacts/-/issues/260
View Lorry Controller Status