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.
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 main future plan is to support the adding of PIM data.
See below for the required data service work required to enable this on the backend.
- 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.
- Use html table formatting in the pop-up text to allow proper layout and indenting, css styling, etc?
- I was suggesting we might move the code from the Calendar engine to the Akonadi data engine so the implementations and interfaces are consistent, but thinking about it again Akonadi is an implementation detail and a bad name for a high level api so perhaps separate data engines for Calendar, Mail, and Contacts are better even if they use the same underlying code and consistent api.
- 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?
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 would suggest two main improved applets sharing only low-level interface and layout code:
- A compact widget based on the current design that is touch friendly and is meant for use in the panel and restricted screen size devices
- A larger widget showing more data by default that is designed to be placed on a desktop or larger screen device
Other possible applets:
- Holidays: Applet to show all holidays around the world today, tomorrow, this week, next week, etc
- Birthdays: Show only Akonadi Birthdays collection, basically the same as Holidays applet, perhaps shared "Special Events" widget?
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.
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:
- Custom Properties
Plasma Service Design
An initial minimal definition for the Plasma Service has been created. The actual implementation is still required.
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.
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.:
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.