1. Overview.. 2

1.1 Brief Introduction. 2

1.2 Dependency. 2

2. Core reference. 3

2.1 Architecture. 3

2.2 UI components design. 4

2.3 Time management 5

2.4 Enabler wrapper 6

3 Todo. 6

 

 

 

1. Overview

 

1.1 Brief Introduction

 

Calendar is a light weighted calendar application which provides the functions such as, managing the user's agendas, alarm at scheduled time, and check the agendas in different views. The application works on UNIX-like platforms. It bases on the libcalenabler, which uses sqlite3 as the database engine. The small footprint and the high efficiency make the application suitable to run on embedded devices.

The application provides following functions to users:

The application provides users with clear UI to create/edit events, set the event start/end time, repeat model, and the alarm model.

Users can check their agenda easily by different way: day view, week view, month view.

Users can choose to delete one specific event, or delete events before specific date. As to repeating event, delete only one instance or the whole sequences are both possible.

Users can directly jump to the specified day and check the agenda.

If it's set, an alarm window will be prompted up to the screen and the alarm sound will be played at scheduled time.

 

1.2 Dependency

 

Calendar application depends on the following libraries:

The GTK+ library contains widgets, that is, GUI components such as GtkButton or GtkTextView.

Shared code for applications developed for the phone application framework providing easy access to softkey definitions and communication.

A library provides some basic UI components which are commonly used in the GPE Phone Edition software.

A library provides the basic and core calendaring and scheduling functions.

The package  provides various interfaces to make the service oriented communication between applications much easier than using low-level D-Bus routines ever before.

 

 

 

2. Core reference

2.1 Architecture

 

Following graph depicts the whole architecture of calendar.

Figure 1 calendar application architecture

We can see from the bottom to the top:

The calendar application call the interfaces provided by libcalenabler, which provides the basic and core calendaring and scheduling functions.

Libgemwidget provides some basic UI components which are commonly used in the GPE Phone Edition software.The calendar application uses the following gemwidget: GtkTimeEdit, GtkDateEdit. These two widgets provide convenient rendering for date and time.

Inside the application architecture, the calendar application can be divided into two layers: the upper layer implements the UI interface, the lower layer supplies a wrapper to libcalenabler interface and provides the other utility functions like time management.

 

The following 3 sections will describe above 3 parts of the application in detail.

2.2 UI components design

 

In the implementation of GUI, there're 5 windows frequently popped up and down in the screen. It's obviously not a good way to create and destroy the windows frequently. Another way is to create the windows at the start, then show or hide some of them when necessary. But managing the windows becomes an important issue. Fortunately, Gtk+ has provided us with so many different widgets for different situation. The GtkNotebook widget is a GtkContainer whose children are pages that can be switched. The GtkNotebook widget manages the child pages efficiently, which is what we want.

For each of the 5 pages, we create a new widget. They're all derived from GtkFrame but each has different subwidgets and properties. Then the widgets are all inserted to the GtkNotebook widget. In this way, we can easily switch between the pages by the functjion " gtk_notebook_set_current_page () ".

Following table shows the functionalities of the 5 pages:

 

GUI

Functionality

Widget

Month view page

List the events happened in the specified month.

CalMonthView

Day view page

List the events happened in the specified day.

CalDayView

Week view page

List the events happened in the specified week.

CalWeekView

Event edit page

The page to add a new event or modify an exist event

CalEventEdit

Setting page

The page to set the default view and the start day of a week for the application

CalSettingPage

Table1 functionalities of the 5 main pages

This page displays all the events happened in the specified month. Direction keys can be used to browse between different days conveniently. When the user choose one day and press enter, the application will switch to the corresponding day view page. From this page, users can select items from the softkey pop-up menus to switch to other pages for different views, add new event, delete events or go to specified day. Events can be removed all at once, or users can choose to delete events happened before specified day. When users choose to go to specified day, the focus will be moved to the small grid representing the day. If the day to go isn't in the month we're viewing, the whole month view page should be redrawn for the different month.

The events happened in the day being reviewed will be listed in this page. The events may be repeating events which have occurrences on that day. Users can select event from the list to edit; add event to the calendar; or delete a specific event. The event will be checked before removing from the data storage. If it's a repeating event, uses will be asked to remove just one occurrence or remove all. For different choices, different calendaring enabler interfaces are to be called.

This page displays all the events happened in the specified week. From this page, users can select items from the softkey pop-up menus to switch to other pages for different views.

This page is used to create a new event or edit existing event. The user input in this page will be collected to produce a cal_event_t instance through the interface provided by calendaring enabler. Then, if user chooses to "save" the editing, the cal_event_t instance will be added/updated to the data storage by the calendaring enabler interface. If the alarm properties are set for the event, a newly created alarm job will be added to the alarm job list automatically by the enabler.

This page provides some configuration for the user preferences.

Month view, week view, and day view pages can be set.

Any day in a week (Mon, Tue,¡­) can  be set.

When the time is up for an alarm job, a dus message will be sent to gpe-applauncher to pop up a notification window at the top of the screen; alarm sound will be played; and the calendaring enabler interfaces will be called to reschedule the alarm jobs.

2.3 Time management

The time management part (time.c/.h) provides common time utility functions which are used in the whole application.

In the application, a global time variable "viewtime" should be used to keep record of the date and time that the user is browsing. "lastviewtime" is used to keep record of the last date and time that the user browsed. These two variables are compared to decide whether to update the whole GUI. Functions are provided in "time.h" to get and set the two variables.

Some functions provide basic date and time calculation. The function "cal_days_in_month ()" will return how many days are there in the specified year and month. The function "cal_time_from_day ()" will output the time in type of "time_t" while the input specifying year, month and day. The function "cal_day_of_week ()" return the week number in the year for specified day.

2.4 Enabler wrapper

Enabler part (calenabler.c/.h) provides some convenient functions which encapsulates the libcalenabler interfaces.

The functions "cal_enabler_init ()" and "cal_enabler_destroy()" can be used before and after using the libcalenabler to initialize or release the resources.

The functions "cal_event_list_init ()", "cal_event_list_destroy ()" makes it easy to render a list of variables of the type "cal_event_t".

This part isn't a total wrapper for libcalenabler. Most of the libcalenabler functions are still needed to be called directly by the GUI part.

3 Todo