KDE PIM Bof at Akademy 2010
Tuesday, July 6th 2010, 18:00 in Area 4
Please add stuff here we need to discuss!
Depend on KDE 4.5 libs in trunk? -> For stability reasons and dependencies -> Needs to build on all platforms first, will take some time -> And Komo needs to be merged -> For stuff in kdelibs trunk: Use KDE_IS_VERSION #ifdef -> Works for a handful of classes only, like proxymodels
-> Need standard install dir and naming convention for QML components -> KStandardDirs: Add QML support -> Conflicts with point 1: Backport? Copy? -> CMake variable
-> Before: Every app has different idea of edit and view -> Now: Libraries in kdepimlibs for contact handling -> Needed: Same for KJots, KMail and KOrganizer -> Clear design -> No more D-Bus calls -> Seperate, reusable components -> Example: KJots and KJots Plasmoid -> kdepimlibs -> No more code duplication -> Factor out common patterns for viewers/editors in base class? -> Sit down and get shit done - Concepts for better reuse of editor components (separating gui/logic) - Timeline for moving editors/viewers to kdepimlibs -> Making it public: Need nice API -> API design & review -> Not something short-term EMail components: MessageCore, MessageComposer (depends on MessageViewer), MessageViewer, MessageList, TemplateParser -> Meet for Message* classes here in Tampere? -> Or dedicated sprint? -> invite other people who use PIM stuff -> Needs broader design/requirements etc before Calendar comp: IncidenceEditor, Calendarviews Timeline: First use components in other kdepim apps (4.6+x), then public API (4.7+x) kdepimlibs/akonadi contacts calendar mail notes? feeds?
Feeds Akregator unmaintained Akonadi port half done Volunteers? Needs maintainer for moving stuff into kdepimlibs Share message list and folder tree with KMail? News Olivier porting KNode to messageviewer Akonadi port half done Goal: Share most parts between KMail and KNode
Notes Model class and some others Still needs some thought on the needed API
MessageCore: Currently, dumping ground for shared KMail classes -> Like libkdepim (and kdecore ;) Remove dependency of MessageComposer on MessageViewer -> Split OTP into processing and rendering TemplateParser: Only used by messagecomposer? Then move there! akonadi_next: lots of stuff to clean up and move around there Calendarviews depend on akonadi_next -> conceptually questionable: KCal/CalendarAdaptor hack -> get rid, clean up -> models go to kdepimlibs first libkdepim addresseelineedit should move to kdepimlibs - problematic ldap dependencies? Move to kldap? Refactor? - nice API, horrible implementation can be ignored - Volunteer: Tobias mail: move out message actions into standard action manager -> same for other types -> also useful for mobile applications kcheckcombobox -> where to put it? kdeui? -> kdeui move rejected. search for reasons, fix issues -> qcombobox does that? check! -> convenience API around low level stuff in QCB -> Volunteer: David kdate*, ktime* -> replicates like bunnies -> move to kdelibs, finally! -> Volunteer: Kevin O. (KDate*)
- Before API freeze -> October? - KCalCore timeline? -> One month (Meego release) -> API review can be done offline or dedicated spring - Specific goals needed for having direction - Focusing on 4.6 release?
- Move KAlarm resource to runtime/resources -> all apps can use it - Related: Calendar dataengine copied code -> review, candidates for kdepimlibs/akonadi/calendar -> Volunteer: John Layt -> Contact Frederik Gladhorn for that
- Nice live demo :) - Kontact summary page is rewritten - uses Plasma and Dataengines - Plasma Shell embedded in KPart -> also used in other applications - 1/3 of way - Lionmail will be used for mail summary - Planner: not yet - Make all lists (todo, mails, whatver) read-write -> can be put on desktop as well -> use standard kdepimlibs/akonadi/xyz widgets? - Dataengines - One abstraction layer too much? - possible wrap ETM in a dataengine? - provide easier scripting
- regular reports on the list -> by student?
What is it? Nokia forked KCal a year ago for Meego, called ExtendedKCal Last Akonadi Meeting: Work together to merge the two libraries New library: KCalCore Basically KCal without deprecated Resource stuff etc No KMessageboxes, i18n strings, etc Next month: Split has to be finished Till: When is the API freeze?? KDAB (Sergio & Allen) work on it Advantages for both sides Meeting in Berlin with a few people for API review? Small warning Old KCal will stay around, compatibility reasons Port KOrganizer to KCalCore KDE migration? Is there still something using KCal directly, without Akonadi? Maybe resources (groupwise) New payload type/mimetype? Port also before freeze to detect API issues work harder!!!
- Big problems for end users (David's user experience probably typical), bad impression - Bugs are found by testing with many different setups, widespread testing -> But: Already many known problems anyway - forget about 4.5 / only do beta during 4.5 -> too many bugs discovered -> no final release, release only betas until 4.6 - frequent releases are important - kdepim 4.5 depend on lastest kdepimlibs 4.5 -> has to be synchronized -> kdepim 4.5 beta releases at the point of minor releases of KDE SC -> first release: based on kdepimlibs KDE SC 4.5.0 - 4.5 / trunk: merges/backports needed - development model - stable trunk - conflicts with komo/e35 work - focuses resources on one branch - bugfixing work should be done in 4.5 - very good for svnmerge - nothing will get lost in merging - should create policy - no bugfixes in trunk, they should be done in 4.5 - no backports, forwardports with svnmerge - Volunteer for mailing to kdepim / documenting svnmerge Thomas - people who bypass svnmerge will get hurt by me - komo branch gets merged to trunk, not 4.5 - withdraw tarball from Allen? - or: warning that stuff is broken (migration, filtering) - kdepim+libs 4.5 branch string frozen!