Federated_Computer/federated-calendar
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
6,039 Commits 3 Branches 0 Tags
8a21b82e42b6dc8245eb6d3cccc8dbda033b33e1
Commit Graph
91 Commits
This Branch
This Branch
All Branches
Author SHA1 Message Date
Federico Mena Quintero 309a91ddcb Move GcalEventSchedule to new files gcal-event-schedule.[ch] 
I am not sure that these should be in src/core, since the
gcal_event_schedule_set_*() functions do have a bunch of GUI policy.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
 2025-08-27 20:18:52 -03:00
Federico Mena Quintero 8a653ec99d Rename GcalScheduleSectionValues -> GcalEventSchedule 
And correspondingly, gcal_schedule_section_values_*() -> gcal_event_schedule_*()

Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
 2025-08-27 20:18:52 -03:00
Federico Mena Quintero e9a626ed40 Handle the recurrence until-date with an action, not via the widgets 
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
 2025-08-27 20:18:52 -03:00
Federico Mena Quintero 8c0281aef5 Copy the recurrence, don't just ref it 
GcalRecurrence is shared/mutable.  So, if we have

  curr.recur = ref(event.recur)
  orig.recur = ref(curr.recur)

then recurrence_changed() will return false, since both orig.recur and
curr.recur will point to the same object.  We need fresh copies.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
 2025-08-27 20:18:52 -03:00
Federico Mena Quintero 7bb6549cb6 Handle the recurrence count with an action, not via the widgets 
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
 2025-08-27 20:18:52 -03:00
Federico Mena Quintero d65e1ff216 Add tests for the visibility of the widgets to control recurence limits 
Since changing the limit type changes the visibility of the "count" or
"until" widgets, we need to test that logic.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
 2025-08-27 20:00:18 -03:00
Federico Mena Quintero ca5bf2269f Add test for setting the recurrence limit to UNTIL 
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
 2025-08-27 20:00:18 -03:00
Federico Mena Quintero 98afcf3195 Remove superfluous "inline" 
This is not a hot code path and the keyword just adds noise.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
 2025-08-27 20:00:18 -03:00
Federico Mena Quintero dfe38af9ac Set the recurrence limit type via an action 
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
 2025-08-27 20:00:18 -03:00
Federico Mena Quintero 52a7021241 Set the recurrence frequency via an action function, not by poking the widgets directly 
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
 2025-08-27 20:00:18 -03:00
Federico Mena Quintero 74e784fb92 Use get_recurence_limit_type() in all places 
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
 2025-08-27 20:00:18 -03:00
Federico Mena Quintero 05fed3d9c6 Use get_recurrence_frequency() in all places 
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
 2025-08-27 20:00:17 -03:00
Federico Mena Quintero ffd66ff084 Add helper function to get GcalRecurrenceLimitType from the widgets 
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
 2025-08-27 20:00:17 -03:00
Federico Mena Quintero 13babc7a2e Don't use magic numbers in on_repeat_duration_changed_cb() 
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
 2025-08-27 20:00:17 -03:00
Federico Mena Quintero 2d28a36072 Add helper function to get the GcalRecurrenceFrequency from the widgets 
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
 2025-08-27 20:00:17 -03:00
Federico Mena Quintero 63cf4374e4 Remove gcal_event_set/get_original_timezones() 
They are unused now.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
 2025-08-27 20:00:01 -03:00
Federico Mena Quintero d1ccbdf4fb Handle the case where the event editor is present but it has no GcalEvent yet 
Apparently the calendar's views hold a live event editor without an
event, and only set an event when one is selected for editing.

I think it would simplify things to only create the event editor when
it is actually needed, with an event - it would avoid these checks.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
 2025-08-27 20:00:00 -03:00
Federico Mena Quintero 324e3ef71c Move recurrence fields into GcalScheduleSectionValues, split it into "orig" and "curr" values 
This commit does a bit too much, but with these themes:

- Move the recurrence fields into GcalScheduleValues.  This was needed
  for consistency, anyway, and...

