summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* event: Don't assume UTC if timezone can't be readfail-in-the-face-of-broken-timezonesRay Strode2022-10-242-12/+36
| | | | | | | | | | | | | glib currently doesn't read the timezone properly from Toolbx containers. This leads GNOME Calendar to sometimes assuming the the timezone is UTC. (See https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2955) Assuming an arbitrary timezone (even UTC) when the timezone isn't available isn't great behavior. It's better to fail, I think. This commit makes it fail in that case.
* Update Hebrew translationYosef Or Boczko2022-10-231-9/+9
|
* Post-release version bumpGeorges Basile Stavracas Neto2022-10-171-1/+1
|
* 43.143.1Georges Basile Stavracas Neto2022-10-172-0/+5
|
* core/recurrence: Port to gatomicrefcountgbsneto/recurring-event-editing-fixesGeorges Basile Stavracas Neto2022-10-172-4/+4
|
* core/manager: Remove old hack around recurrencesGeorges Basile Stavracas Neto2022-10-171-9/+0
| | | | We handle it all before reaching GcalManager now.
* event-editor/dialog: Properly handle editing recurrent eventsGeorges Basile Stavracas Neto2022-10-171-3/+116
| | | | | | | | | | | | | | | | | | | When a recurrent event is edited, we now are able to only offer the MOD_ALL option when it actually will work. However, we're still left with the problem that we end up applying the instance-specific data onto the main event, through an old hack. The views already aren't able to offer the MOD_ALL property, since they all change the dates of events, but GcalEventEditorDialog can, and it must handle that properly. For now, do the simplest possible approach, which is: retrive the template event and apply all properties that can be applied to it, without letting the start and end days leak into it. We already only allow passing MOD_ALL on situations where the dates aren't really modified, so it should be safe. Fixes https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/882
* event-editor/dialog: Improve detection of MOD_ALL exclusion casesGeorges Basile Stavracas Neto2022-10-173-11/+26
|
* event-editor/dialog: Don't hide dialog on cancelling operationGeorges Basile Stavracas Neto2022-10-171-5/+8
| | | | | If the user clicks the "Cancel" button, it obviously means "cancel", so let's cancel.
* core/event: Fix transfer annotationGeorges Basile Stavracas Neto2022-10-171-1/+1
|
* window: Properly hide start headerbar buttonsGeorges Basile Stavracas Neto2022-10-171-2/+2
| | | | Fixes https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/859
* event-editor/schedule: Trivial autoptr cleanupGeorges Basile Stavracas Neto2022-10-171-3/+1
|
* event-editor/dialog: Don't ask mod type if event wasn't recurrentGeorges Basile Stavracas Neto2022-10-171-1/+8
|
* event-editor/dialog: Don't show MOD_ALL if schedule changedGeorges Basile Stavracas Neto2022-10-171-1/+11
| | | | | | | | | | | We get into seriously tricky situations if we try and change the date & time of an event with recurrency, and pass MOD_ALL. That's because it is ambioguous *where* the change must be applied. Don't allow selecting MOD_ALL when the scheduling of the recurrent event changes. Fixes https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/882
* event-editor/dialog: Don't apply changes if nothing changedGeorges Basile Stavracas Neto2022-10-171-0/+16
| | | | | This saves some cycles by not doing anything when nothing needs to be done.
* event-editor/sections: Add vfunc to check for changesGeorges Basile Stavracas Neto2022-10-177-0/+185
| | | | | This will be useful for next commits where we will need to check if the schedule section actually changed something.
* event-editor/dialog: Don't apply changes to readonly eventsGeorges Basile Stavracas Neto2022-10-171-3/+3
| | | | | In practice this never does anything relevant, because widgets are insensitive, but it's better not to nonetheless.
* views: Don't show MOD_ALLGeorges Basile Stavracas Neto2022-10-173-3/+3
| | | | | | | | | | The only field that views may change using DnD is the start date field (and, consequently, the end date), and that's exactly what we must not show the MOD_ALL option for. Don't show it. Related: https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/882
* utils: Add boolean flag for showing MOD_ALLGeorges Basile Stavracas Neto2022-10-176-1/+10
| | | | | This will be used by next commit to more finely control editing of recurrent events.
* manager: Remove unnecessary commentGeorges Basile Stavracas Neto2022-10-171-8/+1
|
* event-widget: Properly dispose template childrenGeorges Basile Stavracas Neto2022-10-172-2/+4
|
* event: Trivial style fixGeorges Basile Stavracas Neto2022-10-171-1/+1
|
* calendar-monitor: Properly update and delete recurrent eventsGeorges Basile Stavracas Neto2022-10-171-0/+159
| | | | | | | | | | | | | | | | | When we receive the 'objects-modified' signal, we get components that may represent main events. We also may receive components that have no recurrency because they were just changed from being recurrent to non-recurrent. We need to handle all these cases properly. If the event has no recurrency set, remove any potential old recurrence instance lingering around. If we're changing an event with recurrency, make sure the recurrency instances are in sync with the new recurrency. Fixes https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/881 (or so I hope.)
* calendar-monitor: Move events hash table to shared sectionGeorges Basile Stavracas Neto2022-10-171-12/+27
| | | | | | We'll start accessing the hash table from multiple threads, so it must be in the shared section of the structure, and it must be encapsulated by locking.
* calendar-monitor: Simplify locking code a bitGeorges Basile Stavracas Neto2022-10-171-12/+8
| | | | | Use GRWLock*Locker to simplify the locking code in a couple of places.
* calendar-monitor: Replace mutex by a rw-lockGeorges Basile Stavracas Neto2022-10-171-11/+13
| | | | | This will be more appropriate once we start accessing the events hash table from the monitor thread.
* calendar-monitor: Shuffle some variables aroundGeorges Basile Stavracas Neto2022-10-171-6/+8
| | | | Move them to where they're used.
* Update Icelandic translationSveinn í Felli2022-10-171-66/+80
|
* window: Fix crash in toast animationfix-toast-crashRay Strode2022-10-141-1/+1
| | | | | | | | | | | | | | Every once in a while when I'm deleting an event gnome-calendar crashes. I dug in a bit, and it seems the reason is adw_toast_overlay_add_toast takes ownership of the passed in reference. This is a little idiosyncratic for something that's not GInitiallyUnowned, but it appears to be the API nonetheless. GCalWindow assumes it owns the reference. This commit makes both users of the toast happy by adding a ref call.
* Update Hebrew translationYosef Or Boczko2022-10-121-9/+10
|
* gcal-week-grid: Fix wrong x postion for events in RTLYosef Or Boczko2022-10-121-1/+1
| | | | | | | | | | | Every event in RTL languages is drawn in the wrong place. As a result the week view is totally unusable. Fix this. #817 Signed-off-by: Yosef Or Boczko <yoseforb@gmail.com>
* Misc: Fix GObject property types for GLabel::xalign/yalign propertiesMilan Crha2022-10-062-4/+4
| | | | | | | | | When running under valgrind, it claims that there's used uninitialized memory, which is set as GObject property in the code. It's for GtkLabel::xalign. The problem was that the value in the code is an integer, but the property itself expects float type. This fixes the place and where a floating point is already used it annotates the value to be float, not a double.
* gcal-window: Event deletion aborts unfinished previous delete attemptMilan Crha2022-10-051-1/+3
| | | | | | | | | Cannot use g_clear_pointer() here, because it unsets the pointer first and only then calls the free function, which means the test on self->delete_event_toast NULL-ness would be satisfied in the on_toast_dismissed_cb(), thus the previous event delete attempt would be "cancelled" internally. Closes https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/858
* gcal-event-editor-dialog: Use user-chosen mode in ↵Milan Crha2022-10-051-1/+1
| | | | | | | | on_ask_recurrence_response_save_cb() ...to do what the user asked for. Closes https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/871
* gcal-month-view: Use gcal_view_set_date() to update date on scrollMilan Crha2022-10-051-1/+2
| | | | | | | This way the content of the view is updated properly, otherwise only internal GDateTime structure had been updated, but not the view itself. Closes https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/868
* gcal-date-chooser: Update also `combined_choice` in set_date()Milan Crha2022-10-051-2/+1
| | | | | | | | Thus it's in sync with the rest of the date chooser. Also use a common function to replace `self->date` value. Related to https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/868
* gcal_set_date_time: Avoid possible use-after-freeMilan Crha2022-10-051-2/+3
| | | | | When the `*dest` and `src` are the same, doing g_date_time_unref() can free the instance before it's assigned back to the `*dest`.
* date-chooser: Update combined-choice on date changesFlorian Müllner2022-10-051-0/+1
| | | | | | Otherwise the header will not reflect the active date. https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/876
* flatpak: Remove `gtk3` from gcr optionsDimitrios Christidis2022-10-051-1/+0
| | | | Refer to https://gitlab.gnome.org/GNOME/gcr/-/issues/100
* Update Bulgarian translationAlexander Shopov2022-10-021-2/+9
|
* Update Georgian translationZurab Kargareteli2022-10-011-2/+2
|
* Update Abkhazian translationNart Tlisha2022-09-291-49/+3946
|
* Update Georgian translationZurab Kargareteli2022-09-281-2/+9
|
* Update Slovak translationDušan Kazik2022-09-271-68/+85
|
* Update Friulian translationFabio Tomat2022-09-251-47/+76
|
* Updated Spanish translationDaniel Mustieles2022-09-211-5/+9
|
* Update Brazilian Portuguese translationRafael Fontenelle2022-09-201-8/+12
|
* Updated Czech translationMarek Černocký2022-09-181-3/+10
|
* Update Turkish translationSabri Ünal2022-09-181-211/+10
|
* Update Hungarian translationBalázs Úr2022-09-181-5/+11
|
View Lorry Controller Status