gnome-calendar issueshttps://gitlab.gnome.org/GNOME/gnome-calendar/-/issues2024-03-05T07:41:13Zhttps://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/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/1171Consider searching event descriptions (not just summaries titles)2024-02-21T20:13:34ZJeff FortinConsider searching event descriptions (not just summaries titles)Looking at [gcal-shell-search-provider.c](https://gitlab.gnome.org/GNOME/gnome-calendar/-/blob/main/src/core/gcal-shell-search-provider.c)'s code, it seems our GNOME Shell search provider searches not only the events summaries (titles) b...Looking at [gcal-shell-search-provider.c](https://gitlab.gnome.org/GNOME/gnome-calendar/-/blob/main/src/core/gcal-shell-search-provider.c)'s code, it seems our GNOME Shell search provider searches not only the events summaries (titles) but also the descriptions:
```c
search_query = g_strdup_printf ("(or (contains? \"summary\" \"%s\") (contains? \"description\" \"%s\"))",
self->pending_search->terms[0],
self->pending_search->terms[0]);
for (i = 1; i < g_strv_length (self->pending_search->terms); i++)
{
g_autofree gchar *complete_query = NULL;
g_autofree gchar *second_query = NULL;
second_query = g_strdup_printf ("(or (contains? \"summary\" \"%s\") (contains? \"description\" \"%s\"))",
self->pending_search->terms[0],
self->pending_search->terms[0]);
complete_query = g_strdup_printf ("(and %s %s)", search_query, second_query);
g_clear_pointer (&search_query, g_free);
search_query = g_steal_pointer (&complete_query);
}
```
…whereas the search button's code in [gcal-search-button.c](https://gitlab.gnome.org/GNOME/gnome-calendar/-/blob/main/src/gui/gcal-search-button.c) looks only at the summaries:
```c
sexp_query = g_strdup_printf ("(contains? \"summary\" \"%s\")", text);
```
Once we take care of the issues listed further below, it _might_ be desirable to provide the ability to search "descriptions" too. However, this would bring up not only performance considerations, but also information management and design considerations.
This ticket is more of a "what if" idea and Request for Comments, not something for the short-term. It might fit into George's vision to switch from EDS to Tracker (or to switch _EDS to Tracker,_ see also https://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/307), but personally I have concerns about depending on Tracker for all this, as for me EDS has been a very reliable zero-problems workhorse for the past 20 years.
---
Some preliminary UX design questions to consider:
* How to present the ability to toggle between full text search vs "restricted to event summaries (titles)"? A filter button+popover like in Nautilus' searchbar?
* Should the UI offer auto-expanding the search fields (i.e. "Search Everywhere") and time range, when not enough results are found? (or that they are instantly found, but there are too many to reasonably display)
* Should there be a visual separation of summary-only matches (first / above) vs summary-and-description matches (below, as secondary results)?
* Should it allow some sort of advanced search syntax or filtering (ex: meetings with certain attendees or senders, or near a certain location; declined/accepted/tentative/undecided meeting invitations?)
---
Before implementing and testing this potential feature, I believe it would depend on these:
1. Search delay trick to avoid wasteful queries / avoid spamming the search backends: https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1170
1. Not accidentally having "leftover" intermediate search results: https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/989
1. Ability to do unordered search queries: https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1169
1. Having a UI design proposal for a way to let the user choose between searching titles only vs searching titles and descriptions
Somewhat related consideration: https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/624https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1131Register GNOME Calendar as a webcal:// URI protocol handler for web browsers,...2024-03-07T23:33:12ZJeff FortinRegister GNOME Calendar as a webcal:// URI protocol handler for web browsers, and parse commandline arguments to preconfigure the "New Calendar" dialog with the URIUsing the [GNOME releases schedule/calendar page](https://release.gnome.org/calendar/) as a test case, which contains [this webcal link](webcal://www.gnome.org/start/unstable/schedule.ics), this is what happens when you click the webcal ...Using the [GNOME releases schedule/calendar page](https://release.gnome.org/calendar/) as a test case, which contains [this webcal link](webcal://www.gnome.org/start/unstable/schedule.ics), this is what happens when you click the webcal link in Firefox:
![webcal_prompt_from_Firefox](/uploads/f8c28b5e26ebee20c925c4c0fb349237/webcal_prompt_from_Firefox.png)
If you click it with Epiphany 45, it opens Evolution's calendar registration dialog directly without asking:
![image](/uploads/a8e703e7030ae6b6121c848a52bf31f9/image.png)
Now the open questions to investigate are:
* Would it make sense to have GNOME Calendar as a `webcal://` protocol/URI handler for web browsers? (probably, for computers where Evolution is not installed...)
If so, how is this achieved? Probably @mcrha might have a hint, though I wonder if the game is changing with portals nowadays.
* Can that be done with Calendar's existing GUI dialogs & technologies, or this would still need to create a bunch of new dialogs? (I'm hoping it could just reuse/pre-set the existing "Add calendar..." dialog?
* Will this require some extra GUI work in Epiphany? @mcatanzaro might have an opinion here.
I'm guessing this might be either a super trivial self-contained thing to implement (i.e. newcomers-friendly)… or an epic with fixes needed in various other places. From an implementation standpoint, Georges doesn't know yet what it would entails until we try (or gather more info here).https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1127pkpass (boarding passes and events tickets QR codes) import2023-11-24T18:51:29Zjohannesjhpkpass (boarding passes and events tickets QR codes) import### It would be nice to be able to open and import `.pkpass` boarding passes using GNOME calendar
Background and motivation: When I check in for a flight, I get sent an email with a `.pkpass` attachment. The .pkpass file is a digital bo...### It would be nice to be able to open and import `.pkpass` boarding passes using GNOME calendar
Background and motivation: When I check in for a flight, I get sent an email with a `.pkpass` attachment. The .pkpass file is a digital boarding pass. The boarding pass contains information about my flight, such as the date, time, flight number, location etc. It is possible to import the boarding pass as an event into a calendar. For example, the [passandroid](https://play.google.com/store/apps/details?id=org.ligi.passandroid) app allows to export and save the boarding pass into an android calendar.
Feature suggestion for GNOME calendar: It would be nice if GNOME calendar could open and import .pkpass files.
### How would you like it to work
Similar to how GNOME calendar is registered as an application that can open .ics files, i.e., GNOME calendar could register as an application that can open .pkpass files. When opening a .pkpass file, GNOME calendar could show the same dialog as when importing an .ics file.
### Relevant links, screenshots, screencasts etc.
**passes:**
EDIT: thank you for pointing out this app in the comments below!, I added it here to provide a better overview
The [Passes](https://flathub.org/apps/me.sanchezrodriguez.passes) app is available on flathub; it allows to open and view .pkpass files. Judging from my quick test, I don't think it registers as an app that handles `*.pkpass` files, and it does not include functionality for exporting a pass to the calendar.
**passandroid:** screenshot from the passandroid. the screenshot shows a .pkpass boarding pass. the green highlighted area in the screenshot shows the button for saving the boarding pass as an event in android's calendar. note, I grayed out personal information such as my name and the qr code.
![signal-2023-11-23-075343_002](/uploads/a2a5a6cdc542d473e187ba6e3c381dfb/signal-2023-11-23-075343_002.jpeg){height=400px}
<!-- Do not remove the following line. -->https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1114Provide easily copy-pastable bug reporting information in the About dialog, w...2024-02-20T06:29:42ZJeff FortinProvide easily copy-pastable bug reporting information in the About dialog, with version numbers of libraries it most depends onTo make it easier for casual testers to make better bug reports in GNOME Calendar or elsewhere (ex: when we find a bug in GTK), GNOME Calendar's about dialog should provide its version numbers for the most critical libraries it depends o...To make it easier for casual testers to make better bug reports in GNOME Calendar or elsewhere (ex: when we find a bug in GTK), GNOME Calendar's about dialog should provide its version numbers for the most critical libraries it depends on:
* GTK
* LibAdwaita
* Evolution Data Server
* GNOME Online Accounts
* libsoup
And whether the user is running on GNOME or not, on Wayland or not, etc.
There are of course various other libraries mentioned in the [dependencies](https://gitlab.gnome.org/GNOME/gnome-calendar/-/blob/main/meson.build), but compared to the ones mentioned above, they usually don't cause much trouble.
[Tuba](https://tuba.geopjr.dev/) is an example of an application that provides a nice convenient UI for this in its About dialog:
![image](/uploads/6f1daee996b6a41f5761cd9078272b84/image.png) ![image](/uploads/e01268ebabfb7ec24d670bf90e008640/image.png)GNOME 46Felipe KinoshitaFelipe Kinoshitahttps://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1112Support for event categories2023-10-27T17:15:00ZSebastian KutterSupport for event categories<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Feature summary
<!--
Describe what you would like to be able to do with GNOME...<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Feature summary
<!--
Describe what you would like to be able to do with GNOME Calendar
that you currently cannot do.
-->
Many Calendar apps and backends support categories for events (Evolution included).
I would wish for gnome-calendar to support categories
### How would you like it to work
<!--
If you can think of a way GNOME Calendar might be able to do this,
let us know here.
-->
1. In the settings for a specific calendar, there should be a way to manage categories. Each category should include a name and a color.
2. Within an event, there should be a ComboRow. The ComboRow should spawn a Popover with one row for each category. Each row should consist of a colored circle on the left and the category name on the right.
### Relevant links, screenshots, screencasts etc.
<!--
If you have further information, such as technical documentation,
code, mockups or a similar feature in another desktop environments,
please provide them here.
-->
<!-- Do not remove the following line. -->https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1074"Zigzag" month boundaries separation line for the new month view2024-01-27T16:18:18ZJeff Fortin"Zigzag" month boundaries separation line for the new month view## Context / problem
Following up on #603, considering that the month view in 45.x+ is now an infinite multi-weeks view that allows moving up and down, I believe that one of the best ways to make it easy to spot the delimitations betwee...## Context / problem
Following up on #603, considering that the month view in 45.x+ is now an infinite multi-weeks view that allows moving up and down, I believe that one of the best ways to make it easy to spot the delimitations between calendar months as you are scrolling is to rip out the month names' from the header above the view (#934) and embed them directly in the cell of the 1st day of each month (#962).
This is easily done, however we run into the problem of trying to make the month name labels easy to spot visually. We could still use very bold fonts and some color (like the old month name labels in the header), but we probably couldn't use larger font sizes than the cell's day number text, because that would probably cause the line height to vary compared to other cells. So we can probably only use bold + color, like this:
![image_2_](/uploads/f33e2c4e411670eed0b3e8cc9b5a77ff/image_2_.png)
There is some shading on the background color of the cells for "the months before/after the currently focused month" (i.e. weeks at the top and bottom of the view), however that effect is very subtle.
## Proposed improvement
I think that a solution to make the visuals "easy to spot" would be combining the two existing aspects (bold+colored month name in the 1st day's cell, + shaded cell backgrounds) with a third visual aspect: a hard border style that separates the months, what I call the "zigzag line".
If we do a border style that separates the cells of the previous vs current (and current vs next) month, then the month name's font size becomes less of an issue because you then have three combined visual indicators helping your eyes spot the boundaries between months as you scroll.
Various other apps out there have taken this visual approach, here's one example:
![fantastical3_month_view](/uploads/2e05e0b107ed29fbe10dd44dbcd0bbd8/fantastical3_month_view.png)
### Possible implementation
Maybe the cells in the month view's C code could dynamically set/unset 4 additional CSS classes, with these simple properties, effectively causing a zigzagging border line to be created in practice:
* `.day_in_month_last_row { border-bottom: 1px solid; }`
* `.last_day_of_month { border-bottom: 1px solid; border-right: 1px solid; }`
* `.first_day_of_month { border-left: 1px solid; border-top: 1px solid; }`
* `.day_in_month_first_row { border-top: 1px solid; }`
...maybe this needs to be multiplied by two for right-to-left languages orientation (if GTK doesn't do it automagically for us), but otherwise, it might be sufficient?
### Possible caveats (to test)
We don't know if this might "just work", or if it might cause a combinatorial explosion in CSS matching or something like that.GNOME 46Hari Ranatheevilskeleton@riseup.netHari Ranatheevilskeleton@riseup.nethttps://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1070Make the sidebar / agenda view an infinite scrolling timeline ListView (inste...2024-03-27T18:06:14ZJeff FortinMake the sidebar / agenda view an infinite scrolling timeline ListView (instead of the "current day until Sunday" limitation)Presumably not terribly hard to implement, but not urgent, and the current behavior was hard to guess, so I'm filing this issue for reference, in case someone would like to work on it.
# Current problem / symptoms
Barring [sidebar bugs...Presumably not terribly hard to implement, but not urgent, and the current behavior was hard to guess, so I'm filing this issue for reference, in case someone would like to work on it.
# Current problem / symptoms
Barring [sidebar bugs](https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/?label_name%5B%5D=Sidebar), the current scope / way the sidebar filters events (with the initial implementation @aplazas did in version 43) can be a bit confusing in practice, whether you are using it on the desktop or a portrait-oriented mobile phone. Currently, it seems that the scope of "events that do or do not get shown in the sidebar" is based on the combination of two things:
* The currently selected day in the mini calendar, AND
* The week of the selected day in the minicalendar (until Sunday only)
The fact that it shows only events "after that day, but only up to Sunday of that particular week" is weird and limiting. In practice, the list keeps shrinking in scope as you progress forward every day of the week, until you go past Sunday into Monday, and then the list gets filled up again with events of the next week.
In addition to the above, there are specific bugs that make the sidebar's contents selection & organization fall apart, currently: #898, #936, #968, #994 for instance.
From a broader perspective, it currently behaves in a way where no formfactor is well-served (the contents are redundant with the infinite month view in desktop mode, while not providing an infinite linear view in mobile phone mode). It seems @bertob also feels like we'd probably want different sidebar behavior on mobile (e.g. a full list below the mini calendar?) but then this probably means we need design clarification on this alongside with #1007 (see the "outstanding design question" below).
# Proposed technical solution (mobile and desktop)
To fix at least the weird scope/filtering part, I would suggest that:
* The sidebar's backend gets reworked to have the same "infinite scrolling" architecture as the New Month View (#603) introduced in version 45
* It filters to "Current day + 7 days" by default (scrolling/swiping/keypressing further up/down would enlarge the scope as needed), without the limitation of the "end of the week" that the current implementation has. i.e. no week boundaries, only number-of-days limits for performance.
In this case here, it'd probably be much easier than #603 was, because it's the sidebar/agenda/schedule is completely linear and less things are shown at once.
Technically, to solve the "minimal" portion of the issue, you could address only the 2nd point above, but ideally, might as well address both points at the same time, as it might be nicer to have the infinitely scrollable view there too.
# Outstanding design question (desktop)
Independently of the outcome of this ticket, there is the question of what to do with the sidebar on the wide desktop formfactors/breakpoints, because as it stands currently it is mostly just adding visual clutter.
The alternative I can see is, "Never show the sidebar in desktop mode; move its navigational widgets back into the main view's headerbar while in desktop mode" (i.e. treat it as a portrait-mobile-only view), but I don't know if that's the best solution.
It would be much better if, instead, it could provide information that doesn't simply duplicate a portion of what I already have in the Month (aka multi-week) or Week (aka multi-days / timetable) view... sure, if it was just me, I'd hide the sidebar entirely in desktop mode (like we probably should in some breakpoints like in #1007), but I suppose other people might have different needs than me on that front, so can we find a way to give it a particularly useful function on the desktop?https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1064Configurable amount of rows in the grid for the new Month view, and columns i...2024-02-16T00:48:04ZJeff FortinConfigurable amount of rows in the grid for the new Month view, and columns in the Week viewThis is part of issue #603, and supersedes issue #1.
# Problem statement
A hardcoded 5-weeks row arrangement for the new month view cannot be expected to fit all situations and all user's workstyles (and similarly, a hardcoded 7-days/c...This is part of issue #603, and supersedes issue #1.
# Problem statement
A hardcoded 5-weeks row arrangement for the new month view cannot be expected to fit all situations and all user's workstyles (and similarly, a hardcoded 7-days/columns width for the week view can be similarly problematic). It would be desireable for this to eventually be configurable somehow, because:
* Not all my computer monitors have the same available vertical space real estate (ultrawide, small laptop screens, etc.)
* You might decide to use Calendar on a portrait-oriented vertical screen, at 1080x1920 for example, and then "only" 5 rows becomes not dense enough when you could easily fit 7 to 10 rows...
* Personally, I have _so many_ events per day, that most of the month view's cells trigger the "overflow popover" thing even with the currently hardcoded "5 week rows in the month view" default... and yet in practice most of the time I don't want/care to view more than 3 or 4 week rows at a time. But sometimes when planning across two months, I might switch to 5 to 7+ weeks view... it's very situational.
# Possible UX approaches
Here are some potential ways I think this could be made configurable, in terms of UX:
* The height / number of rows (or width / number of columns, in the case of weekview) shown on screen could be adjusted with pinch zoom and ctrl+scroll (like the height of the timetable can currently be adjusted in the existing week view)
* This could also be configurable through a visible GUI element in one or two locations:
* Right-clicking (or long-pressing, on touch devices) the "Month" view (and "Week" view) switcher button in the headerbar would reveal a popover (or menu, or whatever) that would show the widgets to configure this (ex: a spinbutton for the number of desired rows). This is what Fantastical does, I haven't checked other apps to see if they do the same thing.
* In the main menubutton. But I don't know if Georges would be happy with that location. It has the advantage of being much more discoverable than something requiring a right-click/longpress on the view switcher buttons, though.
* As a third way, it could also be possible to adjust by dragging a multi-week range in the sidebar's minicalendar, as shown in [this video demonstrating that feature in Evolution's calendar](https://www.youtube.com/watch?v=Z4Y9D_287wM), which also works for the weekview. However this has two caveats:
* it would not make it possible to set a range bigger than 5 weeks (which would be useful for portrait-oriented computer monitors) unless more than one minicalendar month is shown in the sidebar;
* it depends on the presence of the sidebar (which contains the minicalendar), which may not be guaranteed if #1007 ends up removing the sidebar in some screen breakpoints.
Notes:
* A possible replacement for a spinbutton could be to have a submenu with choices, but I don't see the point in restricting the number arbitrarily.
* In the future, the week view (when it eventually becomes "infinite") would need not only configurable number of days (columns) shown, but also configurable number of hours per day (for issue #10), so that one would need two UI settings...
I'd love to have @teams/design's thoughts on how to expose and visually present that configurability.https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1061Implement keyboard navigation & operations in the new month view's grid2023-11-29T16:14:55ZGeorges Basile Stavracas NetoImplement keyboard navigation & operations in the new month view's gridJeff's initial ideas of keyboard shortcuts that should be used when the view is focused (or nothing in particular is focused):
* `Up`/`Down` arrow to go from one week to another in the new month view (with feedback animation: #1065)
* `...Jeff's initial ideas of keyboard shortcuts that should be used when the view is focused (or nothing in particular is focused):
* `Up`/`Down` arrow to go from one week to another in the new month view (with feedback animation: #1065)
* `PgUp` / `PgDown` (already implemented) and Shift+scrollwheel (#1072)
* `Left`/`Right` to go from one month view's cell to another, i.e. previous/next day (even across weeks; pressing `Right` on day 7 should probably lead to next week's day 1)
Other accessibility-related keyboard shortcuts for making selections and operations within the cells: we need some guidance on what needs to be done there.https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1045Add shortcut for the "Calendars" menu2023-08-05T17:11:33ZHari Ranatheevilskeleton@riseup.netAdd shortcut for the "Calendars" menuCurrently, there is no shortcut for the "Calendars" menu,[^1] which is difficult to acticate it using a keyboard (`F10` -> `Esc` -> `Shift`+`Tab`). As discussed in Matrix, we should explore a shortcut that would make it easy to activate ...Currently, there is no shortcut for the "Calendars" menu,[^1] which is difficult to acticate it using a keyboard (`F10` -> `Esc` -> `Shift`+`Tab`). As discussed in Matrix, we should explore a shortcut that would make it easy to activate it. We are thinking of using F8.
[^1]: ![image](/uploads/f4771b68344d325eeacf12ba981ceb62/image.png)GNOME 45Hari Ranatheevilskeleton@riseup.netHari Ranatheevilskeleton@riseup.nethttps://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1025Add a way to show how long until an event2023-08-01T04:20:15ZNokseAdd a way to show how long until an event<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Feature summary
A label with the amount of time until an event starts maybe whe...<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Feature summary
A label with the amount of time until an event starts maybe when you click on an event
<!--
Describe what you would like to be able to do with GNOME Calendar
that you currently cannot do.
-->
### How would you like it to work
Show the number of days/hours until the event
<!--
If you can think of a way GNOME Calendar might be able to do this,
let us know here.
-->
### Relevant links, screenshots, screencasts etc.
<!--
If you have further information, such as technical documentation,
code, mockups or a similar feature in another desktop environments,
please provide them here.
-->
<!-- Do not remove the following line. -->https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1023Provide a shortcut in the hamburger menu linking to GNOME Control Center's "D...2023-11-09T17:14:53ZJeff FortinProvide a shortcut in the hamburger menu linking to GNOME Control Center's "Date & Time" settings panelIn order to be able to set global preferences such as:
* The first day of the week (#160)
* Toggling week numbers on/off in mini calendars (#1022 for context)
* The home timezone, and 24-hour vs AM/PM format
...and sharing the effects ...In order to be able to set global preferences such as:
* The first day of the week (#160)
* Toggling week numbers on/off in mini calendars (#1022 for context)
* The home timezone, and 24-hour vs AM/PM format
...and sharing the effects with GNOME Shell's calendar etc., and avoiding adding too many preference UIs to GNOME Calendar, there should be a quick and discoverable way for users to go to the "Date & Time" settings. This could be an action in GNOME Calendar's main hamburger menu, with a separator, like this:
```
Date & Time settings… 👈🏽
Online Accounts…
Weather >
----------------------
Keyboard Shortcuts
About Calendar
```
The backend code for this action could probably be inspired by the backend code that is triggered by the LinkButton in the "Manage Calendars…" dialog's "Add Calendar…" dialog (or whatever it becomes after the changes to #566, if that happens first).GNOME 45Victoria LacroixVictoria Lacroixhttps://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1013Feature request: add an option to display past events on the event list2023-08-18T01:47:10ZAdam MadaFeature request: add an option to display past events on the event list<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Feature summary
In some use cases it would be handy to be able to display past...<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Feature summary
In some use cases it would be handy to be able to display past events on the event list (on the left panel, under the calendar widget).
### How would you like it to work
User should be able to specify a certain number of days in the past that are needed to be included on the listing (preferences/settings/etc.)
Past events would be displayed only in case today is selected (I think that displaying them relative to any selected date would greatly decrease readability).
Probably making them a little dimmed would be nice.
### Relevant links, screenshots, screencasts etc.
<!--
If you have further information, such as technical documentation,
code, mockups or a similar feature in another desktop environments,
please provide them here.
-->
<!-- Do not remove the following line. -->GNOME 45https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1011Add custom recurrence options for reminders and events2023-04-22T01:59:56Zcorey drew bruceAdd custom recurrence options for reminders and events<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Feature summary
More custom options repeat reminders meaning you can pick mult...<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Feature summary
More custom options repeat reminders meaning you can pick multiple day, month or years instead of being stuck and limited with the default 1 day, month or year.
### How would you like it to work
Give us a custom option after the default repeat times so we can set custom times.
### Relevant links, screenshots, screencasts etc.
![image](/uploads/3f226fb022ee17776d333655f1e15abb/image.png)
I did notice this 2022 roadmap https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/965 But sadly nothing has been added yet so I really hope this feature gets added as it makes Google calendar a bit limited to use as I need custom times for my developing events and reminders.
<!-- Do not remove the following line. -->https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/998Gregorian/non-Gregorian calendar integration dual usage support2023-12-10T20:54:32ZYosef Or BoczkoGregorian/non-Gregorian calendar integration dual usage support### Feature summary
I want an option to see the Hebrew Calendar integrated with the Gregorian Calendar.
In practice:
1. To see the month in Hebrew-Calendar beside Gregorian-month.
1. To see the day in the Hebrew-Calendar beside Gregori...### Feature summary
I want an option to see the Hebrew Calendar integrated with the Gregorian Calendar.
In practice:
1. To see the month in Hebrew-Calendar beside Gregorian-month.
1. To see the day in the Hebrew-Calendar beside Gregorian-day.
### How would you like it to work
The libhdate-glib library should do the most of the work.
The question is how to add this feature - as a plugin or builtin?
### Relevant links, screenshots, screencasts etc.
Google Calendar for example:
| In English UI | In Hebrew UI |
| ------ | ------ |
| ![google-calendar-english](/uploads/b8ea937aa5c4e154578db41f8a194560/google-calendar-english.png) | ![google-calendar_hebrew_dates](/uploads/dc3da5842c77d350404aba9c7f80d83a/google-calendar_hebrew_dates.png) |
Another example (Hebrew only):
![rotter-calendar](/uploads/79cc8a306bf383c2e849cdaece387992/rotter-calendar.png)
<!-- Do not remove the following line. -->https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/958Add local note on readonly remote webcal2023-09-18T20:14:12ZPHHENSAdd local note on readonly remote webcal<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Feature summary
<!--
Describe what you would like to be able to do with GNOME...<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Feature summary
<!--
Describe what you would like to be able to do with GNOME Calendar
that you currently cannot do.
-->
### How would you like it to work
It would be nice to add the ability to complete a remote readonly webcal event with a
local stored note.
As an example, in a student timetable given in a remote webcal, he could complete
the event "mathematic course" with a note like "don't forget to take the red copybook".
Thanks for understanding this need.
<!--
If you can think of a way GNOME Calendar might be able to do this,
let us know here.
-->
### Relevant links, screenshots, screencasts etc.
<!--
If you have further information, such as technical documentation,
code, mockups or a similar feature in another desktop environments,
please provide them here.
-->
<!-- Do not remove the following line. -->