- ... the next step was to make ::changed() work, which actually
  required knowing the original and current values of the recurrence as
  well as the dates.

- But then, having a field "orig_foo" for each field "foo" starts
  getting unwieldy.  So, I moved things around:

  - GcalScheduleValues has start/end dates and all_day, and the recurrence.

  - GcalScheduleSectionValues is new; it has the "orig" and "curr"
    values of the previous type.  This simplifies memory management
    since each field can be freed with gcal_schedule_values_free()
    instead of duplicating _free() for each sub-field.

  - GcalScheduleSectionValues also has time_format, as a way to
    decouple that value from GcalContext.  It's not in orig/curr
    because it does not pertain the event; it's just a display-related
    thing.

- Actually fix gcal_schedule_section_changed(),
  gcal_schedule_section_recurrence_changed(), and
  gcal_schedule_section_day_changed().  These become simple since they
  just look at the orig/curr fields, without having to touch widgetry.

- All test pass.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
 2025-08-27 20:00:00 -03:00
Federico Mena Quintero dfc3833253 gcal_schedule_values_free(): Oops, also free the orig_ fields 
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
 2025-08-27 20:00:00 -03:00
Federico Mena Quintero 02a596e967 GcalScheduleValues: store the original value of the all_day flag 
We'll need this for ::changed()

Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
 2025-08-27 20:00:00 -03:00
Federico Mena Quintero 9d8c6486eb gcal_schedule_section_day_changed() - Use the original dates 
The original code from commit 10234653 is

  GCAL_RETURN (gcal_date_time_compare_date (start_date, gcal_event_get_date_start (self->event)) < 0 ||
               gcal_date_time_compare_date (end_date, gcal_event_get_date_end (self->event)) > 0);

but it doesn't explain why it just checks for the modified event
getting "wider" (earlier start, later end) than the original event.

I don't understand that logic, i.e. why doesn't it just check that the
dates changed.

Still, now that we keep the original date-time in the
GcalScheduleValues, use them to preserve the original semantics.

I'm not sure exactly what to test about this... a test to preserve those
semantics?  A test that the function, per its name, returns true if
the days are strictly different?

Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
 2025-08-27 20:00:00 -03:00
Federico Mena Quintero 5172b9438a Add a real test for #43 
I had broken the engine; now it should be fixed.  What is broken now is
::changed(), but I only see it in the GUI.  I'll try to add a test for
that next.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
 2025-08-27 20:00:00 -03:00
Federico Mena Quintero 0dfd19ebd1 Remove obsolete comment 
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
 2025-08-27 20:00:00 -03:00
Federico Mena Quintero 20d593295f For all-day, keep real dates in GcalScheduleValues, and human-readable dates in WidgetState 
This reorders the trick to "subtract one day from date_end" and "add
it back when applying the data to the event".  It also has a test for roundtripping.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
 2025-08-27 20:00:00 -03:00
Federico Mena Quintero f2d039487e Fix leak 
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
 2025-08-27 20:00:00 -03:00
Federico Mena Quintero 6c0da161a6 gcal_schedule_section_apply_to_event(): Get the data from GcalScheduleValues, not the widgets 
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
 2025-08-27 20:00:00 -03:00
Federico Mena Quintero 6f19c32a80 Move the logic from on_end_date_time_changed_cb() to gcal_schedule_values_set_end_date_time() 
And add a test.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
 2025-08-27 19:59:59 -03:00
Federico Mena Quintero 1ace5806d3 Move the logic from on_start_date_time_changed_cb() to gcal_schedule_values_set_start_date_time() 
If the new start_date is later than the end_date, we make the end_date
the same as the new start_date, but with the original end_date's
timezone.

And add a test.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
 2025-08-27 19:59:59 -03:00
Federico Mena Quintero cf43f6e475 Add a correctness check to the helper function 
I was writing a new test, and messed up the times vs. timezones of my
start/end times.  So, let's check them so it is easier to write new tests.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
 2025-08-27 19:59:59 -03:00
