elementary
display event over multiple days as one object
like every other application does, for example Apple Mail.
Launchpad Details: #LP1417158 davidak - 2015-02-02 16:03:30 +0000
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
This would be a HUGE quality of life improvement. But having written a blocking system for a calendar myself (buisiness, so I'm sadly not allowed to duplicate this work in FOSS) I know it's a bit tricky to:
- calculate the overlapping (to be able to have non-overlapping events on the same row/column)
- calculate the position in the stack for all blocks on the same overlap (to stack overlapping events in their column/row)
- check constraints and limits (like "max 3 multi-day-events")
- apply vertical or horizontal layout
But no rocket science at all. I wish I could help more. Darn...
One hint: I found that, if you do the above correctly and store very few state and position informations in event objects, you can use the same logic for basically any layout that requires you to display blocks of events (day, week, all-day, multi-day, multiple-all-day, ...). Just in one case you (whoever will take a look at this) need to look at the time and in the other case you only need the date.
Launchpad Details: #LPC Timo Reimerdes - 2015-06-23 07:24:52 +0000
From #261
It looks like other apps/services like Google Calendar and GNOME Calendar distinguish them in a few ways:
- Multi-day events visually span multiple days instead of showing an individual item on each day. This also means they only how the even details on the first visible day, cleaning up some of the clutter.
- Timed (not all-day) events show less visually prominent, often with a color-coded dot or icon next to the text instead of a whole colored block around the text.
- The time of non-all-day events is often shown next to the event title if there's room, making the calendar more useful at a glance.
On mobile, Google Calendar is much more similar to our current implementation, likely due to being space constrained. So there's an argument for something a little more responsive/adaptive based on available space as well.
