Federated_Computer/federated-calendar
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
5,709 Commits 3 Branches 0 Tags
855fea34bf3dca653dcb945c8d2ee479fb1b47cb
Commit Graph
942 Commits
Author SHA1 Message Date
Philipp Sauberzweig 6e97c05a14 views: Merge month name and date number into a single label. 
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/647>
 2025-10-28 14:06:44 +00:00
Trystan Mata d8e22b5646 event-editor: Fix template update when updating all events 
Change how the template end date is determined by mainly relying on the
new template start date:
- If all day, end date is start date plus 1 day (midnight enforced)
- If time-based, end date is start date plus the time span of the event
  properties

Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/635>
 2025-10-21 14:17:33 +00:00
Trystan Mata e11a3be44c schedule-section: Skip updating recurrence limit if no repeat 
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/634>
 2025-10-21 14:12:21 +00:00
Trystan Mata 20274b0b94 editor-dialog: Fix time-slot timezones 
Uses the local timezone if the event was originally all-day.

Also set the end time to 1:00 if start and end date are the same.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/641>
 2025-10-21 14:08:04 +00:00
Philipp Sauberzweig a32df2b070 views/month-cell: Remove dimming of out-of-month cells 
The infinite scrolling month view obsoletes the out-of-month
dimming, as the view is no longer fixed in a specific month, nor
does it make out-of-month cells insensitive.

Closes: https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1145
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/646>
 2025-10-17 18:06:17 -04:00
Lukáš Tyrychtr 3a544b22fc week-view: Add tooltip to the all day events expander 
This adds a tooltip to the all day events expander button,
indicating whether the expander will expand or collapse
upon activation.

Fixes https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1449

Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/637>
 2025-10-17 13:59:26 -04:00
Hari Rana 3a93a4004d views/month-popover: Use adw_lerp() function 
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/650>
 2025-10-17 17:08:42 +00:00
Jean-François Fortin Tam 3e31bd1641 Revert "event-editor/notes: Add height-request" 
The widget already auto-adjusts its height depending on text contents.
Let it use as much or as little height it needs.
This avoids extra scrolling in some cases.

This reverts commit a09c02591e.

Fixes: https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1455
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/636>
 2025-10-17 17:04:00 +00:00
Philipp Sauberzweig fc90d259b2 gui/views: Fix event margins in week header 
Margins are already applied to the event widget itself through CSS.
This commit removes unnecessary margins and row spacing to bring
it in line with the month view.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/649>
 2025-10-17 12:27:03 -04:00
Jean-François Fortin Tam 28e8e07219 gcal-event-editor: Add mnemonic for "Delete Event" 
This lets keyboard-centric power users delete events in 1 second.
It can be useful in rare situations when you need to delete many events.

Fixes: https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1313
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/628>
 2025-10-10 13:27:46 +00:00
Philipp Sauberzweig 2368a9f29d gui: stop dimming the sidebar headings 2025-10-07 18:36:03 +00:00
Trystan Mata 38e355c3b1 calendar-navigation-button: Fix active-date reference 
Increase active-date reference count so the button and the window have
their own reference.

This fix the reference issue while the window is finalizing.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/638>
 2025-09-04 15:29:01 +00:00
Trystan Mata 66542a6673 edit-calendar-page: Check calendar before setting name while disposing 
The calendar is not initialized when opening and closing the
calendar management dialog.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/638>
 2025-09-04 15:29:01 +00:00
Trystan Mata 0b25305aa4 view/month-view: Fix seeking ancestor of NULL 
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/638>
 2025-09-04 15:29:01 +00:00
Trystan Mata 15a78b4063 gui/event-editor: Fix GcalDateChooserRow date selected changed callback 
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/632>
 2025-08-30 16:38:44 +02:00
Jean-François Fortin Tam d86d0f7e1e event-editor: Focus the whole title entry on start 
This avoids the text cursor being positioned at the start of the entry.

Fixes: https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1452
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/631>
 2025-08-30 00:24:15 -04:00
Hari Rana 9213a4fbe4 gui/window: Only set focus when popover is explicitly closed 
The window would either set focus to the event widget or a
focusable ancestor, no matter how the event popover was being
closed.

This caused a major accessibility regression where,
whenever the event editor dialog opened from the event
popover, the window set focus to the event widget instead of
the content inside the dialog, which made the dialog incapable
of navigating through until the dialog was focused. This also
prevented mnemonics from being triggered.

This patch addresses that bug by only setting focus whenever
the popover is being closed explicitly; as in, when the user
presses outside the popover to hide it or pressing escape.

Fixes https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1398
 2025-08-29 21:45:59 -06:00
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 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