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 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:
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:
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 CalendarEngine API.
The following data fields are yet to be implemented:
The first task is to define the minimal set of functionality supported. Only the creation of simple non-recurring Events, Journals and Todo's should be 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. Deletion of Events should be supported.
An initial minimal definition for the Plasma Service has been created. Use case scenarios and the actual implementation are still required.
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:
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.
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.
These basic components can then be combined into different Applet layouts, such as:
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:
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.