Plasma/Clock: Difference between revisions

From KDE Community Wiki
No edit summary
Line 47: Line 47:
* KAlarm integration - Name as "Reminders", maybe in Calendar engine or in separate engine?
* KAlarm integration - Name as "Reminders", maybe in Calendar engine or in separate engine?
* Clock Chimes
* Clock Chimes
* Custom Timz Zone names
* Custom Time Zone names
* Desktop shortcut to show Calendar
* Desktop shortcut to show Calendar
* Some way to detect if Akonadi is actually being used,as it may be installed by not used, therefore starting it on login is wasteful of resources. Or wizard to help set up Akonadi access to uers alternative data sources, e.g. Evolution, Sunbird, Google, etc?
* 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?


== Applets ==
== Applets ==

Revision as of 17:06, 28 May 2012

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 adding of PIM data.

Brainstorm Suggestion

See below for the required data service work required to enable this on the backend.

Other ideas:

  • 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?

Applets

I would suggest two main improved applets:

  • 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 Today: 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.

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.

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.