KDE PIM/Meetings/Osnabrueck 11

The annual KDE PIM Meeting will take place from 1.3.2012 to 3.3.2012 at the KDAB offices in Berlin.

Topics

Projects

Projects we'll work on in small groups, mostly coding or creating other concrete results.

• Add your project here
• KDE Dependencies Repository: create and fill a repository containing all essential dependencies for kdelibs, kde-runtime, kdepimlibs, kdepim-runtime and kdepim, primarily for use on Mac and Windows. Define update policy for those packages.
• KDE-wide metacontacts (KPeople) - general overview of the state, architecture and possible uses
• Review John's proposed QTimeZone scheduled for inclusion in Qt 5.1 to ensure meets KDEPIM requirements, bug fixes, code improvements, etc
• WebAccounts integration :33

Discussions

Discussions about topics, which are relevant to all or a sub group of people. Please state audience and desired result of the discussion.

Future Development

Audience: all, Desired Results: Plan regarding future 4.x releases and port to KF5

• How to move to KF5?
• KHolidays2 - Use JSON files? Try make standalone project for all PIM apps and desktops to use?

Marketing

Audience: all, Desired Results: Input on timeline, facts on good things on Akonadi, agreement on communication, group hug

Follow up on what we did at Osnabrück 10.

Add your discussion topic here

QML Calendar API

There is some awesome calendar stuff living in branches right now. That however is the C++ side. We don't seem to have any "developer friendly" QML layer to use all it's abilities. I'd like to draft up a "QML API" to make the calendar data easily available in QML. This is for the "calendaring" branch: http://quickgit.kde.org/?p=kdepim.git&a=shortlog&h=6854a4bb1b3843234ecc2ee9eb319585f56b84c9 Should we use a dataengine or a dedicated QML component?

We do already have the calendar engine: http://quickgit.kde.org/?p=kde-workspace.git&a=tree&h=0c2732e5a4bcd5f508ed52b3c7967e452cc04931&hb=b01fae8966132826097a97237bbf6954ebad6732&f=plasma%2Fgeneric%2Fdataengines%2Fcalendar. Should that be extended or should we go for a dedicated QML component as API like so:

Calendar {
  id: todaysItemsFromX

  // If no date is provided, all entries will be returned
  day: QDateTime something..

  // Fetchtype determines which events to return. Enum with TodoEntries, EventEntries, YournalEntries, .... etc.
  fetchType: Calendaring.EventEntries

  // The calendar from which to fetch the entries. If none provided then it will fetch the requested entries from all available calendars.
  calendar: "x"

  // The model containing the data with the filters applied.
  model
}

Above is just a "braindump". I'd like to discuss this idea with some people at the sprint and implement it.

Plasma Calendar

Added by John Layt.

We need to push for the completion of the Plasma integration, this years GSOC could be a good opportunity with its theme of polishing existing things. See http://www.layt.net/john/blog/odysseus/fame_akademy for my blog on what needs doing and http://community.kde.org/Plasma/Clock for more details. In short:

• Ability to choose Collections to display in a widget
• Ability to add simple Events and Todo's
• KAlarm integration
• Various UI improvements

It may be worth considering if we want to continue with the current Plasma widget or come up with something new.

One problem that also needs addressing is the Plasma Calendar launching Akonadi only to discover that no calendars are configured. To quote my blog:

"One other area that needs solving is what to do when a user doesn't actually use KDEPIM or Akonadi for their PIM needs but Akonadi has still been installed by the distro by default? At the moment we launch Akonadi by default inside the Plasma Calendar as soon as the user clicks on the Clock, and query it for any available events. Naturally it finds none, but by then it is too late, Akonadi has been launched and is seen to be using resources. "Oh noes, big bad bloated KDE!" Many distro's avoid this by changing the default setting to not showing Events, but then users may not realise that they can be enabled. A far better solution would be if there was a passive way to query if any Akonadi Calendar Resources have been configured and only launch Akonadi if they have. We could also then offer a wizard to configure Akonadi Resources if none have been. This of course is something that would have to be implemented by the KDEPIM/Akonadi team."

Presentations

Presentations of things interesting to the KDE PIM community. Please state targeted audience.

• Add your presentation here

Agenda

Friday

16:00 Start meeting, fill agenda, get organized

Saturday

10:00 Review first batch of work, get organized

10:30-12:00 Presentations, discussions targeted at whole group

13:30 Group photo

17:00 Review second batch of work, get organized

17:30-18:30 Presentations, discussions targeted at whole group

Sunday

10:00 Review third batch of work, get organized

10:30-11:30 Presentations, discussions targeted at whole group

14:00 Close meeting, collect next steps

Meeting Notes

Notes will go here

Blogs

When you blog about the meeting (and you should ;-), please add a link here

Organization

See the Osnabrück 11 organization page for organizational details.