Plasma/Clock

Plasma is all about Clocks. It's an old joke, but it contains a kernel of truth. The clock is the one element of the desktop most people depend on, and it can be a valuable conduit for information they need. This page will co-ordinate all the resources around the Plasma Clock and plans for it's future.

Resources

UserBase Page

KDE Bugzilla all open Plasma Clock bugs

Plasma Tasks List for Clocks

Current Implementation

The current implementation can be found in the following locations.

Time DataEngine - Provides current Time

Calendar DataEngine - Provides Events and Holidays

Akonadi DataEngine - Provides Akonadi email

Plasma Clock Library - Common base classes for all clock/calendar Applets.

The Calendar Applet

The Digital Clock Applet

The Analog Clock Applet

The Binary Clock Applet (Addons)

The Fuzzy Clock Applet (Addons)

Future Plans

The main future plan is to support the editing of PIM data via the clock/calendar. This is the top ranked Brainstorm Suggestion and was the most popular feature request in Bugzilla.

To implement this requires two steps are required:

• Adding the required features to the DataEngine to allow adding and editing of PIM data
• Adding the UI to the Applets

The existing Applets are also very rough around the edges and not as usable as they could be and need some rework.

Other ideas that need doing:

• Allow the user to configure what Collections/Sources get displayed in each plasmoid instance, and to filter within those Collections e.g. have work and personal calendars on separate widgets, hide private events, disable events if calendar displayed on screen-saver, select Birthdays resource, etc.
• KAlarm integration - Name as "Reminders", maybe in Calendar engine or in separate engine?
• Clock Chimes
• Custom Time Zone names
• Desktop shortcut to show Calendar
• Some way to detect if Akonadi is actually being used, as it may be installed but not used, therefore starting it on login is wasteful of resources. Or wizard to help set up Akonadi access to users alternative data sources, e.g. Evolution, Sunbird, Google, etc?
• The DataEngines need some reorganisation. All the DataEngines using Akonadi to provide services should share common code to simplify maintenance and provide a consistent api to clients when dealing with resources, etc. However having a DataEngine named Akonadi is not desirable as it is an implementation detail which should not be exposed to the Plasmoid client coders. This suggests a shared base class AkonadiEngine that is not exported from which specific client API classes are derived like CalendarEngine, ContactsEngine, and MailEngine. The CalendarEngine currently supports Events, Journals, Todos, and Holidays and could add Birthdays and Reminders, or do these deserve separate DataEngines?

PIM Data Interface

Currently PIM data is read-only and is provided via the Calendar Plasma DataEngine. To make PIM data 2-way would require the creation of a Plasma Service. However, the Akonadi interface and the creation of PIM data in general is very complex and is not ideally suited to being mapped into a Data Engine or Service. The API would be very big and unwieldy and a maintenance nightmare, and the complex specialised gui widgets such as Recurrence Editor would have to be recreated. This is one occasion where Plasma elements requiring complex functionality will be better off directly using the Akonadi API and GUI elements. However this doesn't stop a simplified service being provided that would meet 80% of needs with the more complex requirements being left for the native apps to handle.

Plasma DataEngine

The Calendar DataEngine supports queries to Akonadi for Event, Todo, and Journal data, and to the KHolidays library for Holidays data.

The data structure is documented in the Calendar DataEngine API.

The following data fields are yet to be implemented:

• Attendees
• Attachments
• Relations
• Alarms
• Custom Properties
• Lat/Lon
• Collection/Source

Plasma Service Design

An initial minimal definition for the Plasma Service has been created. The actual implementation is still required.

Only the creation of simple non-recurring Events, Journals and Todo's are supported by this service. Any more advanced features will require the user to launch a specialized app. Editing simple Events may be added later, but this may be confusing to users as to why they can edit some Events and not others.

Akonadi Calendar Model

Currently the Calendar DataEngine contains a direct copy of the required Akonadi Calendar Model as this code was not available in kdepimlibs at the time. See the README file for full details. When this API becomes available in KCalCore then the DataEngine must be ported to use it. Until then the code must be kept in sync withe the kdepim calendarsupport code for bug fixes every release.

Chimes Feature

Various users have requested a Chiming Clock feature which was discussed on the plasma-devel mailing list. The following design was proposed by John Layt as a compromise between easy configuration and advanced features.

The problem here is the old one of balancing features for the power users against ease of use for the majority of users, it just means we have to make the code do more of the work instead of the user, or rather just be smarter about it.

The most common features of chiming clocks are:

* Quarters, i.e. different chimes at 00, 15, 30 and 45
* Striking the hour, i.e. 12 strikes at midnight
* The hour chime plays before the hour, with the first hour strike playing exactly on the hour

Combined with the "Speak Time" feature, we would obviously want to allow slightly more options, such as only chiming/speaking on the hour, turning off striking the hours (which can get very annoying and is meaningless for speak time), or chiming/speaking every x minutes. I'm sure people can think of plenty more "nice-to-have-but-rarely-used" options that we don't want to expose most users to.

Expecting a user to configure a ui for all that is just not on.

The key to keeping it simple is to NOT allow the user to configure the sounds and when they play in the ui as most users will never need to do this, and catering for all the options is just too complex. Instead we would define a Chime Theme file format that we and power users can use to configure how a Chime Theme works and what sound files to use, and provide the user with a simple list of available themes to choose from. We could even allow downloading new themes from GHNS, in which case we would ship KDE with just a very simple theme.

Here's how a single ui section for "Audible Feedback" in the "General" tab would look like:

A combo for "Feedback Type" with options for:

* None
* Speak Time
* Play Chimes

A combo for "Frequency" that is activated only if "Feedback Type" is not "None", with options for:

