KDE PIM/Meetings/Osnabrueck 11: Difference between revisions

Revision as of 15:51, 2 March 2013

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 for an unified way of managing web (google, facebook, ownCloud) accounts.
Google Integration - creating dedicated IMAP resource with native support for GMail IMAP extensions and adding support for Google Reader to the family of Akonadi resources for Google services

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

Porting to KDE Frameworks 5

Report from Kevin & David on status
Progress made on prep work, Qt upstream
kdeui main blocker
also date/time
once done will split
Tech Preview end of this year
Then QA process
Will need early porters to test results before final release
KDE PIM to be guinea pig?
already kdepimlibs-frameworks branch
initial port to build on kf5
then make kpl "dissapper"
Can use CMake features earlier, e.g. automoc in 4.11
Same of K??? can be done in 4.11
kdepim no branch before tech preview, too much changing
kpl branch has value as unit tests etc exercises code
cmd line args stuff needed in Qt, have branch in Gerrit, hard sell into Qt, volunteer(s) needed for 5.2!
lots of widgets stuff needs to move to Qt, need volunteers for 5.2!
libpimutils?
next meeting will be position to address kpl and kp porting
can remove any q3support NOW!
Could look to move K -> Q classes where not using the K extra features, but tricky to know

Akonadi/Nepomuk integration

vHanda: Looking into using the nepomuk feeders for KPeople. Currently too slow (2 or 3 emails per second, goal = 10 emails per second). Already better than the previous situation, 10 s per mail.
Completion in kmail composer (via nepomuk) is enabled again... but the goal is to replace that with KPeople (which has the contacts in memory).
vHanda: Planned: adding support for persistent queries.
C.M.: Letting the user control the feeder process -- people report CPU usage bugs, but if they could see that it's indexing emails, then we can differ that from actual bugs.
vHanda: Missing features for complex searches: query emails by date range etc. (feature set == see search dialog in kmail)

Virtuoso

vHanda: "I think I can write a virtuoso replacement in a month or two" (!) == mainly a SPARQL to SQL converter (limited to the SPARQL subset used in KDE)

Problems with virtuoso:

Their use case is web-based stuff, so no consistency checking (it's not strongly typed at all, all values go into the same column).
Some fields cannot be indexed (e.g. no date/time searches)
Memory consumption (Milian, help!). Caches in virtuoso + caches in nepomuk.
No support for cancelling queries (although, with Sebastian now working on virtuoso, we could push for that)
Two databases, we could use akonadi's DB instead.
No support for stemming in text-based searches.
Lots of data copying (e.g. for one email, there's the email on disk, in akonadi DB, in virtuoso's SQL table, in virtuoso's full text index).
This extra data copying cannot be streamed. So the text content of the large pdf files is loaded into memory and pushed all in one go into virtuoso cause there are no steaming operators. With our own solution, we would not store this extra data and we could just directly pass it into the full text indexer.

Instead of one big table, one table per property -> more control over indexing.

 Need to choose a full-text-indexing solution, one idea is XAPIAN.

Other 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.

@@ Line 153: / Line 153: @@
 * No support for stemming in text-based searches.
 * Lots of data copying (e.g. for one email, there's the email on disk, in akonadi DB, in virtuoso's SQL table, in virtuoso's full text index).
+* This extra data copying cannot be streamed. So the text content of the large pdf files is loaded into memory and pushed all in one go into virtuoso cause there are no steaming operators. With our own solution, we would not store this extra data and we could just directly pass it into the full text indexer.
 Instead of one big table, one table per property -> more control over indexing.