KDE PIM/Meetings/Akademy-2010: Difference between revisions
Appearance
mNo edit summary |
add meeting notes |
||
(2 intermediate revisions by 2 users not shown) | |||
Line 16: | Line 16: | ||
* Planning sprint later this year | * Planning sprint later this year | ||
* Making Akonadi resources available to non-kdepim apps | * 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 = | = 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! | |||
[[Category:PIM]] | [[Category:PIM]] |
Latest revision as of 20:50, 6 July 2010
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!