gnome-calendar issueshttps://gitlab.gnome.org/GNOME/gnome-calendar/-/issues2024-03-28T14:15:15Zhttps://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1205Adaptive event details dialog2024-03-28T14:15:15ZPhilipp SAdaptive event details dialogThe current event details popover does not use modern libadwaita widgets and is not adaptive. I developed the following updated design for the event details.
It's designed to be adaptive for narrow and wide screens, and meant to be imp...The current event details popover does not use modern libadwaita widgets and is not adaptive. I developed the following updated design for the event details.
It's designed to be adaptive for narrow and wide screens, and meant to be implemented using libadwaita dialogs. They can show more content at once on desktop and fit into limited space on mobile. The event details dialog shows all available information in a read-only and compact way and hides away all the widgets of the event editor dialog that are not used. Some advantages are:
- adaptive, no placement outside the window
- compact but complete presentation of information
- different actions (e.g. joining a video call) on the widgets than in the event editor
- always opens in the same predictable location (centered)
- can be opened from search results
![EventDetailsDialog](/uploads/5c23d146f6fbfd3e453ec7791bb123c3/EventDetailsDialog.png)
[EventDetailsDialog.svg](/uploads/b29a4034031d17b71c7c10ea9deb118b/EventDetailsDialog.svg)
@snwh @jfft @TheEvilSkeleton @feaneronhttps://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1204Date format should be localizable in Event Widget2024-03-27T13:08:20ZJordi MasDate format should be localizable in Event WidgetHello,
Currently the dates in Catalan in the event Widget are shown as "dilluns abril 1" when it should show "dilluns 1 d'abril"
This code https://gitlab.gnome.org/GNOME/gnome-calendar/-/blob/main/src/gui/gcal-event-widget.c?ref_type=h...Hello,
Currently the dates in Catalan in the event Widget are shown as "dilluns abril 1" when it should show "dilluns 1 d'abril"
This code https://gitlab.gnome.org/GNOME/gnome-calendar/-/blob/main/src/gui/gcal-event-widget.c?ref_type=heads#L403:
` timestamp_str = g_date_time_format (time, "%a %B %e");`
Should be translatable. Currently it assumes that dates will be "month (%B) - day (%e)" for all locales, but this order changes depending on the locale.
The easiest will be do make it translatable.
Finally, this seems to be also another problem of the same type in the Agenda View:
https://gitlab.gnome.org/GNOME/gnome-calendar/-/blob/main/src/gui/views/gcal-agenda-view.c?ref_type=heads#L188https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1203Multi day event incorrectly drawn for the whole week2024-03-24T15:22:03ZlightonfluxMulti day event incorrectly drawn for the whole week### Affected version
* Your OS and version: Fedora 39
* Affected GNOME Calendar version: 46.1-ac5b3828 (and latest stable)
### Bug summary
Calendar event from Monday 9:00 to Thursday is drawn until sunday / end of week. The yellow "Na...### Affected version
* Your OS and version: Fedora 39
* Affected GNOME Calendar version: 46.1-ac5b3828 (and latest stable)
### Bug summary
Calendar event from Monday 9:00 to Thursday is drawn until sunday / end of week. The yellow "Nachmeldephase" event with the tooltip below. The part that is marked in red is erroneously drawn.
![Bildschirmfoto_vom_2024-03-24_15-53-46](/uploads/0f1225f091b395c174c4d3e4952018f1/Bildschirmfoto_vom_2024-03-24_15-53-46.png)
### Steps to reproduce
No idea. I cannot reproduce it so far.
### What happened
I created an event some time ago on a CalDAV calendar, it is an application phase, Gnome Calendar is the only calDAV client that displays the event incorrectly, but its the only client i checked and missed the deadline.
### What did you expect to happen
Multi day events should only be drawn until the end of the event, not the view.
### Relevant logs, screenshots, screencasts etc.
#### Exported ics:
```
BEGIN:VCALENDAR
CALSCALE:GREGORIAN
PRODID:-//Ximian//NONSGML Evolution Calendar//EN
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Europe/Berlin
X-LIC-LOCATION:Europe/Berlin
BEGIN:DAYLIGHT
TZNAME:CEST
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
DTSTART:19810329T020000
RRULE:FREQ=YEARLY;UNTIL=20370329T010000Z;BYDAY=-1SU;BYMONTH=3
END:DAYLIGHT
BEGIN:STANDARD
TZNAME:CET
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
DTSTART:19961027T030000
RRULE:FREQ=YEARLY;UNTIL=20361026T010000Z;BYDAY=-1SU;BYMONTH=10
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
UID:cb4398391aaxx4364b6d04845
DTSTAMP:20240201T144034Z
DTSTART;TZID=Europe/Berlin:20240318T090000
DTEND;TZID=Europe/Berlin:20240321T130000
SUMMARY:XXXX Nachmeldephase
SEQUENCE:4
CREATED:20240201T144130Z
LAST-MODIFIED:20240201T144130Z
END:VEVENT
END:VCALENDAR
```
<!-- Do not remove the following line. -->https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1202Dates for all-day events in the Sidebar might sometimes be offset by 1 day fo...2024-03-22T21:00:46ZDebasish PatraDates for all-day events in the Sidebar might sometimes be offset by 1 day for `VALUE=DATE` events
<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
Gnome Calendar 46.0
<!--
Provide at least the following information:
* Your OS an...
<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
Gnome Calendar 46.0
<!--
Provide at least the following information:
* Your OS and version
* Affected GNOME Calendar version
-->
Arch Linux
Gnome Calendar 46.0
### Bug summary
ICS file loaded to calendar shows incorrect date in left sidebar in Gnome Calendar 46.0
<!--
Provide a short summary of the bug you encountered.
-->
Please find the screenshot below and compare the dates in the grid and the dates in the left sidebar.
![Screenshot_from_2024-03-21_19-56-41](/uploads/7b8f3950728c0efe1e9401e62f936f33/Screenshot_from_2024-03-21_19-56-41.png)
Sample ICS file attached in case its required
[2024-India-Bangalore.ics](/uploads/48f93acd3bb1ac0d3967404a98b68897/2024-India-Bangalore.ics)
### Steps to reproduce
i. Load any ICS Calendar file offline in Gnome Calendar 46.
ii. Look for the Dates in the sidebar for the event.
iii. It is always the event date+1 instead of event date as shown in color code in the left sidebar of Gnome calendar
Please let me know if i need to make any other corrections or attach debugs for the bug to be clear or help with reproducing it.
<!-- Do not remove the following line. -->https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1201Fast Scrolling is Slower than Slow Scrolling2024-03-16T16:28:38ZsnoutieFast Scrolling is Slower than Slow Scrolling<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Affected version
<!--
Provide at least the following information:
* Your OS an...<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Affected version
<!--
Provide at least the following information:
* Your OS and version
* Affected GNOME Calendar version
-->
Fedora 39
GNOME Calendar 45.1
### Bug summary
<!--
Provide a short summary of the bug you encountered.
-->
When Scrolling through the calendar, fast scrolling will result in less area scrolled compared to slow scrolling in the same time.
This makes the app frustrating to use.
### Steps to reproduce
<!--
1. Step one
2. Step two
3. ...
-->
1. Scroll with a normal speed, as if you scrolled through a webpage, notice the view scrolling only by one line even though you scrolled an amount worth of more
2. Scroll slower, waiting for each animation cycle to finish before scrolling further, notice how now every scroll goes through
Or alternatively:
1. Place finger on scroll wheel
2. Scroll down fast
3. Scroll up slowly until your finger reaches the starting position again
4. Notice how the view is not at the starting position, but further up
### What happened
<!--
What did GNOME Calendar do that was unexpected?
-->
Fast Scrolling is slower than Slow Scrolling
### What did you expect to happen
<!--
What did you expect GNOME Calendar to do?
-->
Fast Scrolling is faster than Slow Scrolling
### Relevant logs, screenshots, screencasts etc.
<!--
If you have further information, such as technical documentation, logs,
screenshots or screencasts related, please provide them here.
If the bug is a crash, please obtain a stack trace with installed debug
symbols (at least for GNOME Calendar) and attach it to
this issue following the instructions on
https://wiki.gnome.org/Community/GettingInTouch/Bugzilla/GettingTraces.
-->
![Screencast_from_2024-03-15_21-28-25](/uploads/4e0bf8c03e411d3b3bfb7bc5a998e199/Screencast_from_2024-03-15_21-28-25.webm)
<!-- Do not remove the following line. -->https://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/1197EDS' "Data source does not support OAuth 2.0 authentication" error sometimes ...2024-03-15T14:04:07ZMichael CatanzaroEDS' "Data source does not support OAuth 2.0 authentication" error sometimes prevents seeing any Google Apps for Enterprise calendarsI'm unable to access any of my Google calendars in gnome-calendar-46~beta-2.fc40. It's as if the calendars are just not there: GNOME Calendar does not display any warning or error message of any sort in the UI (#17). The Google account i...I'm unable to access any of my Google calendars in gnome-calendar-46~beta-2.fc40. It's as if the calendars are just not there: GNOME Calendar does not display any warning or error message of any sort in the UI (#17). The Google account is configured using gnome-online-accounts.
```
(gnome-calendar:39093): GcalManager-WARNING **: 10:19:39.553: source_credentials_required_cb: Failed to authenticate 'mcatanza@redhat.com': Data source “mcatanza@redhat.com” does not support OAuth 2.0 authentication
```
That's strange because this is Google, which surely does support OAuth 2.0.https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1196Sidebar's calendars list popup can make it difficult to distinguish some cale...2024-03-19T21:22:34ZShema Angelo VerlainSidebar's calendars list popup can make it difficult to distinguish some calendarsOn my calendar, I have two accounts, and the popup in the calendar that allows enabling/disabling calendars is very cramped. Furthermore, knowing which calendar belongs to which account is tough****. Look for example in the following scr...On my calendar, I have two accounts, and the popup in the calendar that allows enabling/disabling calendars is very cramped. Furthermore, knowing which calendar belongs to which account is tough****. Look for example in the following screenshot:
![Screenshot_from_2024-03-12_12-12-51_3](/uploads/c2055903cc0dfc893bbc3a590392c980/Screenshot_from_2024-03-12_12-12-51_3.png)
The calendar above shows two copies with similar names for "Holidays in Rwanda" and "Birthdays". It is tough to know to which account each calendar belongs.
I think the solution would be to show sections in the popover for each account. A separator can separate each section to show they are from a singular account, and each section may have a title corresponding to the calendar name.https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1193Calendar does not provide the "reason" for why it keeps running in the backgr...2024-03-20T02:48:16ZJeff FortinCalendar does not provide the "reason" for why it keeps running in the backgroundI just discovered that apps like Pika state the reason why they remain as a portalled background process (ex: "Monitoring Backup Schedule").
It would be pretty cool if GNOME Calendar could do the same:
![image](/uploads/f321405da576f0...I just discovered that apps like Pika state the reason why they remain as a portalled background process (ex: "Monitoring Backup Schedule").
It would be pretty cool if GNOME Calendar could do the same:
![image](/uploads/f321405da576f099d50e3a3873ea4220/image.png)
What should the stated reason be? Other than instant-show performance, is it needed for being able to play and show reminder alarms/notifications, or EDS / GNOME Shell takes care of those for us? (presumably not until https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/155)
For setting the status message, it seems we need to use the `SetStatus` function in https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.Background.htmlhttps://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/1191UI Issues with the New Calendar dialog2024-03-07T23:43:23ZSam Hewittsnwh@gnome.orgUI Issues with the New Calendar dialogEven though there's plans to revamp these dialogs in #1037, I went through to spot issues with the status quo that could probably be fixed/improved in the meantime or be on the brain to address in the revamp.
### New Calendar Dialog
![...Even though there's plans to revamp these dialogs in #1037, I went through to spot issues with the status quo that could probably be fixed/improved in the meantime or be on the brain to address in the revamp.
### New Calendar Dialog
![image](/uploads/e10e902e3f84d8d07b8d0a69f640bf36/image.png)
- the dialog doesn't resize to new content and can't be manually resized resulting in a scroll window
- there is no close button on the New Calendar subpage
- the title of the subpage is incongruous with the "Add Calendar..." button, i.e. it should probably be "Add Calendar" instead of "New Calendar"
- there is no gap between the "Import a Calendar" title and the text below
- there is no feedback that Calendar is doing something after pasting the link from a web calendar to import, just a short pause before the add button is made sensitive
- The entry for the link should probably become insensitive temporarily while calendar processes the link and display a progress spinner
- there is no clear button to remove the link from the entry
- opening a calendar from a file is added automatically and isn't staged like a web calendar
- the automatic adding doesn't let a user change the calendar name or color if they wish and hit Add themselves
- if they didn't set the name in the first step they get a name generated from the file
- there's no way change the file in case they picked the wrong one, they'd have to remove the calendar first and add a new one
### Edit Calendar Dialog
![image](/uploads/c173731c2a7fdcac726a3554df8e2849/image.png)
- no window title or close buttonhttps://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/1189Prompt for confirmation about discarding / saving unsaved changes when exitin...2024-03-04T17:18:14ZJeff FortinPrompt for confirmation about discarding / saving unsaved changes when exiting the Event Editor dialogAs per discussion with @theevilskeleton and others, it probably makes sense to show a confirmation dialog in this situation.
Sort of depends on the UI cleanup proposed in https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1168#note_...As per discussion with @theevilskeleton and others, it probably makes sense to show a confirmation dialog in this situation.
Sort of depends on the UI cleanup proposed in https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1168#note_2038316
Prior art for @snwh @philippsauberz @bertob's consideration, in case we need to do anything special here:
| Evolution | GNOME Text Editor |
| - | - |
| ![evo_unsaved_changes](/uploads/d1066eb63a32b0b7a5a2fd70d4d995d6/evo_unsaved_changes.png) | ![text_editor_unsaved_changes](/uploads/04e9c9730f29db050f27318621128800/text_editor_unsaved_changes.png) |
My impression is that we could straightforwardly clone Evolution's dialog, but in the visual styling of Text Editor's dialog.https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1188Google Meet videoconferencing event metadata in description does not get cut ...2024-03-04T23:12:39ZJeff FortinGoogle Meet videoconferencing event metadata in description does not get cut out at the correct separator location for popover and details tooltipIf you have a Google Calendar event with built-in Google Meet link stuff, roughly like this:
```
Hello,
After this meeting, you will say that this meeting could have been an email.
Blah blah blah, blah blah blah blah blah blah blah bl...If you have a Google Calendar event with built-in Google Meet link stuff, roughly like this:
```
Hello,
After this meeting, you will say that this meeting could have been an email.
Blah blah blah, blah blah blah blah blah blah blah blah blah blah blah blah blah blah
blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah.
Thanks
-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-
Join with Google Meet: https://meet.google.com/abc-defg-hij
Or dial: (CA) +1 613-916-8351 PIN: 000000000#
More phone numbers: https://tel.meet/abc-defg-hij?pin=000000000&hs=7
Learn more about Meet at: https://support.google.com/a/users/answer/9282720
Please do not edit this section.
-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-
```
Then GNOME Calendar's `gcal_utils_extract_google_section` function (in `gcal-utils.c`) tries to parse that junk, and _mostly_ gets it right, except that there is some leftover cruft in the resulting contents of the event preview popover and event tooltip, and the exact amount of cruft varies from one event to another:
| Event popover feat. `\n\n-:` | Tooltip feat. `\n\n-::~:~::~:~:~:~:~:~:~:~:~:~` (ellipsized) |
| - | - |
| ![image](/uploads/8feb54b63a7e223e1f882f9b5f0260e5/image.png) | ![image](/uploads/c188f0d1e994e0cf7243017dd8f42067/image.png) |
| Event popover feat. `\n\n-` | Tooltip feat. the full separator + "Join with Google" |
| - | - |
| ![image](/uploads/c7a6598b89ae4e73aea210372ad40045/image.png) | ![Screenshot_from_2024-03-04_17-46-45](/uploads/7fbb722ecaee4ce5023811cc37799e35/Screenshot_from_2024-03-04_17-46-45.png) |
It is strange/suspicious that the cutoff happens differently depending on whether it is shown in the tooltip vs the popover, differently from one event to another, on the same machine…
Note that for testing purposes, you really need to create a Google Calendar "with Google Meet" event, somehow it is impossible to paste the example content text above into a new calendar event from within GNOME Calendar or Evolution…https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1187Offer GNOME Shell dash app launcher menu actions for creating or importing an...2024-03-07T23:30:31ZJeff FortinOffer GNOME Shell dash app launcher menu actions for creating or importing an eventSome apps like Builder, Evolution, Firefox, Epiphany and Ptyxis have custom menu actions available from their desktop launcher:
![image](/uploads/5e472d0fc12a6ee20ef82792701c6680/image.png)
While not critical to have, it would be a nea...Some apps like Builder, Evolution, Firefox, Epiphany and Ptyxis have custom menu actions available from their desktop launcher:
![image](/uploads/5e472d0fc12a6ee20ef82792701c6680/image.png)
While not critical to have, it would be a neat integration feature if GNOME Calendar offered actions for:
* "Add Event" (directly opens the full Event Editor dialog, same as the "+" button in the toolbar)
* "Import Events from File" : this would open a file chooser portal (with filtered mimetypes, and probably pre-set to the XDG downloads folder) that would then throw the result at the `import-dialog` module, replacing the feature that was previously mis-placed in the Manage Calendars dialog (#390) and that needs to find a new home (#255)
In terms of implementation, this seems to be mostly a combination of .desktop file properties tied to commandline arguments/parameters, and then tying this together with the backend+GUI of GNOME Calendar. For example, GNOME Builder's .desktop file contains, among other things:
```
Actions=new-window;create-project;clone-repo;new-editor;dspy;
[Desktop Action new-window]
Name[ca]=Obre un projecte
Name[cs]=Otevřít projekt
Name[da]=Åbn et projekt
Name[de]=Ein Projekt öffnen
Name[el]=Άνοιγμα έργου
Name[en_GB]=Open a Project
(blah blah blah)
Name=Open a Project
Exec=gnome-builder --greeter
[Desktop Action create-project]
Name[ca]=Comença un projecte nou
Name[cs]=Začít nový projekt
Name[da]=Start nyt projekt
Name[de]=Neues Projekt beginnen
Name[el]=Έναρξη νέου έργου
Name[en_GB]=Start New Project
(blah blah blah)
Name=Start New Project
Exec=gnome-builder --create-project
```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/1184Meeting invitation .ics event importer should visually differentiate invisibl...2024-03-01T05:16:00ZJeff FortinMeeting invitation .ics event importer should visually differentiate invisible calendars among possible choicesSame as in the event editor dialog: it should still be possible to import a .ics event into a calendar that is not currently visible/shown/displayed in the main window's views, but we should make that clear visually.Same as in the event editor dialog: it should still be possible to import a .ics event into a calendar that is not currently visible/shown/displayed in the main window's views, but we should make that clear visually.GNOME 47Jeff FortinJeff Fortinhttps://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/1180Focus grabbing by the Title (summary) field in the Event Editor breaks the Es...2024-03-07T23:54:37ZJeff FortinFocus grabbing by the Title (summary) field in the Event Editor breaks the Escape keyboard shortcut for read-only events after viewing a writable eventWhile testing another (completely unrelated) branch now, I have found a small hard-to-spot regression introduced by @theevilskeleton's !421, present in `main`, that occurs in some very specific order of steps:
1. Open the event editor f...While testing another (completely unrelated) branch now, I have found a small hard-to-spot regression introduced by @theevilskeleton's !421, present in `main`, that occurs in some very specific order of steps:
1. Open the event editor for a writable event
2. Press `Escape` to close the event editor
3. Open the event editor for a read-only event
4. Try to press `Escape` to close the event editor
Result: nothing happens, because the focus is on the Title widget (which is insensitive) instead of the window.
Workaround: you can press `Tab` to change the focused widget in that window, which makes `Escape` work again.
Expected result: `Escape` should still work.
I think that in the specific case of read-only events, focus could be set on the `Done` button instead (because other than the lock icon, I think the Done button is the only widget that is going to remain sensitive after !419; testing with that MR right now, I also see that pressing `Tab` in this situation leads to the "Done" button getting focused first anyway).GNOME 47Jeff 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)