Federico Mena Quintero 6029b5f061 Extract function to create a GcalScheduleValues with certain date-time for tests 
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
 2025-08-27 19:59:59 -03:00
Federico Mena Quintero a7282564fd Move the logic for setting the date_end from on_end_date_changed_cb() to gcal_schedule_values_set_end_date() 
Analogous to the last commit; also add a test.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
 2025-08-27 19:59:59 -03:00
Federico Mena Quintero af4ddc1282 Move the logic from on_start_date_changed_cb() to gcal_schedule_values_set_start_date() 
This also adds a test for syncing the date_end to the date_start if
the date_start happens to be set after the date_end.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
 2025-08-27 19:59:59 -03:00
Federico Mena Quintero ba3380206d GcalScheduleValues: keep copies of the original dates of the event 
That is, we'll keep the original values, plus the working values that
get changed from the widgets.  We'll use the original values to be
able to reconstruct the original event's duration if needed.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
 2025-08-27 19:59:59 -03:00
Federico Mena Quintero 481569543d on_schedule_type_changed_cb(): Don't frob the widgets here 
Converting the start/end dates to local time is done to get them to
display as the user expects.  Instead, let's change things so that
they are actually computed and handled correctly.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
 2025-08-27 19:59:59 -03:00
Federico Mena Quintero 9975a96927 Add a test, with the failing part commented out 
I want to test that when:

- a one-hour event is loaded
- all-day is turned on

then the start and end date widgets display both the same date.

This fails right now, because we subtract one from the end_date.  I'll
change the way the dates are handled so that this magic only needs to
be done when setting back the GcalEvent.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
 2025-08-27 19:59:59 -03:00
Federico Mena Quintero 18beea3052 Extract function to update the widgets *and* the values 
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
 2025-08-27 19:59:59 -03:00
Federico Mena Quintero e0641709bf Move handling of the start/end dates to GcalScheduleValues / WidgetState 
This clarifies things:

* GcalScheduleValues contains the real data, based initially on the
  GcalEvent.

* WidgetState's date_time_start / date_time_end may not be the same as
  the real data, since the values get adjusted for display, as in the
  case when handling all_day events.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
 2025-08-27 19:59:58 -03:00
Federico Mena Quintero 8120162f23 Fix leak of two GDateTime 
While gcal_date_time_chooser_get_date_time() returns a new reference,
gcal_date_chooser_row_get_date() just returns the pointer to the date
being edited.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
 2025-08-27 19:59:58 -03:00
Federico Mena Quintero f787afbeab Clarify oudated comments 
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
 2025-08-27 19:59:58 -03:00
Federico Mena Quintero 1cfb58e3c4 Fix leak of date_time_end 
It's replaced by this line:

  date_time_end = all_day ? g_date_time_add_days (date_time_end, -1) : date_time_end;

so we need to be able to free that.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
 2025-08-27 19:59:58 -03:00
Federico Mena Quintero ba69d04465 Remove unused variable 
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
 2025-08-27 19:59:58 -03:00
Federico Mena Quintero 2ca29785dc Remove superfluous conditional 
Now that all cases set the same times to the
{start,end}_date_time_chooser widgets, we don't need that condition anymore.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
 2025-08-27 19:59:58 -03:00
Federico Mena Quintero 1309bf4a82 gcal_schedule_section_set_event(): Don't change the timezones when setting up the widgets 
I think this was being done so that:

  - create a new all-day event
  - open it in the event editor
  - switch to time-slot
  - time choosers now say "UTC"

doesn't happen.  I think this can be handled more gracefully.

Evolution does not handle it very gracefully; when turning off
all-day in its event editor, it sets the times to $now.

The iOS calendar app is better.  If you turn all-day off, it picks
$next_hour_based_on_now for the start time, and $next_hour_plus_one
for the end time.  So if you turn off all-day and it is 18:24 right
now, it will set the start_time to 19:00 and the end_time to 20:00 ---
that is, it creates a one-hour event at the next start of the hour
from now.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
 2025-08-27 19:59:58 -03:00