* Chime Theme Defaults (only show if "Play Chimes" chosen)
* Hourly
* Quarters
* Every x Minutes (better wording needed)

(Note that Hourly and Quarters are just synonyms for every 60 or 15 minutes.)

Next to this combo is a minutes input spin box activated when "Every x Minutes" is chosen. Alternatively we do "Frequency" as a radio button with the spinbox inline in the "Every x minutes" text.

A combo for "Chime Theme" which is only activated if "Play Chimes" is selected, with a list of the currently available themes:

* Beep
* Time Pips
* Westminster
* Cuckoo
* ...

Next to this could be a GHNS button to download more themes.

Optionally under this could be a tick-box for "Strike Hours" which is only activated if "Play Chimes" is activated, to turn off striking hours which could get annoying. Alternatively it could be integrated into the "Feedback Type" combo as separate options for "Play Chimes and Strikes" "Play Chimes Only" and "Play Strikes Only".

I think 3 or 4 lines of simple config options is not too bad. The "Feedback Type" and "Chime Theme" could even be merged for an even simpler interface.

The Chime Theme would actually be a self-contained folder holding a config file and all required sound files, and would look something like this:

 sounds/chimes/themename/
   themename.desktop - Holds name of theme and default config options
   default.ogg       - Default sound to play if no specific sound
   strike.ogg
   hour.ogg
   quarterpast.ogg
   half.ogg
   quarterto.ogg

In the .desktop file itself, the config options would allow you to point to other sound files in other locations and set default frequency, e.g.:

   [Sounds]
   hour=/media/data/audio/sounds/doh.wav

There's lots of options that could be set here, but I won't detail them now.

Some possible Chime Themes:

• Beep: A simple beep with slightly different ones for hours, quarters, and minutes. Ship with KDE, download the rest.
• Time Pips: http://en.wikipedia.org/wiki/Greenwich_Time_Signal
• Westminster: http://en.wikipedia.org/wiki/Westminster_Quarters
• Whittington: http://en.wikipedia.org/wiki/Whittington_chimes
• Ships Bells: http://en.wikipedia.org/wiki/Ship%27s_bells

At first glance it may seem a fairly complex solution, but I think the implementation will actually be fairly simple and not add much overhead, the hardest part is designing the config file to be flexible enough.

Applets

See also the Brainstorm Suggestion.

Experience from the many layout bugs in the current Clock/Calendar Applet suggests that having one applet trying to dynamically adapt its layout to every different use case is just too hard.

I suggest we need to implement the following low-level widgets that can then be mixed and matched to create different Applets.

• Calendar Widget - Date table with navigation, already have one but needs a lot of improvement, see Zoomable Calendar proposal below
• Events Widget - New widget to list Events, Holidays, etc. By default will show Today, Tomorrow, and Upcoming (next x events that fit available space), but can be configured to list Events for a given date or date range. Include Todo's that have due dates, but separate Todo widget for advanced features.
• Clock Widget - Already have but needs to be more flexible options, e.g. show date only, etc. Fix a lot of the current problems. Applets can then choose what features they want to allow to be configured

These basic components can then be combined into different Applet layouts, such as:

• Compact Applet: Show just the Calendar Widget, clicking on a day zooms the widget in to show the Event Widget instead. Intended for restricted screen sizes, touch friendly.
• Landscape Applet: Calendar and Events shown side-by-side, designed to be placed on a desktop or larger screen device. Clicking on a day shows that days Events.
• Portrait Applet: Calendar and Events shown in vertical column.

See various layouts and proposals at the bottom of the page.

The interaction between the Widgets needs improving, mousing over a day causes the Event list to change which is disorientating and inconsistent. The Event list should show Today, Tomorrow and Upcoming by default until a particular day is clicked on, when only that days events are shown, or a "No Events" message.

Other possible applets:

• Holidays: Applet to show all holidays around the world today, tomorrow, this week, next week, etc. Based on Events Widget.
• Birthdays: Show only Akonadi Birthdays collection, basically the same as Holidays applet, perhaps shared "Special Events" widget?
• Time Zones: Clock Widgets stacked to show different time zones, optional map of world (i,.e. Gnome 2 style).
• Fancy widget: Showing desk calendar like layout with large day number, etc.

Zooming Calendar

The design for this widget is unashamedly borrowed from the Windows 7 calendar, although with far more polish and functionality (and I'm sure they borrowed the idea from somewhere... :-). This is designed to be a very finger and click friendly widget for compact screen spaces like phones, tablets and default panel clocks, but still also keyboard navigable.

Here's what the Windows calendar looks like when popped up, a standard Month view Day Grid with arrows to navigate to the previous and next month:

What is well hidden is if you click once on the month name the Day Grid zooms out to a Month Grid showing all the months in the current year:

Clicking the arrows takes you to the next and previous month, and clicking on a month name zooms you in to the Day Grid for that Month. If you click once on the Year Number however you zoom out to a Year Grid for all the years in the current decade:

I think you'll spot a pattern by now. Clicking the arrows takes you to the next and previous decade, and clicking on a year zooms you in to the Month Grid for that Year. If you click once on the Decade Range however you zoom out to a Century Grid for all the Decades in the current Century:

Clicking the arrows takes you to the next and previous Century, and clicking on a Decade zooms you in to the Year Grid for that Decade.

This should be easily achieved in QML, with a rather more obvious looking button at the top for the zoom-out function. The real added feature for KDE would be if you click on a day number in the Day Grid you will zoom-in to the Events list which will show a scrollable list of Events, Holidays, Todo's, etc for that day. Clicking on one of these Events will zoom-in to the full details for it. A long-hold on the day number, or clicking on a plus button in the Event list will allow you to add a new simple Event.

Example Widgets