KDE PIM/Akonadi: Difference between revisions
(Add collection model/view notes.) |
|||
Line 45: | Line 45: | ||
|- style="background: #ececec; white-space:nowrap;" | |- style="background: #ececec; white-space:nowrap;" | ||
! Status !! Item !! Description !! Contact | ! Status !! Item !! Description !! Contact | ||
{{FeatureInProgress|KResource Akonadi bridge|for KCal and KABC|Kevin}} | {{FeatureInProgress|KResource Akonadi bridge|for KCal and KABC|[email protected]|Kevin}} | ||
{{FeatureTodo|Akonadi KResource bridge||Kevin}} | {{FeatureTodo|Akonadi KResource bridge||[email protected]|Kevin}} | ||
{{FeatureTodo|Expire Agent||}} | {{FeatureTodo|Expire Agent||}} | ||
{{FeatureTodo|MBOX Resource||Thomas}} | {{FeatureTodo|MBOX Resource||Thomas}} |
Revision as of 20:29, 9 February 2008
Akonadi TODO
The following list contains the things which need to be done for Akonadi.
Core
Status | Item | Description | Contact |
---|---|---|---|
DONE | Cache policies | As discussed in Osnabrueck | Volker <[email protected]> |
IN PROGRESS | Agent configuration | As discussed in Osnabrueck | Volker <[email protected]> |
TO DO | Item size | Needed by Mailody | [mailto: <>] |
TO DO | Item streaming in ItemSync/ResourceBase | As discussed in Osnabrueck | [mailto: <>] |
TO DO | API for additional item parts | As discussed in Osnabruck | [mailto: <>] |
TO DO | Infrastructure for showing additional dialogs from agents/resources | As discussed in Osnabrueck | [mailto: <>] |
TO DO | Allow to limit ItemFetchJob to current cache content | Prevents search index feeder agents from downloading all remote data | [mailto: <>] |
TO DO | Conflict detection in resources | See Osnabrueck meeting notes for details | [mailto: <>] |
TO DO | Fix API for item/collection modifications | See Osnabrueck meeting notes for details | [mailto: <>] |
TO DO | Remove DataReference | Fold back into Item | [mailto: <>] |
TO DO | Undo framework | [mailto: <>] | |
TO DO | Action framework | see below | <Volker?> |
TO DO | Server-side copy | for items and collections | [mailto: <>] |
TO DO | Finish collection model/view | see below | [mailto: <>] |
TO DO | Solid integration | Switch online/offline state in ResourceBase automatically | [mailto: <>] |
Mail specific extensions
Status | Item | Description | Contact |
---|---|---|---|
TO DO | Extend model/view stuff for mails | [mailto: <>] |
Event/Todo/Journal specific extensions
Status | Item | Description | Contact |
---|---|---|---|
TO DO | Todo proxy model | See KOrganizers To-Do view | <Bruno?> |
Resources, Agents and others
Status | Item | Description | Contact |
---|---|---|---|
IN PROGRESS | KResource Akonadi bridge | for KCal and KABC | Kevin <[email protected]> |
TO DO | Akonadi KResource bridge | Kevin <[email protected]> | |
TO DO | Expire Agent | [mailto: <>] | |
TO DO | MBOX Resource | <Thomas> | |
TO DO | Extend IMAP Resource | [mailto: <>] | |
TO DO | POP3 Resource | <Thomas> | |
TO DO | Filter Agent | [mailto: <>] | |
TO DO | Search | [mailto: <>] | |
TO DO | Filter Rule GUI | Used by filters and searches | [mailto: <>] |
Akonadi Braindump
Ideas/notes etc. on various open issues in Akonadi.
Akonadi Standard Actions
Idea: Have something like KStandardAction for Akonadi that not only includes the representation of the action but also its state management and the actual operations. Like libakonadi that should be splitted into a generic, type-independent part and be extensible for type-specific actions. This will enable code sharing among many applications and guarantee consistent actions everywhere.
State management: watch selection models of a collection and/or item model.
Use KXMLGUI for context menus in standard views to allow easy extensibility with custom actions.
Generic actions:
- new collection
- new virtual collection
- delete collection
- copy collection
- cut collection
- paste collection
- synchronize collection
- show collection
- delete item(s)
- copy item(s)
- cut item(s)
- paste item(s)
- paste native data
- tag item(s)
- comment item
- rate item(s)
The list is definitely long enough to make this worthwhile.
Collection Model / Collection View
Ideas/missing features/bugs of the collection model/view:
- Enable/disable status columns
- Show status after the name (see KMail)
- Size column
- Save/restore layout
- Custom collection icons (see KMail, also needed for resource defined special folders (eg. Inbox)
- Status tooltips (see KMail in 3.5.9)
- Quick search
- Favorite folder view as proxy model on top of the normal collection model (FlatCollectionProxyModel might be helpful for there)
KMail Breakdown Plan
The current plan is to put some parts of KMail into a stand-alone library, independent of KMail. This increases code reuse (for example, the message composer could be shared with Mailody) and makes the code a lot easier to maintain and to port to Akonadi.
Status | Item | Description | Contact |
---|---|---|---|
TO DO | Bodypart formatters | [mailto: <>] | |
TO DO | Reader Window | [mailto: <>] | |
TO DO | Composer: Editor | [mailto: <>] | |
TO DO | Composer: Message Composer | [mailto: <>] | |
TO DO | Composer: GUI Window | [mailto: <>] | |
TO DO | Queue Manager for mailtransport | [mailto: <>] | |
TO DO | Templates: Core | [mailto: <>] | |
TO DO | Templates: GUI | [mailto: <>] | |
TO DO | Port KMCommands | [mailto: <>] | |
TO DO | Port away from KMMessage and KMFolder* everywhere it is left | [mailto: <>] | |
TO DO | Migration application for index and other config | [mailto: <>] | |
TO DO | Port MDNs | [mailto: <>] |