Federico Mena Quintero 923424acab Run the tests for the flatpak build 
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
 2025-08-27 19:59:58 -03:00
Federico Mena Quintero a0a817ee8a Add scaffolding for a new test-internals binary 
* There is a gcal_tests_add_internal() function...

* called from tests/test-internals.c...

* ... which doesn't add any tests yet, but we'll have some soon.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
 2025-08-27 19:59:57 -03:00
Federico Mena Quintero cdc602bb1f Start sketching gcal_schedule_values_set_start_date() 
But we need a test first!

Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
 2025-08-27 19:59:17 -03:00
Federico Mena Quintero 938419c1d4 Handle the time_format as part of GcalScheduleValues and WidgetState 
This will let us write tests for changing the time format without a
context object.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
 2025-08-27 19:59:17 -03:00
Federico Mena Quintero 11dcab5ddf Set the state of the schedule_type_toggle_group in update_widgets() 
And now the redundancy in gcal_schedule_section_set_event() is gone.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
 2025-08-27 19:59:17 -03:00
Federico Mena Quintero 253b1d4f17 Start transitioning gcal_schedule_section_set_event() to use update_widgets() 
For now this is redundant, as update_widgets() only sets the
visibility of the time selectors, while the call to
adw_toggle_group_set_active_name() effectively does the same.

But that redundancy will go away in the next step.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
 2025-08-27 19:59:17 -03:00
Federico Mena Quintero 640488883b Introduce a WidgetState structure and compute it from GcalScheduleValues 
You may think, yet more indirection!  But behold:

1. We take events from the widgets ("schedule type (all-day) changed") and turn
   them into actions (gcal_schedule_values_set_all_day()).

2. Those actions (e.g. that function) decide how to change the GcalScheduleValues.

3. We compute the desired state of the wigets, based on the new
   values.

4. We set the state of the widgets based on that.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
 2025-08-27 19:59:17 -03:00
Federico Mena Quintero 2c476f6d02 New function to set the all_day flag on GcalScheduleValues 
You may think that this is too much indirection.  But wait!  This is
the start of enabling tests.  Hang in there.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
 2025-08-27 19:59:17 -03:00
Federico Mena Quintero a4d891aadd New function to copy a GcalScheduleValues 
These structs are immutable.  Any changes will be made on a copy.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
 2025-08-27 19:59:17 -03:00
Federico Mena Quintero 939b60d6b4 gcal_schedule_section_apply(): extract an _apply_to_event() helper function 
With this, there's no direct mutation of the self->event anywhere; the
_apply() function just uses self->event as a target for mutation
because that's what the surrounding architecture expects.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
 2025-08-27 19:59:16 -03:00
Federico Mena Quintero 70173639e4 gcal-schedule-section.c: Use the stored values instead of pulling them from the event every time 
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
 2025-08-27 19:59:16 -03:00
Federico Mena Quintero f51186c298 gcal_schedule_section_apply(): use the stored values as a reference 
Also, update the values from the updated event at the end.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
 2025-08-27 19:59:16 -03:00
Federico Mena Quintero 68126bcfac gcal_schedule_section_set_event(): set the widgets from the extracted values, not from the event 
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
 2025-08-27 19:59:16 -03:00
Federico Mena Quintero d44e6847c7 GcalScheduleSection: store the values when an event is set 
We don't use them yet; just hooking things up for now.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
 2025-08-27 19:59:16 -03:00
Federico Mena Quintero f75785a34c GcalScheduleValues: new struct to hold values from a GcalEvent for the schedule widges 
We'll move GcalScheduleSection to operate without a backing GcalEvent,
so we can add tests.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
 2025-08-27 19:59:16 -03:00
Federico Mena Quintero 42b00ec052 Fix cut&paste error 
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
 2025-08-27 19:59:16 -03:00
Federico Mena Quintero 72762ee11d GcalEventWidget: remove the date-end property; it is unused 
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
 2025-08-27 19:59:16 -03:00
Federico Mena Quintero 7a814cc1f3 Move explanatory comment 
Analogous to date-start

Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
 2025-08-27 19:59:16 -03:00
