GNOME issueshttps://gitlab.gnome.org/groups/GNOME/-/issues2019-12-03T14:06:47Zhttps://gitlab.gnome.org/GNOME/mutter/-/issues/781Implement MetaWindowContent2019-12-03T14:06:47ZGeorges Basile Stavracas NetoImplement MetaWindowContentGNOME 3.36Georges Basile Stavracas NetoGeorges Basile Stavracas Netohttps://gitlab.gnome.org/GNOME/yelp/-/issues/200Design: Port to Gtk42023-03-05T12:39:35ZBenjamin S. Osenbach (GNOME profile)Design: Port to Gtk4With most GNOME apps moving to Gtk4 / libadwaita, I wanted to kickoff a discussion about the merits of porting Yelp's user interfaceWith most GNOME apps moving to Gtk4 / libadwaita, I wanted to kickoff a discussion about the merits of porting Yelp's user interfacehttps://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/856Weather information overlaps with dates in month view at smaller widths2024-03-07T15:03:17ZAthul IddyaWeather information overlaps with dates in month view at smaller widths<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Affected version
Fedora 37 Workstation with GNOME 43.beta ([test day image](ht...<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Affected version
Fedora 37 Workstation with GNOME 43.beta ([test day image](https://fedoraproject.org/wiki/Test_Day:2022-08-15_Fedora_37_GNOME_43_Beta))
### Bug summary
Weather information overlaps with dates in month view at smaller widths.
### Steps to reproduce
1. Ensure that "Show Weather" option is turned on
2. Resize calendar horizontally until just before the sidebar takes over the whole window
### What happened
Weather information overlaps with dates in month view.
### What did you expect to happen
Weather information should not overlap with dates.
### Relevant logs, screenshots, screencasts etc.
![Screenshot_from_2022-08-14_18-35-20](/uploads/4927e7fc8215aa8799cd4eb0558959dd/Screenshot_from_2022-08-14_18-35-20.png)
<!-- Do not remove the following line. -->GNOME 47Markus GöllnitzMarkus Göllnitzhttps://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/898All-day events and events ending at midnight create duplicates of days in the...2024-03-07T15:03:18ZJeff FortinAll-day events and events ending at midnight create duplicates of days in the sidebarBasically what you can see with this screenshot of GNOME Calendar 43 on Fedora 37: today, "samedi octobre 22" is shown twice instead of only once.
![gnome-calendar-43-sidebar-has-trouble-with-midnight](/uploads/e805d884be3dfb2b1dfe1cf44...Basically what you can see with this screenshot of GNOME Calendar 43 on Fedora 37: today, "samedi octobre 22" is shown twice instead of only once.
![gnome-calendar-43-sidebar-has-trouble-with-midnight](/uploads/e805d884be3dfb2b1dfe1cf447a8fe5d/gnome-calendar-43-sidebar-has-trouble-with-midnight.png)
I can only guess that there's a check going on for event boundaries at midnight, but when you have an event that ends exactly at midnight (like my "prep une autre DOUBLE batch de pâte à pain" event, from 23h00 to 00h00) or an all-day event (which, I will guess, is considered to be an event that goes from midnight to midnight?), then GNOME Calendar thinks "Oh it's spanning two days, from the 22nd to the 22nd! Clearly not the same as those hourly events that occur during the day of the 22nd! Yup, makes sense!"
This can lead to some funky situations such as this (screenshot taken on a 31st of August):
![image](/uploads/4ba5c6745553d0d6841221c215bf92c2/image.png)
See also issue #968 ...GNOME 47Daniel Garcia MorenoDaniel Garcia Morenohttps://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/968All-day events and time-based events within the same day create a day heading...2024-03-17T12:04:29ZJeff FortinAll-day events and time-based events within the same day create a day heading separation in the sidebarAn easy testcase for the sidebar in 43.1 and nightly, set up a mixture of single-day all day events and some time-based events, in tomorrow's cell in month view:
![image](/uploads/9cef34af266c708d5f29449aa941a647/image.png)
...and this...An easy testcase for the sidebar in 43.1 and nightly, set up a mixture of single-day all day events and some time-based events, in tomorrow's cell in month view:
![image](/uploads/9cef34af266c708d5f29449aa941a647/image.png)
...and this will be the result in the sidebar:
![image](/uploads/4af3c58d3cfc9fb51b8350e3dcb718f4/image.png)
...it doesn't make sense that "Tomorrow" would be shown twice. Also, we can see there that the chronological order is inverted (issue #936).
Overall, this can lead to some pretty ridiculously cluttered situations (for example, in the screenshot below taken on August 31st, where we have 3 headers for the next day, September 1st / Tomorrow, and 3 headers for the day that follows it... simply because I have a mix of time-based, all-day-single-day and multi-day events):
![image](/uploads/4ba5c6745553d0d6841221c215bf92c2/image.png)GNOME 47Daniel Garcia MorenoDaniel Garcia Morenohttps://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1103With the infinite timeline, clicking the Previous / Next month button in the ...2024-03-07T15:03:18ZJeff FortinWith the infinite timeline, clicking the Previous / Next month button in the sidebar jumps by ±5 weeks based on the current day, instead of clamping to the month's "day 1"This is a small UX regression I did not notice when testing:
1. Scroll to the middle of the month so that something other than the 1st week is aligned to the top (if not already the case, if today happens to not be on the 1st week of th...This is a small UX regression I did not notice when testing:
1. Scroll to the middle of the month so that something other than the 1st week is aligned to the top (if not already the case, if today happens to not be on the 1st week of the month)
2. Click the Previous/Next month buttons in the sidebar's minicalendar, or use the `PgUp` / `PgDown` keyboard shortcuts
Results: The new month view jumps forward by the number of rows (currently 5), without regards to the notion of month.
Expected results:
* When specifically asking to switch to the previous/next month, instead of using infinite scrolling, most users (including me) will expect the view to clamp/align to the 1st day/week of the previous/next month, so don't jump exactly 5 weeks, jump to the 1st day of the previous/next month.
* When you are in a previous/next month and click those buttons (or shortcuts) to go back to the current month, I think it would still be expected to clamp to the 1st day of the month, instead of "Today". If the user wanted to align/clamp to "Today", they can/should click the "Today" button.GNOME 47Fabian HügelFabian Hügelhttps://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/171Floating time events incorrectly interpreted as UTC2024-03-09T22:26:21ZGeorges Basile Stavracas NetoFloating time events incorrectly interpreted as UTCIn GNOME Calendar, "floating time" events are incorrectly interpreted as UTC.
Calendar wrongly "converts" that to local time for display, and "from" local time when writing.
For example, on a system with a Europe/London time zone (cur...In GNOME Calendar, "floating time" events are incorrectly interpreted as UTC.
Calendar wrongly "converts" that to local time for display, and "from" local time when writing.
For example, on a system with a Europe/London time zone (currently UTC+1), the following:
```
DTSTART:20170818T140000
DTEND:20170818T150000
```
is displayed in Calendar as 15:00-16:00 (i.e. interpreted as 14:00-15:00 UTC, then displayed as 15:00-16:00 UTC+1).
Instead, it should be interpreted as 14:00-15:00 in the user's current time zone.
Editing the event time continues this misinterpretation - the start/end are written out in floating time format, as if it is a UTC time being written. So editing the above example in Calendar and changing the times to 16:00-17:00 results in:
```
DTSTART:20170818T150000
DTEND:20170818T160000
```
The iCalendar DATE-TIME value type forms are specified here: https://tools.ietf.org/html/rfc5545#section-3.3.5
**[Link to original bug (#786155)](https://bugzilla.gnome.org/show_bug.cgi?id=786155)**
---
Note: this affects both .ics file imports and webcal / online calendars.GNOME 47https://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/994Events in the sidebar agenda sometimes not updated / not removed when moving ...2024-03-27T15:26:25ZLukas RuzickaEvents in the sidebar agenda sometimes not updated / not removed when moving events across the Month View### Affected version
* Fedora 38 Beta
* gnome-calendar-44~rc-1.fc38.x86_64
### Bug summary
When an event is created, it also appears in the left overview bar of the application. When the event is edited, after a while the change prop...### Affected version
* Fedora 38 Beta
* gnome-calendar-44~rc-1.fc38.x86_64
### Bug summary
When an event is created, it also appears in the left overview bar of the application. When the event is edited, after a while the change propagates into the overview bar. However, when the application is dragged and pulled to a different date slot, the changes will not propagate until Calendar is restarted which is confusing.
### Steps to reproduce
See the screencast:
![Screencast_from_2023-03-15_14-46-08](/uploads/7e4a2b8fd73795210b8a550606aaec4e/Screencast_from_2023-03-15_14-46-08.webm){width=100%}
### What happened
The overview does not change after drag and drop.
### What did you expect to happen
The overview should change accordingly.
### Relevant logs, screenshots, screencasts etc.
See above
<!-- Do not remove the following line. -->https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1092Dragging an event in month view does not work if dragging over another event ...2023-11-13T21:43:48ZPhilipp SDragging an event in month view does not work if dragging over another event (only empty spaces in the cell act as drop targets)### Affected version
45\.0- 9ace504e
### Bug summary
When dragging an event in month view not the whole target grid cell acts as a drop target as one would expect. The area covered by events in that cell does not accept the drop actio...### Affected version
45\.0- 9ace504e
### Bug summary
When dragging an event in month view not the whole target grid cell acts as a drop target as one would expect. The area covered by events in that cell does not accept the drop action. Instead only the remaining area in the cell accepts the drop action.
### Steps to reproduce
Drag an event to another cell in month view that contains some event items. Release it above an event item.
### What happened
When releasing the dragged event in another cell above an event item, the drop action is not performed and the intended move of the event to that cell fails without any indication.
### What did you expect to happen
The whole grid cell should act as the drop target regardless of events below the pointer.https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1125With some AMD Radeon graphics, infinite scroll may be a bit laggy2024-03-16T16:28:38ZJeff FortinWith some AMD Radeon graphics, infinite scroll may be a bit laggyOn my desktop workstation machine, GNOME Calendar 45+'s month view scroll animation can be a bit slow:
* It feels like 20-25 fps rather than 60.00 fps, even on an optimized version of GNOME Shell on Wayland.
* It feels slower if there a...On my desktop workstation machine, GNOME Calendar 45+'s month view scroll animation can be a bit slow:
* It feels like 20-25 fps rather than 60.00 fps, even on an optimized version of GNOME Shell on Wayland.
* It feels slower if there are more events to be shown.
Hardware info and comparisons:
* My machine's GPU is an AMD "Curacao PRO" Radeon R9 270, paired with an Intel Xeon® W3520 ×8 CPU and 24 GB of RAM.
The system's flatpak directories, caches, etc. all are on a SSD. This happens with the lightweight system-installed version as well as the flatpaked versions.
* This is not really felt easily on newer machines (such as an Intel Kabylake laptop), but it is possible that the issue occurs on newer machines while not being noticeable because they are so overpowered (and Intel drivers instead of AMD).
While I can live with this slight jankiness, and I'm not sure if it's a bug in GNOME Calendar or somewhere else in the stack… _just in case_ if there _is_ something fishy in the output below and we can optimize something in there, it would be nice to have.
## Sysprof 45 profiling captures
The raw sysprof 45.1 capture can be downloaded [here](https://fortintam.com/public/gnome-calendar-1125-sysprof-45.1-capture.tar.xz). It will decompress to a 3 GB filesize on your system.
The app startup was slow (and the app behaved slower than usual) during recording, probably because I told sysprof to also record all memory allocations. As such, the relevant part (where I scroll the month view with the mouse wheel) probably only starts around the 20 seconds mark.
This is roughly what the main views in sysprof look like with this capture, filtered to show what happens after the ~20 seconds mark:
![2023-12-08_23-53-55_gnome-calendar_45.1_-_sysprof_45_-_flame_graph_zoomed_in_2_-_crop.opti](/uploads/ff0e7ca0fa65103f308f2dac4cb3827c/2023-12-08_23-53-55_gnome-calendar_45.1_-_sysprof_45_-_flame_graph_zoomed_in_2_-_crop.opti.png)
| Call graph, the EDS part | Call graph, the GTK part |
| ------ | ------ |
| ![2023-11-18_15-38-32_gnome-calendar_45.1_-_sysprof_45_-_call_graph](/uploads/dc48aa959ebf837677f7e85c51bb2b37/2023-11-18_15-38-32_gnome-calendar_45.1_-_sysprof_45_-_call_graph.png) | ![2023-12-09_00-01-31_gnome-calendar_45.1_-_sysprof_45_-_call_graph_part_2__GTK_.opti](/uploads/9a1aba40dc79026b1999c263b65f414c/2023-12-09_00-01-31_gnome-calendar_45.1_-_sysprof_45_-_call_graph_part_2__GTK_.opti.png) |
| Marks chart | Marks summary |
| ------ | ------ |
| ![2023-11-18_15-39-26_gnome-calendar_45.1_-_sysprof_45_-_mark_chart](/uploads/7d928276b8b7c6743ee088e1356eca04/2023-11-18_15-39-26_gnome-calendar_45.1_-_sysprof_45_-_mark_chart.png) | ![2023-11-18_15-40-07_gnome-calendar_45.1_-_sysprof_45_-_mark_summary](/uploads/a3fe60bb8e84997f3f2165eb7bf2117d/2023-11-18_15-40-07_gnome-calendar_45.1_-_sysprof_45_-_mark_summary.png) |https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1066(New Month View) With certain row start dates, "Today" button's sensitivity i...2024-03-09T20:42:06ZJeff Fortin(New Month View) With certain row start dates, "Today" button's sensitivity is incorrect when aligned to the current week or a week adjacent to itA variant of bug #1063 : if you scroll to the 3nd week row of August 2023 "in a locale that starts the week on Sunday" while we currently are in the 2nd week of August 2023, the `Today` button will remain insensitive, probably because it...A variant of bug #1063 : if you scroll to the 3nd week row of August 2023 "in a locale that starts the week on Sunday" while we currently are in the 2nd week of August 2023, the `Today` button will remain insensitive, probably because it thinks that Sunday August 13th (which is shown at the start of the 3rd week in month view), belongs to the (current) 2nd week of August (which it does, technically/numerically, as it is not the 14th day).
Demonstration video:
![2023-08-08_sunday_confuses_week_heuristic_for_Today_in_month_view](/uploads/06d3d59b2d37328f848a3dcab2172ab0/2023-08-08_sunday_confuses_week_heuristic_for_Today_in_month_view.mp4)
Another example (with the month of September) is described in a comment below.
---
This is most likely the same causes as #1192
Hints:
* This bug is maybe not a regression from the infinite timeline month view branch, but probably emanates from the heuristic of "when is it the current week?" from the Week View that we now depend on since bug #1063.
* Will also have to take #160 into account once that lands (ideally, fix 160 first!)https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1192When selecting a dates cells range from Sunday to Monday, quick-add popover o...2024-03-09T20:41:28ZJeff FortinWhen selecting a dates cells range from Sunday to Monday, quick-add popover only says "next Sunday" or "Tomorrow"As found by @theevilskeleton, in versions 45-46+, if you select both the upcoming Sunday and Monday, the label in the quick-add popover is incorrect.
Some examples:
| When testing some days prior | When tested on a Saturday (Sat is bl...As found by @theevilskeleton, in versions 45-46+, if you select both the upcoming Sunday and Monday, the label in the quick-add popover is incorrect.
Some examples:
| When testing some days prior | When tested on a Saturday (Sat is blue, but not actually selected) | When testing on a Monday |
| - | - | - |
| ![image](/uploads/5117dead4ea90388c85c8c382412f675/image.png) | ![image](/uploads/3796436fd498ed49916c30ac0db5a6fb/image.png) | ![foo](/uploads/04a49f6d19be4b4d0f73cb456fafadec/foo.jpg) |
This is most likely the same causes as #1066.
---
Hints:
* This bug is maybe not a regression from the infinite timeline month view branch, but probably emanates from the heuristic of "when is it the current week?" from the Week View that we now depend on since bug #1063.
* Will also have to take #160 into account once that lands (ideally, fix 160 first!)https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1089In reduced animations mode, scrolling the New Month View by one mouse wheel "...2024-03-16T16:28:38ZJeff FortinIn reduced animations mode, scrolling the New Month View by one mouse wheel "notch" unit sometimes scrolls 2 weeks instead of 1The fix for issues #1079 and #1080 works well! However, its faster timing (100ms instead of 150ms) reveals another minor bug. That bug _sometimes_ (very rarely) happens in normal animations mode, but it somehow seems to be much easier to...The fix for issues #1079 and #1080 works well! However, its faster timing (100ms instead of 150ms) reveals another minor bug. That bug _sometimes_ (very rarely) happens in normal animations mode, but it somehow seems to be much easier to encounter in reduced animations mode.
## How to reproduce
1. Use a traditional external mouse with a ratchetty "discrete" mouse wheel
(instead of a continuous mouse wheel), where there are notches to "clack" / ratchet to
2. Ratchet up and down one notch on the mouse wheel, at various speeds (slow / medium) while being careful to only do one notch at a time (you'll feel it with the fingers)
## Symptoms
_Sometimes,_ even if you did a single wheel ratchet "clack" motion clamping to its wheel's physical notch, it jumps 2 weeks in the month view instead of 1.
Tips:
* To notice the symptom more easily, keep your eyes on the minicalendar's week highlight visual while doing the scrolling, instead of looking at the month view's grid itself.
* The ideal behavior would be that it should always match the physical notches/tactile feedback of traditional mice, by not accidentally skipping weeks.
## Additional info
* I have tested this on three different Logitech mice, and two different GPUs (Intel and AMD Radeon) on a Wayland GNOME session on Fedora 38, wit the nightly flatpak version of GNOME Calendar. So presumably, it's not the graphics stack acting up.
* This seems to happen even if I turn off a bunch of calendars, so presumably it's not entirely related by how heavily loaded your calendar's view is, but it _might_ be easier to trigger if you have many calendars with tons of events filling up the view.
* The 150ms normal animations version appears to be much less likely to cause that to happen, for some mysterious reason.
Non-urgent priority: this is a relatively minor/harmless issue. The "workaround" is simply to scroll again to correct the offset scroll. Therefore, it's "nice to fix" if easy-enough, otherwise a non-critical annoyance.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/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/1118Updating or moving event out of a day from the overflow popover does not upda...2023-11-27T02:55:01ZnicolasUpdating or moving event out of a day from the overflow popover does not update / remove the event from the overflowThese two manifestations of the bug still occur with version 45+ / nightly
## Scenario 1: moving events (original description)
This happens to me all the time and I get confused each time, sometimes deleting the event by mistake becaus...These two manifestations of the bug still occur with version 45+ / nightly
## Scenario 1: moving events (original description)
This happens to me all the time and I get confused each time, sometimes deleting the event by mistake because of it.
1. Have more than X event on a day (4 on my screen) so that all events don’t fit in the day and you have to click the day to get a popover with all events.
2. Move one of these events to another days.
Expected: The event is moved.
Actual: The event is actually moved, but what you see is that the event is still shown in the popover like if you didn’t move it. Demonstration:
![Screencast_from_2023-10-31_18-32-36](/uploads/e72247f44f3791028026ae109e8560e3/Screencast_from_2023-10-31_18-32-36.webm)
## Scenario 2: updating events
Edit by @jfft: this bug also affects any updates to existing events in the overflow widget. For example, open the overflow, click one of the events to open the event editor, change the event's title (or change the time, or change the assigned calendar) and save the changes; changes will not be reflected in the overflow widget.https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/807event detail: Reminder alarm toggle is not saved2024-03-14T20:20:47ZSophie Heroldevent detail: Reminder alarm toggle is not savedAlso, there are 3 states for the button. The bottom one appears after adding the reminder.
![image](/uploads/ecc6de4b5d78af52da85b496bdc6f3f4/image.png)Also, there are 3 states for the button. The bottom one appears after adding the reminder.
![image](/uploads/ecc6de4b5d78af52da85b496bdc6f3f4/image.png)GNOME 47Abdullahi UsmanAbdullahi Usmanhttps://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1001Can't add / remove / modify reminders on existing events2024-03-14T20:20:47ZIslam BahnasyCan't add / remove / modify reminders on existing events### Affected version
OS: Ubuntu 22.10
gnome-calendar: 43.0-2, and the nightly version
### Bug summary
Can't add reminder to existing ~~NexCloud~~ event
### Steps to reproduce
1. ~~Add NextCloud account the the online accounts and en...### Affected version
OS: Ubuntu 22.10
gnome-calendar: 43.0-2, and the nightly version
### Bug summary
Can't add reminder to existing ~~NexCloud~~ event
### Steps to reproduce
1. ~~Add NextCloud account the the online accounts and enable Calendar sync.~~
2. From gnome-calendar try to edit and existing ~~recurring~~ event and add a reminder to it.
3. Close gnome Calendar and re-open it; or just re-edit that event.
### What happened
The reminder is not saved, neither locally or remotely.
### What did you expect to happen
The reminder should have been saved to the event and synced to the remote server.
<!-- Do not remove the following line. -->GNOME 47Abdullahi UsmanAbdullahi Usmanhttps://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1146Manage Calendars window: calendar subpages have no window title2024-03-07T15:03:16ZAutomeris naranjaManage Calendars window: calendar subpages have no window title## Affected version
45.1 - Flathub
## Steps to reproduce
1. Go to Calendars dropdown menu > Manage Calendars...
2. Open a calendar
## Seen behavior
The window will have no title.
![image](/uploads/a4cd1a2e68330610830db4ede97cc973/imag...## Affected version
45.1 - Flathub
## Steps to reproduce
1. Go to Calendars dropdown menu > Manage Calendars...
2. Open a calendar
## Seen behavior
The window will have no title.
![image](/uploads/a4cd1a2e68330610830db4ede97cc973/image.png)GNOME 47Aurélien DeloryAurélien Delory