KDE PIM/Meetings/Toulouse2016

Attendees

• Laurent
• K´evin
• Franck
• Dan
• Andre
• John
• Sandro
• Christian
• Volker

Notes

libkleo dependencies / libkleo/qgpgme future

Andre/Christian/Sandro

Andre already started dropping dependencies and made some optional, so the situations is much better, than it was evelulated for kube.

Currently libkleo is used in kleopatra, mimetreeparser and messagecomposer.

libkleo is currenty a bundly of things:

• jobs around gpgme++

- will move lower the stack to qgpgme

• widegt for selected keys, showingWarnings...
• different backend support chiasmus/gnupg

- chiasmus support will very likly to be dropped from libkleo

For mimetreeparser the moving of jobs to lower stack is enough move the dependency to qgpgme. Without chiasmus the whole idea of libkleo is getting away, so maybe get rid of it completly?

• open question is where to move widgets that are used from messagecomposer and kleopatra

Additionally qgpgme will get support for a higher Qt API to request f.ex

• a more user orintated API instead of a API around what gnupg exposes
• a key for a keyid (from verification/ decryption result)
• add more advanded errors/warnings ("missing secrect key" instead of "decryption failed")

ICal TimeZones

Plan:

• drop KCalCore::IcalTimeZone* classes
• just provide a list of available additional time zones known to KCalCore

Existing users:

• incidence editor time zone combo box -> reduced dependency to name-based lookup for a string provided by UI
• ical Akonadi serializer, used as a timezone cache for system timezones -> move inside KCalCore to hide from API

C++11 usage

auto

Two views on this: always-auto fans and people concerned about readability of code.

Therefore we start with the following compromise: Use auto primarily to avoid duplicated type information (ie. when the type is already written on the right hand side), or when the type is "generally known" and inconvenient to write (e.g. iterators).

libraries

Follow KF5 guidelines.

application

GCC 4.8 and MSVC2015 which is basically the complete C++11 language feature set (but not the library feature set).

QML representation for mails in Kube

Christian/Sandro

To get rid of rendering the whole email to html and implement the handling inside html (like requestion decrpytion, handling attachments). We want to do thing handling inside QML and only show the actually mail content inside a QWebView.

mimtetreeparser dependencies

• move attachmenttemporaryfilesdirs to mimetreeparser
• nodehelper should no longer be necessary (we should be able to iterate over the parts ourselves)
• quoteHtmlChars is not necessary if we move the html generation out of mimetreeparser
• move html messagepart to messageviewer and thus remove "to plaintext" functionality from mimetreeparser

Bumping so version number

Some distributions complained that we broke ABI without bumping so version numbers.

• some devs see it as an inconvenience to selectively bump so version numbers, because it's no longer obvious what is the latest set.
• it is also precieved as standard to have the so version synchronized to the library version.

We will either bump all so versions collectively with every release (since most change currently anyways), or only bump the ones that actually changed (since most won't change eventually). Of course everything that goes to frameworks follows frameworks policy anyways.

Sandro will evaluate the siutation in kdepim again, how in flux we actually are, and discuss the problems that distributions actually have again, and then suggest a solution.

Zanshinification of KDE PIM

Architecture

• Move to onion architecture, with application-specific domain model in the center.
• Domain objects need to consider performance and scalability, Zanshin's approach of using QObjects with copied data wont work for KMail.

Moving from layer architecture to onion:

1. develop application specific minimal domain model
2. develop proxy model or ETM sub-class for mapping to domain model objects
3. switch view code or other model using code to use domain model objects
4. find manually created Akonadi jobs
5. create repository interface for domain objects, for creating/updating/removing and whatever extra operations beyond that are used (higher-level actions).
6. port application to domain object roles (for reading) and domain object repositories (for writing)

Aiming at moving direct Akonadi use out of the application. All steps above should be unit tested.

Code

• StorageInterface: more of less directly useable, move to libakonadi and extend to all operations
• Dependency Manager: Kevin will push that to QtCore.
• Reactive Collections: Might move to KAsync, Christian will investigate when working on IMAP for Sink

KDELibs4Support Removal

Some progress:

• no more KPrintPreview
• no more KCalendarSystem (apart from KAlaram)
• KAddressBook no longer needs KDELibs4Support
• reduced ICalTimeZone usage
• ported some KTimeZone usage to QTimeZone, but this is largely blocked by KDateTime
• ported most remaining KLocale usage

Still to do, based on John's input:

• use12HourClock -> contains("a")/constains("A") on the QLocale date format string
• weeksInYear: std::max(QDate::weekNumber()) for the last 7 days in the year.

Release-impacting changes for 16.08

• kdepimlibs is going to be split and been removed afterwards (split to akonadi-calendar, akonadi-notes, akonadi-mail, kioslaves will move into kdepim-runtime) - montel is doning the stuff
• KHolidays is becoming a framework, John is kicking off the review on frameworks-devel
• kleopatra is splitted out as single application (has already its own repo) kleopatra will have two different release cyles to follow one KDE Applications for Linux and GPG4Win for windows builds
• messagelib will change it dependecy from libkleo to qgpgme
• gpgme++ will be move to upsteam gnupg