Federico Mena Quintero 6e10e746c3 GCalEventWidget: remove the date-start property; it is never used 
Setting and getting the value always happens through
gcal_event_widget_set_date_start() and gcal_event_widget_get_date_start().

Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
 2025-08-27 19:59:16 -03:00
Federico Mena Quintero 2f86a7a77b Move explanatory comment 
We'll remove the date-start property, so put its description in the
corresponding setter function.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
 2025-08-27 19:59:15 -03:00
Federico Mena Quintero 84cf41cc4f core/timeline: Fix leak of QueueData in queue_event_data() 
The new QueueData was created even for REMOVE_EVENT, which causes an
early exit.  Only create the QueueData when needed.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/582>
 2025-05-30 14:10:05 +00:00
Federico Mena Quintero 2eec02b76a gui/views/month-view: Initialize two variables 
The static analizer can't figure out that they will always be initialized
by the for loop in this function.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/581>
 2025-05-28 18:08:54 +00:00
Federico Mena Quintero ef8c6ff55d utils/source-discoverer: Use temporary variable only when tracing is enabled 
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/581>
 2025-05-28 18:08:54 +00:00
Federico Mena Quintero a3ddd8e510 gui/views/month-view: Mark variable as unused 
It's just a temporary reference that will get removed at function exit.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/581>
 2025-05-28 18:08:54 +00:00
Federico Mena Quintero 3c38a272b8 gui/importer/import-dialog: Remove superfluous assignment 
The variable is initialized where it is declared.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/581>
 2025-05-28 18:08:54 +00:00
Federico Mena Quintero 8c2daf672b gui/importer/import-dialog: Remove an unused variable 
Looks like a cut&paste error.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/581>
 2025-05-28 18:08:54 +00:00
Federico Mena Quintero b03eabb7b7 gui/event-widget: Mark a variable as unused 
The actual parsed guri is unused here; the code just does the parsing
as a way to tell whether the event's location refers to a URI/service
or not (e.g. a physical location or address).

Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/581>
 2025-05-28 18:08:54 +00:00
Federico Mena Quintero 172f07c44e gui/views/week-grid: Remove superfluous assignment 
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/581>
 2025-05-28 18:08:54 +00:00
Federico Mena Quintero e56ce53ea5 gui/views/week-header: Remove superfluous assignment 
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/581>
 2025-05-28 18:08:54 +00:00
Federico Mena Quintero 81c8900076 gui/views/week-header: Remove unused variable 
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/581>
 2025-05-28 18:08:54 +00:00
Federico Mena Quintero bc53f169eb gui/views/week-header: Remove unused variable 
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/581>
 2025-05-28 18:08:54 +00:00
Federico Mena Quintero d1499329cc core/calendar-monitor: Replace a manual GRWLockWriterLocker with G_RW_LOCK_WRITER_AUTO_LOCK() 
This takes care of static-scan's warning about a variable being set
but never read.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/581>
 2025-05-28 18:08:54 +00:00
Federico Mena Quintero cf48f79f36 core/calendar-monitor: Replace a manual GRWLockWriterLocker with G_RW_LOCK_WRITER_AUTO_LOCK() 
This takes care of static-scan's warning about a variable being set
but never read.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/581>
 2025-05-28 18:08:54 +00:00
Federico Mena Quintero 26c3f83e3c core/calendar-monitor: Replace a manual GRWLockWriterLocker with G_RW_LOCK_WRITER_AUTO_LOCK() 
This takes care of static-scan's warning about a variable being set
but never read.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/581>
 2025-05-28 18:08:54 +00:00
Federico Mena Quintero e2dc3460a6 core/calendar-monitor: Replace a manual GRWLockWriterLocker with G_RW_LOCK_WRITER_AUTO_LOCK() 
This takes care of static-scan's warning about a variable being set
but never read.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/581>
 2025-05-28 18:08:54 +00:00
