[wip] Calendar application
Open, NormalPublic

Description

Calendar application which allows to,

  • Set reminders
  • View agenda

(though for 1.0 version reminders/agenda can be ignored)

For calender application, you may choose two different options:

Basic application would be kirigami application built around this libs.

Knowledge Requirements: Willing to learn Qt/QML, CMake.

System Requirements: You can develop this application on normal Linux system, and test it in native Linux system. If you want to test it on Plasma Mobile system, you can use actual Mobile device or Plasma Mobile x86 ISO in emulated environment.

Design Resources:

Development Resources:

bshah created this task.Sep 4 2017, 2:23 PM
bshah updated the task description. (Show Details)May 19 2018, 11:57 AM
bshah updated the task description. (Show Details)May 19 2018, 12:54 PM
bshah triaged this task as Normal priority.May 27 2018, 11:29 AM
dkardarakos updated the task description. (Show Details)Jun 26 2018, 4:38 PM
dkardarakos renamed this task from Calendar application to [wip] Calendar application.Aug 1 2018, 2:24 PM
dkardarakos claimed this task.

Here you can find the wip calendar work. Currently, it consumes plasma-framework calendar models. If possible, we may try to change model dependencies and create some kirigami calendar ui components.

Calendar tasks functionality added. VDG feedback is welcome.

Navigation

To add a new task:

  • Select a day

  • Open the context drawer

  • Select Add task
  • Populate the task fields in the FormLayout

  • Trigger either the Save or the Cancel action

To show existing tasks:

  • Select a day
  • Open the context drawer
  • Select Show tasks
  • The tasks of the selected day are displayed in a CardsListView


To edit or delete an existing task:

  • Select a day
  • Open the context drawer
  • Select Show tasks
  • The tasks of the selected day are displayed in the CardsListView
  • Trigger either the Edit or the Delete contextual action

Looks really nice already!
I'm not a designer, but I'd suggest making the calender fill the whole page.

The centered add task form also seems a little unfamiliar to me, I'd probably make it top aligned.

Apart from that, I like the design of the calendar "widget" itself.

pilee added a subscriber: pilee.Dec 1 2018, 6:22 PM

Project's code is now available at Calindori repository.

abetts added a subscriber: abetts.Jan 4 2019, 3:19 PM

If you want, you can go to the KDE VDG Channel and request some design help as you go along. The app is shaping up nicely.

Screenshots added, feedback welcome.

Great! :)
If you need visual feedback:

  1. Card names and date in the details view are misaligned
  2. The time picker looks a bit overwhelming, and I'm not sure how it would work with 24h format.

Android, for instance, does it this way:

I see that you are using KCalCore::Todo for storing tasks. For the usual calendar KCalCore::Event would be more suitable IMHO. Should we change that or would you rather support both types (TODOs and Events)?

I see that you are using KCalCore::Todo for storing tasks. For the usual calendar KCalCore::Event would be more suitable IMHO. Should we change that or would you rather support both types (TODOs and Events)?

I started with the implementation of VTODO instead of the VEVENT because I wanted to offer to-do functionality. According to my understanding of RFC 5545, you can create VTODO without dtstart, while it is normally required in VEVENT. So, this way we can add a to-do to a specific day while we can also offer a to-do list without setting starting dates (my plan is to offer this functionality in the global drawer). Also, I find the algorithm for setting the (optional) dtend of VEVENT as not optimal for a to-do (something that some apps impose for to-dos which IMO is an overkill). Instead, VTODO's "due" is suitable for to-dos - we could add it to the to-do page and, later, we could implement notifications on top of this.

Nevertheless, I think that we should implement VEVENT as well; it will be useful for several use cases and it will facilitate integration with calendars that implement it.

Great! :)
If you need visual feedback:

  1. Card names and date in the details view are misaligned

Not 100% sure about what you mean by this, but several UI details have been fixed, you may check and come back :)

  1. The time picker looks a bit overwhelming, and I'm not sure how it would work with 24h format. Android, for instance, does it this way: |
    |
    |

Agree, it looks overwhelming.

About the android's approach, I find the hour-picker with the 24 elements as not intuitive (when I have to pick the time on a circle what I expect to see is an analog clock). I think it is more intuitive to pick the time using an analog clock and then say if it is AM or PM instead of a clock with hours-after-12.

A feature of android's clock that we may consider adding is the two distinct clocks; the user could click to the hours'/miniutes' text at the bottom of the page and then only the hours'/minutes' clock would be visible.

Another thing is how many hours/minutes model elements we should display. Currently, hours 12,3,6,9, minutes 0,15,30,45 and the selected elements are displayed. Should we display more, less, other?