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
KDE Bugzilla all open Plasma Clock bugs
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 Binary Clock Applet (Addons)
The Fuzzy Clock Applet (Addons)
Future Plans
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.
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?
- 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?
Applets
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
For the compact widget see the proposed "Zooming Calendar" section below.
The more detailed widget would look something like the Google or Gnome widgets shown in the section below.
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?
- Time Zones: Version of teh WOrld Map that shows proper time zones
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.
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.
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.
Other Widgets