Federico Mena Quintero 1d5fd3eec9 core/calendar-monitor: Replace a manual GRWLockWriterLocker with G_RW_LOCK_WRITER_AUTO_LOCK() 
This takes care of static-scan's warning about a variable being set
but never read.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/581>
 2025-05-28 18:08:54 +00:00
Federico Mena Quintero 21b7607c39 core/calendar-monitor: Replace a manual GRWLockReaderLocker with G_RW_LOCK_READER_AUTO_LOCK() 
This takes care of static-scan's warning about a variable being set
but never read.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/581>
 2025-05-28 18:08:54 +00:00
Federico Mena Quintero f55f42b81c core/calendar-monitor: Replace a manual GRWLockReaderLocker with G_RW_LOCK_READER_AUTO_LOCK() 
This takes care of static-scan's warning about a variable being set
but never read.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/581>
 2025-05-28 18:08:54 +00:00
Federico Mena Quintero 32ebd80613 core/calendar: Replace a manual GMutexLocker with G_MUTEX_AUTO_LOCK() 
This takes care of static-scan's warning about a variable being set
but never read.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/581>
 2025-05-28 18:08:54 +00:00
Federico Mena Quintero eeb9c99172 core/calendar: Replace a manual GMutexLocker with G_MUTEX_AUTO_LOCK() 
This takes care of static-scan's warning about a variable being set
but never read.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/581>
 2025-05-28 18:08:54 +00:00
Federico Mena Quintero 0d3975b556 core/calendar: Replace a manual GMutexLocker with G_MUTEX_AUTO_LOCK() 
This takes care of static-scan's warning about a variable being set
but never read.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/581>
 2025-05-28 18:08:54 +00:00
Federico Mena Quintero e884a09268 core/calendar: Replace a manual GMutexLocker with G_MUTEX_AUTO_LOCK() 
This takes care of static-scan's warning about a variable being set
but never read.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/581>
 2025-05-28 18:08:54 +00:00
Federico Mena Quintero 872aae9183 core/calendar: Replace a manual GMutexLocker with G_MUTEX_AUTO_LOCK() 
This takes care of static-scan's warning about a variable being set
but never read.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/581>
 2025-05-28 18:08:54 +00:00
Federico Mena Quintero 384411b33a Increase the required version of glib to 2.80.0 
We'll need this for G_MUTEX_AUTO_LOCK().  It basically does

  g_autoptr (GMutexLocker) G_GNUC_UNUSED var = g_mutex_locker_new (mutex)

which will let us remove static-scan's warnings about assigned
variables that are never read, e.g. it complains about "locker" here:

    g_autoptr (GMutexLocker) locker = g_mutex_locker_new (&priv->shared.mutex);

The whole point of GMutexLocker is to be used with g_autoptr for a
mutex that is unlocked when its scope ends.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/581>
 2025-05-28 18:08:54 +00:00
Federico Mena Quintero 7d869ed4e8 CI: copy the scanbuild directory from the correct place 
Ninja's scan-build command creates a directory with an ugly unique
name.  So, we copy it to a well-known "scanbuild" directory instead.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/580>
 2025-05-27 13:42:19 +00:00
Federico Mena Quintero a00c72b139 Add an index.html landing page for GitLab pages 
For https://gnome.pages.gitlab.gnome.org/gnome-calendar/
 2025-05-26 18:39:08 -06:00
Federico Mena Quintero 1a232ba811 CI: Add a static-scan job 
This will run static analysis and publish the report on

  https://gnome.pages.gitlab.gnome.org/gnome-calendar/scanbuild
 2025-05-26 18:39:08 -06:00
Federico Mena Quintero 9c7315a66a CI: Add a test coverage job 
This uses grcov internally to generate the HTML report.  We use grcov
instead of, say, lcov, because grcov actually generates accessible
pages.

We use the gnome-build-meta:core-nightly container image.  It doesn't
contain grcov by default, but we download the binary from its github
page.  We can change this later to build a custom container image for
gnome-calendar's own CI.

This will publish the report on

  https://gnome.pages.gitlab.gnome.org/gnome-calendar/coverage/
 2025-05-26 18:13:55 -06:00