gnome-calendar issueshttps://gitlab.gnome.org/GNOME/gnome-calendar/-/issues2024-03-13T15:39:22Zhttps://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1198Moving time ranged events via drag and drop in Week View's timetable is off b...2024-03-13T15:39:22ZJeff FortinMoving time ranged events via drag and drop in Week View's timetable is off by one hour during the week of DST daylight savings time switchThis is similar to #482 / #996, except that it still affects version 46 / nightly after @danigm's fixes for those in !370.
The subtlety here is that the problem does not occur upon new time-ranged drag event _creation_ (this was fixed i...This is similar to #482 / #996, except that it still affects version 46 / nightly after @danigm's fixes for those in !370.
The subtlety here is that the problem does not occur upon new time-ranged drag event _creation_ (this was fixed in #482, and remains fixed to this day), but it occurs when _moving_ existing events via drag and drop in the timetable. Demonstration video below.
This _only_ happens during the week where the DST switch occurs. For instance, in that video, the week starts on Sunday (because of #160), and that Sunday March 10th in North America is when the clocks moved forward 1 hour.
Maybe the fix would be similar to what was done for #482? See !370 for inspiration.
Demonstration with version 46 / nightly while trying to move time-based events:
![GNOME_Calendar_46_weekview_timetable_drag-and-drop_event_moving_during_week_of_the_DST_switch](/uploads/cd3ebe90a465619a2c427ce3e91eff87/GNOME_Calendar_46_weekview_timetable_drag-and-drop_event_moving_during_week_of_the_DST_switch.webm){width=100%}https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/482Wrong new event time in "week view" after daylight savings transition2024-03-13T15:39:21ZAdam DingleWrong new event time in "week view" after daylight savings transitionI'm running gnome-calendar from git master on Ubuntu 19.10.
If I click the week view to create a new event in the week following a daylight savings transition, then the new event's time is one hour off from the time I clicked. (This be...I'm running gnome-calendar from git master on Ubuntu 19.10.
If I click the week view to create a new event in the week following a daylight savings transition, then the new event's time is one hour off from the time I clicked. (This behavior is specific to the week view.)
For example, today is Mon Oct 28. Yesterday (Sun Oct 27) daylight savings time ended here in Central Europe. If I click the calendar to create a new event at 4 pm today, the new event dialog shows 3 pm. The same thing happens if I create a new event on any other day this week. But if I click to create an event during the previous or following week, then the proposed time is correct.GNOME 46Daniel Garcia MorenoDaniel Garcia Morenohttps://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/160Allow first day of week to be changed (via GNOME Settings)2024-03-13T15:18:01ZGeorges Basile Stavracas NetoAllow first day of week to be changed (via GNOME Settings)Some religious as well as regional calendars (e.g.: the Japanese calendar) start the week with Sunday as opposed to Monday, so it would be nice if in the gnome-tweak-tool one could set it to Sunday, however this (bug #770139) is not poss...Some religious as well as regional calendars (e.g.: the Japanese calendar) start the week with Sunday as opposed to Monday, so it would be nice if in the gnome-tweak-tool one could set it to Sunday, however this (bug #770139) is not possible until backend support is provided by either gnome-calendar or gnome-shell so that is why I am filling a report on this matter here.
**[Link to original bug (#783792)](https://bugzilla.gnome.org/show_bug.cgi?id=783792)**https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/996Event creation popover is off by one hour in week view's timetable in the nor...2024-03-13T15:18:00ZJeff FortinEvent creation popover is off by one hour in week view's timetable in the northern summer (DST related?)Just noticed this today, it affects git `main`, 44.0/RC, 43.1 (so it's not a regression of recent code):
![image](/uploads/4995db698addd3b757059cdb5eff7513/image.png)
As you can see you click in the 12:00 timeslot and the popover says ...Just noticed this today, it affects git `main`, 44.0/RC, 43.1 (so it's not a regression of recent code):
![image](/uploads/4995db698addd3b757059cdb5eff7513/image.png)
As you can see you click in the 12:00 timeslot and the popover says 13:00.
This might have something to do with the fact that my country has recently switched to summer time, +1 hour...https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1043Events in Week View not updated / not removed when moved to another week via ...2024-03-13T01:24:25ZJeff FortinEvents in Week View not updated / not removed when moved to another week via Month ViewA bit similar to @pksadiq's issue #103 but I found a way to make it occur in 44.x / nightly. Still affects 45.0.
# Reproduction steps
Video demonstrations from "simple" cases:
| Testing all-day events only | Testing time-based and all...A bit similar to @pksadiq's issue #103 but I found a way to make it occur in 44.x / nightly. Still affects 45.0.
# Reproduction steps
Video demonstrations from "simple" cases:
| Testing all-day events only | Testing time-based and all-day events (and comparing with Evolution) |
| - | - |
| ![gnome-calendar-gitlab-1043](/uploads/d7ae2be5a6f1ed777378706540243e52/gnome-calendar-gitlab-1043.mp4){width=100%} | ![gnome-calendar-gitlab-1043_-_time-based_events](/uploads/87084be0f1c141906a68543328867e33/gnome-calendar-gitlab-1043_-_time-based_events.webm){width=100%} |
With any calendar, offline or online (ex: Google calendar configured as an EDS Google-type calendar):
1. Go into GNOME Calendar's week view in a week where you have all-day (or multi-day multi-week) event (ex: all-day event spanning from Friday this week to Wednesday next week);
if you can't see it, click the `V` expander arrow button if needed (if there are many all-day events in the current week view)
3. Either:
* Simpler reproduction methods:
* _Locally, switch from week view to the month view_, move the event to another day on another week, go back to week view. And vice versa (move the same event from another week into the current week, using the month view, and it will suddenly update itself in the weekview).
* Or, alternatively: click the event in the week view's header, click "Edit…", and in the editing dialog, change the start date to some date next week. No drag-and-drop / no month-view required.
* Complex reproduction method: ~~_from the server side_ (ex: Google Calendar's web interface), reschedule the event to next week with different dates (ex: from Monday to Wednesday)... then, in GNOME Calendar, still in week view, use the "Calendars > Synchronize Calendars" menu action.~~
# Results
The event never disappears from the week view's all-day events header area…
* …even if you switch to month view and back to week view (the month view displays the updated event correctly, though)
* …even if, in Week view, you switch to the next week and back to the current week; in fact, it may or may not update, and may even lead to nonsensical or graphically corrupt events after a while (i.e. 5-10 minutes), like the crimson "Beau****" and purple "GUADEC" events you see in these screenshots (note: in my case, the event I moved was the "Beau****" one):
## Screenshots from a complex case
Corrupt view of the next week, showing a duplicated set of the crimson "Beau****" events:
![Screenshot_from_2023-07-13_11-11-09_-_next_week_-_blurred](/uploads/46effc517a97fec8ff6eb4b251ff9439/Screenshot_from_2023-07-13_11-11-09_-_next_week_-_blurred.png)
Corrupt view of "in 2 weeks", showing broken alignment and stacking of events in general:
![screenshot_from_2023-07-13_11-11-30_-_in_two_weeks](/uploads/4146397501077942a9a032267b3347e4/screenshot_from_2023-07-13_11-11-30_-_in_two_weeks.png)https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/103(Week view) not immediately refreshed after the event schedule changes by a week2024-03-13T01:24:25ZGeorges Basile Stavracas Neto(Week view) not immediately refreshed after the event schedule changes by a weekWeek-view event is not immediately refreshed after the event date changes by a week.
How to reproduce:
0. Switch to week view and click 'Today' button. Then switch to month view
1. Create some timed (or full day) event on some day using...Week-view event is not immediately refreshed after the event date changes by a week.
How to reproduce:
0. Switch to week view and click 'Today' button. Then switch to month view
1. Create some timed (or full day) event on some day using month view
Eg: on January 19
2. Now dnd the event to January 12th
3. Switch to week view
Result:
The event is still shown on January 19th. Also, when the view is switch back a week (using the back arrow button) the event is shown twice on January 12th (this happens only once though)
**[Link to original bug (#777419)](https://bugzilla.gnome.org/show_bug.cgi?id=777419)**
## Design Tasks
TODO
## Development Tasks
TODO
## QA Tasks
TODOGNOME 43https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1110Particular .ics imported recurring calendar event's time is offset by multipl...2024-03-11T12:13:26ZJuan CamposParticular .ics imported recurring calendar event's time is offset by multiple hours (interpreted as UTC?)Using a calendar from URL (.ics) some recurrent events are wrong placed and others missing . Evolution shows them correctly.
| GNOME Calendar | Evolution |
| ------ | ------ |
| ![imatge](/uploads/b4bd4c9fd6140f8d6f55082c675ef533/ima...Using a calendar from URL (.ics) some recurrent events are wrong placed and others missing . Evolution shows them correctly.
| GNOME Calendar | Evolution |
| ------ | ------ |
| ![imatge](/uploads/b4bd4c9fd6140f8d6f55082c675ef533/imatge.png) | ![imatge](/uploads/a7224cf17cb902ea1c7277b6dd0e7a06/imatge.png) |
Here the response from the URL
[reachcalendar_3_.ics](/uploads/11e591e12eaa52858d643fded4da50a9/reachcalendar_3_.ics)
Calendar version 45.0https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/95Capitalize month names2024-03-10T18:57:09ZGeorges Basile Stavracas NetoCapitalize month namesOriginally reported by @jfft in [Bugzilla #775548](https://bugzilla.gnome.org/show_bug.cgi?id=775548):
> Essentially the silliest request I have, so low priority, but… month names are all lowercase everywhere, which just looks a bit wei...Originally reported by @jfft in [Bugzilla #775548](https://bugzilla.gnome.org/show_bug.cgi?id=775548):
> Essentially the silliest request I have, so low priority, but… month names are all lowercase everywhere, which just looks a bit weird considering that weekdays are ALLCAPS and the rest of UI elements have Sentence capitalization.
>
> Apparently one would need to wrangle the output given by glib to do that conversion.https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/604When rapidly adding multiple events to week view, timezone information is som...2024-03-08T02:40:59ZVanadiaeWhen rapidly adding multiple events to week view, timezone information is sometimes not correctly savedI'm running the latest development version of GNOME calendar, at master commit `2f6aae7f213a7a5083e5ffa01c6bb1bebb6761cb`.
I'm in a UTC+02 timezone, which means that if it's 08:00 in the UTC (=UTC+00) timezone, it will be 10:00 in my ti...I'm running the latest development version of GNOME calendar, at master commit `2f6aae7f213a7a5083e5ffa01c6bb1bebb6761cb`.
I'm in a UTC+02 timezone, which means that if it's 08:00 in the UTC (=UTC+00) timezone, it will be 10:00 in my timezone.
Steps to reproduce:
1. Open GNOME Calendar
1. go to week view
2. Create a new calendar (so that if something screws up you don't loose anything) and enable it
3. Create a bunch (like 10-20) of events in the new calendar using the simple popover (don't use the details popover, this should help focusing on one place of testing)
Here is a short screencast reproducing this issue (better to watch fullscreen)
![Capture_d_écran_vidéo_de_13-05-2020_16_34_12](/uploads/9100f4435587f47b5709d5d65d4dceb0/Capture_d_écran_vidéo_de_13-05-2020_16_34_12.webm)
As you can see at the end of the screencast, I add an event starting at 17:00 and then it appears at 19:00. (which means two hours were added, like my UTC+02 timezone).
Some strange things :
- this happens after a random number of events. There's no logic to it, I tried multiple times, restarting the app once I notice the bug : first the 12nd, then the 13rd, then the 15th, and after being tired of doing this, the 11st one.
- The time is broken since the first time it break, until you close the app. After reopening it, new events don't break... until they do.
Here is an iCalendar with the bug that can help with this issue.
[calendar_reproducing_material.ics](/uploads/eaecccdb0f037234f01b575337e13b6b/calendar_reproducing_material.ics)
# calendar analyzing
(I used the iCalendar specs at https://tools.ietf.org/html/rfc2445 to know all this)
open the calendar in a text editor. There is only two parts that are relevant (not the version information, etc that are directly in the VCALENDAR scope).
Here is the first part, the event that shows well, without unrelevant properties.
```
BEGIN:VEVENT
DTSTART;TZID=/freeassociation.sourceforge.net/Europe/Paris:
20200514T120000
DTEND;TZID=/freeassociation.sourceforge.net/Europe/Paris:20200514T123000
SUMMARY:good one
END:VEVENT
```
the DTSTART and DTEND are very similar, so will just look at DTSTART.
DTSTART is a property of type [Date-Time](https://tools.ietf.org/html/rfc2445#section-4.3.5) and corresponds to the third form of it. This one stores the timezone information in the TZID property and after the colon the date and time of the form "YYYYMMDD" "T" "HHMMSS" (without the spaces and quotation marks). The time (HHMMSS) is with timezone TZID, so UTC+02 here. This one is correctly shown.
```
BEGIN:VEVENT
DTSTART:20200515T153000Z
DTEND:20200515T160000Z
SUMMARY:bad one
END:VEVENT
```
This event was set at 15:30 but has a "Z" prefix that means UTC time (see form #2). The thing is that it's 15:30 UTC+02, not UTC+00. So for an unknown reason, the popover sometimes doesn't put the UTC+02 timezone, but sets the timezone as UTC.
All these let me think that the problem is in the "add event" popover (files `src/gui/gcal-quick-add-popover.*`) because it's strange that it uses two different formats for the same timezone. The problem is not in the calendar view nor shell notification (which shows the same time as g-c) because when they see that it's at 15:30 UTC+00, they do their job and convert to my timezone, UTC+02, and add 2 hours so that's why it shows 17:30 for the bad event.
## Development Tasks
* [ ] `src/gui/gcal-quick-add-popover.c` is a massive 1000 lines (which I find strange, due to the simplicity of the popover) file so this is a big thing.
## QA Tasks
* [ ] try to reproduce as described at the top of this message
Please care to tell if able to reproduce this.GNOME 46https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1030Week and month views do not render time-based events without an end time2024-03-08T02:16:52ZPhilipp HoferWeek and month views do not render time-based events without an end time### Affected version
Arch 2023-06-05
gnome-calendar: Version 44.1
### Bug summary
Certain events are not shown in the week and month view.
### Steps to reproduce
1. Create the file `test.ics` with the following content:
```
BEGIN:V...### Affected version
Arch 2023-06-05
gnome-calendar: Version 44.1
### Bug summary
Certain events are not shown in the week and month view.
### Steps to reproduce
1. Create the file `test.ics` with the following content:
```
BEGIN:VCALENDAR
VERSION:2.0
PRODID:ics-rs
BEGIN:VEVENT
UID:uid@something.unique
DTSTAMP:19900101T180000
DTSTART:20230419T180000
SUMMARY:My summary
END:VEVENT
END:VCALENDAR
```
2. Open gnome-calendar
3. Add the `test.ics` file (Calendars > Manage calendars > Add calendar...; select the file and press "Add")
4. If you go to the week of the 19.04.2023 the event is not shown and you receive this error message (in the console): `(gnome-calendar:131516): GcalWeekHeader-WARNING **: 15:08:32.965: Error adding event 'My summary' to the week header`
### What happened
It does not show the event.
### What did you expect to happen
Gnome Calendar should show the event.
<!-- Do not remove the following line. -->https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1100HTML (with hyperlinks) in event details (notes) should get sanitized to plain...2024-03-07T03:15:14ZJeff FortinHTML (with hyperlinks) in event details (notes) should get sanitized to plaintext or simple markup for tooltips in the main viewsAs can be seen here, the main views' tooltips don't get their notes/details contents sanitized before insertion into the tooltip's contents:
![image](/uploads/42e06d4b2ae941a6f3dbe5aa9b634a53/image.png)
Evolution seems to have the same...As can be seen here, the main views' tooltips don't get their notes/details contents sanitized before insertion into the tooltip's contents:
![image](/uploads/42e06d4b2ae941a6f3dbe5aa9b634a53/image.png)
Evolution seems to have the same UX issue, including with Markdown-formatted descriptions:
![image](/uploads/e12455d6d791d2bc5b7b2f6f286143e9/image.png)
You can also see in that screenshot here two types of Markdown URLs, long beautified ones (what do we do with those? Nothing I presume) and plain ones (that could be 2x shorter by just using the `<the_url>` markdown syntax, and in the context of tooltips, just the plain URL with no syntax around it)...
I'm wondering what would be the easiest and most elegant way to get "clean" descriptions, if possible, for Gtk Tooltips (since they support Pango markup, but not much more)...
* Some homemade cleanup trickery?
* Throwing it at a markdown conversion and sanitizing utility function/library?
* Or does Evolution Data Server already have some sort of API to provide plaintext-like sanitized variants of event descriptions for this kind of usecase, @mcrha ?https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1190Show calculated age for automated birthday calendar events2024-03-05T07:41:13ZJeff FortinShow calculated age for automated birthday calendar eventsEDS contacts have a "birthday" date field, and an "anniversary" date field. Maybe eventually a [date of death field](https://gitlab.gnome.org/GNOME/evolution/-/issues/1518).
When a full valid date including year is included in the _birt...EDS contacts have a "birthday" date field, and an "anniversary" date field. Maybe eventually a [date of death field](https://gitlab.gnome.org/GNOME/evolution/-/issues/1518).
When a full valid date including year is included in the _birthday_ date field, it would be nice to show what age the person is on that day. Evolution (shown on the right in the screenshot below) does this, whereas GNOME Calendar (shown on the left) doesn't:
![image](/uploads/ed0c8f629d4bb17cc80aa05da127704f/image.png)
This would make the automated "Birthdays & Anniversaries" EDS calendar quite a bit more useful, because it would not only remind you of someone's birthday, but also save you from asking the awkward "so wait, what age are you again?" or might prompt you to celebrate some specific milestones (ex: in some cultures the 50th birthday is significant, etc.).
The design question is whether we should show the date directly in the event title label like Evolution does, or if this can/should only be in the tooltip when you hover it with the mouse, and in the event details popover widget.
---
Interesting fact: @thibaultamartin's screenshot in https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/49#note_779102 reveals that we used to show a birthday cake emoji (instead of the `Birthday: ` text prefix) and the birth yeay (as a suffix, ex.: ` (1992)`). I wonder what led to this behavior changing between 2020 and 2022. Was the cake emoji's replacement by a text string an EDS change @mcrha? I can't find a ticket about it in Evolution or EDS, nor anything related to calendar event labels when searching for "birthday" in the Evolution or EDS commits.
Of course, it is _much_ more useful to show the calculated age (like Evolution does) rather than the birth year (like GNOME Calendar used to do), as the birth year requires me to make a mental calculation that will inevitably be tedious and likely to be wrong.https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1182Highlight the week range on mouse hover in the sidebar's minicalendar2024-03-04T15:12:54ZDaniel CachapaHighlight the week range on mouse hover in the sidebar's minicalendar### Feature summary
When using the mini calendar on the top-left, the hover effect appears around individual days, even though the large calendar only changes based on the selected week in both month and week views which makes it a bit ...### Feature summary
When using the mini calendar on the top-left, the hover effect appears around individual days, even though the large calendar only changes based on the selected week in both month and week views which makes it a bit confusing to me.
![image](/uploads/f9c17c222ab19bb4275006288f423a82/image.png)
I understand that the "agenda" below the mini calendar does react to individual days, but I think it should rather match what is being shown in the large calendar, i.e. snap to weeks.
My proposal would be to highlight the entire week on hover, sort of like in this mockup:
![Untitled](/uploads/e5c32eaf8158ecfd835ff61122d2a727/Untitled.png)
<!-- Do not remove the following line. -->https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/61Past events fading in month view does not respect the local system timezone (...2024-03-03T00:56:55ZGeorges Basile Stavracas NetoPast events fading in month view does not respect the local system timezone (uses UTC)Originally reported in [Bugzilla #768622](https://bugzilla.gnome.org/show_bug.cgi?id=768622) by @jfft:
> [Bug #746267](https://bugzilla.gnome.org/show_bug.cgi?id=746267) being fixed is awesome... except that it seems to use UTC time ins...Originally reported in [Bugzilla #768622](https://bugzilla.gnome.org/show_bug.cgi?id=768622) by @jfft:
> [Bug #746267](https://bugzilla.gnome.org/show_bug.cgi?id=746267) being fixed is awesome... except that it seems to use UTC time instead of the machine's local time... so in my case, it is 20h50 UTC-4 and it faded out an all-day multi-day event that ends today, instead of waiting until midnight to fade out the event.
![image](/uploads/a5857e6bfae75400f38e356dcb768910/image.png)https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/296Event-specific color (RFC7986 iCalendar "COLOR") support2024-03-02T18:03:41ZДилян Палаузовgit-dpa@aegee.orgEvent-specific color (RFC7986 iCalendar "COLOR") supportEDS [added support](https://gitlab.gnome.org/GNOME/evolution-data-server/commit/28297f5d3cdf6c8813114c220552d3c65289e957) for [iCalendar COLOR](https://tools.ietf.org/html/rfc7986#section-5.9).
Consider this property, when displaying ev...EDS [added support](https://gitlab.gnome.org/GNOME/evolution-data-server/commit/28297f5d3cdf6c8813114c220552d3c65289e957) for [iCalendar COLOR](https://tools.ietf.org/html/rfc7986#section-5.9).
Consider this property, when displaying events.
If you want to create events with colours, where the colours are not named according to CSS3, but rather have the form 'COLOR:rgb(12,34,56)', then take into account the discussion at https://www.ietf.org/mail-archive/web/calsify/current/msg03048.html.https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1185After adding an event to an invisible calendar, provide a notification overla...2024-03-01T03:49:52ZJeff FortinAfter adding an event to an invisible calendar, provide a notification overlay toast that allows unhiding / showing the hidden calendar in the viewWhen a new event gets added to a hidden calendar (from the Event Editor dialog as per #950, or the .ics file importer as per #1184), it would be extra nice if we could show an `AdwToast` toast notification overlay with action button, say...When a new event gets added to a hidden calendar (from the Event Editor dialog as per #950, or the .ics file importer as per #1184), it would be extra nice if we could show an `AdwToast` toast notification overlay with action button, saying something like:
> Your event has been added to "`%s`", which is currently hidden. [ Show calendar ]
Where `%s` is the hidden calendar's name, and the "Show calendar" button allows conveniently turning on the visibility of that calendar.
This toast could be shown for 5 seconds (same as the Undo toast that shows up just after deleting an event), or a bit longer (7 seconds? 10 seconds?) to give time for people to read it, since letting it linger a bit longer than a "pending event deletion" is not really a problem.
---
Coding hints: look at...
* the existing toast used when deleting events, in `on_event_editor_dialog_remove_event_cb` in `gcal_window.c`
* `on_event_removed` vs `on_event_created` in `gcal-manager.c`https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/649Meta tracking issue: "Infinite Scroll" multi-days / "Timetable" view2024-02-28T14:19:40ZAdrian L. ShawMeta tracking issue: "Infinite Scroll" multi-days / "Timetable" viewOriginal description:
> The Week tab in GNOME calendar shows a 7 day week. It would be nice if it could be configured to show only 5 days (a typical working week), using the settings. This is an option in some other calendar apps.
Edit...Original description:
> The Week tab in GNOME calendar shows a 7 day week. It would be nice if it could be configured to show only 5 days (a typical working week), using the settings. This is an option in some other calendar apps.
Edit by @jfft:
This is the "horizontal" counterpart to issue #1 and #603.
It would allow replacing the traditional 7-days week view, and all potential (non-implemented) derived views such as the "5-days work week" view and the "upcoming days only" view. An infinite scrolling timetable timeline view solves it all at once.
## Technical & design challenges
A static non-scrolling number of day columns would be the "easy stepping stone" stopgap solution. The ultimate/ideal solution, however, is implementing this as the counterpart to #603 (the "infinite scrolling" month view), but for month view, with a configurable width in terms of "number of shown day columns" (and ideally configurable number of rows, #10 ...).
Doing the week view as an infinite horizontally scrolling timeline is technically much harder to implement than issue 603 because of the "all-day events" header area, mainly the ordering/stacking algorithm for them. Some other apps (like Google Calendar's 3-day view on mobile phones, or Week view on tablets) already solved this UX issue & heuristic. See also #59 for part of the heuristic issue.
In terms of UI configurability, the UX challenge is hinted at in #1064 ; _before_ that ticket, I originally wrote:
> maybe there could be a spinbutton widget in the "hamburger" menubutton that controls the number of days shown in timetable/multi-days view; if you want to keep that menubutton simpler, that spinbutton could be shown only when inside the timetable/multi-days view.Jeff FortinJeff Fortinhttps://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1179Exactly midnight-to-midnight events are displayed as time-based instead of al...2024-02-26T13:52:35ZJeff FortinExactly midnight-to-midnight events are displayed as time-based instead of all-dayThis is a corner case that is different from #889, #1098, #172, #967, #968...
I believe it is _only_ about the display/rendering of the events that are "midnight to midnight" across different dates within the same timezone (possibly bro...This is a corner case that is different from #889, #1098, #172, #967, #968...
I believe it is _only_ about the display/rendering of the events that are "midnight to midnight" across different dates within the same timezone (possibly broken encoding of all-day events by some other calendaring systems? Or is that actually spec-compliant?!)…
Mozilla's [Firefox release dates only calendar](https://www.google.com/calendar/ical/mozilla.com_2d37383433353432352d3939%40resource.calendar.google.com/public/basic.ics) (found on [this wiki page](https://wiki.mozilla.org/index.php?title=Release_Management%2FCalendar&redirect=no), not yet on [this page](https://whattrainisitnow.com/calendar/)) is the test case for this. It contains events like these:
```
BEGIN:VEVENT
DTSTART:20240319T040000Z
DTEND:20240320T040000Z
DTSTAMP:20240223T190750Z
UID:22khvcbfrg5phethl8ljkmgcso@google.com
ATTENDEE;CUTYPE=RESOURCE;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;CN=mozilla.
com_2d37383433353432352d3939@resource.calendar.google.com;X-NUM-GUESTS=0:ma
ilto:mozilla.com_2d37383433353432352d3939@resource.calendar.google.com
CREATED:20230830T163006Z
LAST-MODIFIED:20230830T163006Z
LOCATION:Public - Firefox Merge/Release Schedule
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:Firefox 124 released
TRANSP:OPAQUE
END:VEVENT
```
…we can see that it starts _and_ ends at midnight UTC, on two different days, i.e. an exactly 24-hours event:
```
DTSTART:20240319T040000Z
DTEND:20240320T040000Z
```
The result is that GNOME Calendar 46 displays it as time-based:
| Week view | Month view |
| ------ | ------ |
| ![image](/uploads/1222b6cc75eecb9b4b16b13395d13cef/image.png) | ![image](/uploads/27e42c57150d0849db5f05d67b854305/image.png) |
However, Evolution displays it as an all-day event (which is what users would expect) instead:
![image](/uploads/6f4a9fa8c28d940cbc4dbd128bebc825/image.png)https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/759Visual artifacts (duplicated / non-removed events) when rapidly switching acr...2024-02-22T06:56:13ZEzwenVisual artifacts (duplicated / non-removed events) when rapidly switching across weeks or months
I'm using gnome-calendar with many different remote calendars at the same time (7 CalDav and 3 ICS).
When using the week view, I very often encounter bugs when trying to rapidly switch from a week to another (eg. rapidly clicking 5 tim...
I'm using gnome-calendar with many different remote calendars at the same time (7 CalDav and 3 ICS).
When using the week view, I very often encounter bugs when trying to rapidly switch from a week to another (eg. rapidly clicking 5 times on the right arrow to move from week 10 to week 15). Two bugs tend to occur: (1) sometimes some events are not removed from the view of a given week, and remain when showing another week (eg. some event from week 12 gets shown in week 15), (2) the same event appear "cloned" multiple times, hence shown as multiple boxes in the same time slot.
My feeling is that the UI has a hard time "catching up" both with rapid clicking to switch weeks, and with having to sync with so many remote calendars at the same time, and ends up reaching inconsistent/invalid visual states.
I could provide a video showing some of the problems, but for privacy reasons it's a little difficult…
- gnome-calendar version: 41.1
- GNOME version: 41.1
- Fedora version: 35https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/603Meta tracking issue: "Infinite Scroll" smooth + "ratcheting" scrolling month/...2024-02-22T06:55:15ZJeff FortinMeta tracking issue: "Infinite Scroll" smooth + "ratcheting" scrolling month/multiweek viewThis ticket here is the "ponies on rainbows" endgame successor to issue #1 ~~which could be considered merely a stepping stone / intermediate implementation (ticket no1 would allow doing an initial backend implementation and very simple ...This ticket here is the "ponies on rainbows" endgame successor to issue #1 ~~which could be considered merely a stepping stone / intermediate implementation (ticket no1 would allow doing an initial backend implementation and very simple UI, without having to worry about the whole supporting GTK UI widgetry for high-performance infinite smooth scroll with animations and touch+scrollwheel+keyboard support).~~ Edit: the intermediate "ticket no1" approach is not needed anymore! But useful to look at if you want to learn about the usage scenarios/UX motivations behind all this.
## Why this matters
In terms of UX, this is the "ultimate" infinite month view, freed from the artificial physical-paper-like boundaries of a "month": it lets you use it as a traditional month view if you want, or use it as a multi-week "only the weeks ahead" view, and go up/down as you please on a week-by-week basis.
This is a more "optimal" solution than #1, because it avoids requiring multiple "month vs multi-week" view types, it simply provides _one_ unified and flexible continuous timeline of weeks in a grid, that is no longer chained to the metaphor of physical paper calendar "pages" and allows reducing the amount of widgets and interactions needed in the UI. Compared to the "lazy" approach of a static "Next 3 weeks" separate view, it is more complex to design and implement (it has a lot more details you need to "get right", whether in terms of UI representation or in terms of kinetics management), _but_ the results are way, _way_ better. It also forces us to optimize performance to make this possible.
Others have also thought about this "infinite scrolling timeline" idea in the past, and other calendaring apps out there have implemented it. It's an elegant solution.
Solving this also solves a _ton_ of other technical/architectural issues, and UX issues (see some of the related ones linked below).
## Proposed user interaction & UX
As of 2023, my idea now is that the scroll behavior should be per-week (instead of per-month) and smooth, but _also_ behave like a "[ratchet](https://en.wikipedia.org/wiki/Ratchet_(device))" mechanism, i.e. it "clicks into place" like a "wheel of fortune", "coverflow", or rubberband:
* When scrolling with a **traditional mousewheel** (with discrete "clicks") or **keyboard** (`↓`/`↑` arrow keys), it should go up/down 1 calendar row (or left/right one column, in weekview, when using the `←`/`→` keys or `Shift`+mousewheelscroll) per "mousewheel ratchet click(s)", with a smooth animation that ends with a perfectly aligned week row everytime you finish spinning the mousewheel (or keyboard keys); like a ratchet, but actually double-sided.
* With an **infinite scrollwheel** (like some mice have, either by default or as a mode), **touchpad/trackpad, or touchscreen swiping/gestures**: same thing, but the ratchet behavior would only happen once kinetic scroll movement has ended (or influencing the end of the kinetic movement to "round up" the target destination), to allow free scrolling until it clicks into place. In other words, it would be dependent on the position where the user stops the wheel/swipe.
* A tricky part is ensuring this stays in place when resizing the window height, instead of creating "half-rows"...
* #1064 : user configurable amount of rows in month view. Old description:
> The height/number of rows shown on screen could be adjusted with pinch zoom and ctrl+scroll like in the week view, but this could be tricky to deal with because it would also need a ratcheting mechanism... a simpler way could be to have a configurable setting for the number of desired rows to show in multiweek view (this is what Google Calendar and Fantastical do; I suppose maybe iCal does that too, I don't know). Likewise for the amount of columns in week view. If issues #1 and #649 are implemented before this issue here, this part might be implemented already.
## Potential to replace other traditional views
* This replaces the traditional "Month" view (when at least 4 week rows are shown, this is for all practical purposes a feature-complete replacement of the month view, functionally speaking). It could be renamed "Grid" view or "Multi-weeks" if desired. You _could_ have both the "[Jump to] Today" action to align the current week to the top edge, and a "Align to current month" action (if necessary, but not sure that's actually necessary) to ratchet-align the 1st week of the current month to the top. Switching between months (with clickable UI buttons, or `PgUp`/`PgDown` keys) would simply scroll to ratchet-align the next/previous month's 1st week to the top.
* Eventually we could apply the same architectural concept to the week view, replacing the traditional "Week" view by something we could nickname the "Timetable" or "Multi-days" view: #649Jeff FortinJeff Fortin