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!