< KDE PIM | Meetings KDE PIM Bof at Akademy 2010 Date and Location Tuesday, July 6th 2010, 18:00 in Area 4 Agenda Please add stuff here we need to discuss! Minimum required dependencies during KDE 4.6 development cycle. Unifying mobile component source and install locations Unifying the editor/viewer components for all pim applications Concepts for better reuse of editor components (separating gui/logic) Timeline for moving editors/viewers to kdepimlibs Planning sprint later this year Making Akonadi resources available to non-kdepim apps Kontact-summary SoC status KCalCore is going to kdepimlibs soon, we need to review API (in one month?) Meeting Notes Minimum required dependencies during KDE 4.6 development cycle 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 Unifying mobile component source and install locations -> Need standard install dir and naming convention for QML components -> KStandardDirs: Add QML support -> Conflicts with point 1: Backport? Copy? -> CMake variable Unifying the editor/viewer components for all pim applications -> 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*) Planning sprint later this year - 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? Making Akonadi resources available to non-kdepim apps - 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 Kontact-summary SoC status - 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 Other SoCs - regular reports on the list -> by student? KCalCore is going to kdepimlibs soon, we need to review API (in one month?) 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!!! 4.5 Release "Stuff" - 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! Retrieved from "https://community.kde.org/index.php?title=KDE_PIM/Meetings/Akademy-2010&oldid=3799" Category: PIM This page was last edited on 6 July 2010, at 20:50. Content is available under Creative Commons License SA 4.0 unless otherwise noted.