Projects/PIM/KJots - Revision history

Odysseus: Merge in from KJots top-level page

2011-03-19T13:45:08Z

Merge in from KJots top-level page

Steveire: /* Books and Pages */ Fix second option description re books

2008-09-26T18:25:21Z

‎Books and Pages: Fix second option description re books

Steveire: Plan for using some pillars of kde in kjots.

2008-09-26T17:36:12Z

Plan for using some pillars of kde in kjots.

New page

For KDE 4.2, KJots will undergo several changes to integrate more with some pillars of KDE- Akonadi, Nepomuk, and Plasma.

This will involve changes in how user data is stored and represented.

== Current state ==

Currently, KJots books and pages are subclasses of QAbstractModelItem (see http://websvn.kde.org/trunk/KDE/kdepim/kjots/kjotsentry.h?view=markup)
Those classes are responsible for saving and loading data etc. Data is saved to .book files in the AppData directory. These .books files contain top-level books including any nested books.

The books are organized in a bookshelf, which is a QTreeWidget (http://websvn.kde.org/trunk/KDE/kdepim/kjots/bookshelf.h?view=markup).

== Current plan for 4.2 ==

The plan is to create some new representations of these objects to integrate with akonadi and nepomuk. This will allow multiple plasmoids to allow interaction with multiple or the same books. Additionally, nepomuk will give the possiblility to represent pages in a heirarchy of tags.

* http://thread.gmane.org/gmane.comp.kde.nepomuk/147
* http://thread.gmane.org/gmane.comp.kde.devel.pim/22743
* http://mail.kde.org/pipermail/plasma-devel/2008-September/001256.html

=== Plasmoid ===

Plasmoids would have a root index set as the root of the bookshelf, or rooted in one book or tag collection. For example, if you have a structure like:

* Book 1
** Page 1
** Page 2
** Page 3
** Sub-Book 1
*** Page 1
*** Page 2
* Book 2
** Page 1
** Page 2

Then it will be possible to show a plasmoid which displays only Book1 (including Sub-Book1), only Book2, only Sub-Book1, or all books in the bookshelf. Additionally, it will be possible to show only pages with the same tag.

Drag and drop between plasmoids will be possible as well as dragging books from the kjots application or kjots plasmoids onto the plasma workspace to create a new kjots plasmoid rooted at that book.

=== Mimetypes ===

The above drag and drop behaviour requires that a mimetype be registered for kjots books.
Additionally, akonadi requires that kjots books and pages have mimetypes set to facilitate item retrieval.
The mimetypes application/x-app-kde-kjots-book and application/x-app-kde-kjots-page will be used for these features.

=== Books and Pages ===

For akonadi support, KJotsBooks and KJotsPages wil be represented by simple structs and books will serialized/deserialized with a
[http://api.kde.org/4.1-api/kdepimlibs-apidocs/akonadi/html/classAkonadi_1_1ItemSerializerPlugin.html Akonadi::ItemSerializerPlugin]. This will allow syncronization of pages being displayed in different plasmoids and the kjots application.

There are two options for what to serialize. The current state could be preserved, and top-level books would be [http://api.kde.org/4.1-api/kdepimlibs-apidocs/akonadi/html/classAkonadi_1_1Item.html Akonadi::Item]s and would be serialized. The payload would be the pages and nested books within the top-level book.

Alternatively, the system could be changed to represent each book and page as a distinct file. Each page/book would be a [http://api.kde.org/4.1-api/kdepimlibs-apidocs/akonadi/html/classAkonadi_1_1Item.html Akonadi::Item] and could be serialized/deserialized individually. The payload would be the page content or the list of pages and nested books in the book.

For tagging, nepomuk requires that either books/pages be saved in individual files, or custom book and page classes exist (or both). An ontology will be defined which describes how books and pages relate to each other, and tag capable classes will be generated from that.

I'm not sure if the same class can be used for serialization/deserialization and nepomuk tags. I will probably need AkonadiNoteBook, AkonadiNotePage, and NepomukNoteBook, NepomukNotePage.

=== Bookshelf ===

The kjots bookshelf will be replaced with an [http://api.kde.org/4.1-api/kdepimlibs-apidocs/akonadi/html/classAkonadi_1_1CollectionModel.html Akonadi::CollectionModel]. Each book in the application will be a collection (which can be nested).
Page data will be retrieved with the [http://api.kde.org/4.1-api/kdepimlibs-apidocs/akonadi/html/classAkonadi_1_1CollectionModel.html#489f28b6acb4d13e1237765f85b4c120 Akonadi::CollectionModel::Roles::CollectionRole]. An [[Development/Tutorials/Akonadi/Resources|akonadi resource]] will be used to retrieve the collections, add/remove/modifiy items etc.

Using nepomuk types, a proxy model can represent the tags on a particular page, so that pages can be grouped by tag on the left tree. Dragging items around on the tree would change the tags on the item.

@@ Line 1: / Line 1: @@
 For KDE 4.2, KJots will undergo several changes to integrate more with some pillars of KDE- Akonadi, Nepomuk, and Plasma.
 This will involve changes in how user data is stored and represented.
-== Current state ==
+=== Current state in 4.1 ===
 Currently, KJots books and pages are subclasses of QAbstractModelItem (see http://websvn.kde.org/trunk/KDE/kdepim/kjots/kjotsentry.h?view=markup)
@@ Line 10: / Line 68: @@
 The books are organized in a bookshelf, which is a QTreeWidget (http://websvn.kde.org/trunk/KDE/kdepim/kjots/bookshelf.h?view=markup).
+=== Current plan for 4.2 ===
 == Current plan for 4.2 ==
 The plan is to create some new representations of these objects to integrate with akonadi and nepomuk. This will allow multiple plasmoids to allow interaction with multiple or the same books. Additionally, nepomuk will give the possiblility to represent pages in a heirarchy of tags.
@@ Line 20: / Line 77: @@
-=== Plasmoid ===
+==== Plasmoid ====
 Plasmoids would have a root index set as the root of the bookshelf, or rooted in one book or tag collection. For example, if you have a structure like:
@@ Line 39: / Line 96: @@
 Drag and drop between plasmoids will be possible as well as dragging books from the kjots application or kjots plasmoids onto the plasma workspace to create a new kjots plasmoid rooted at that book.
+==== Mimetypes ====
 === Mimetypes ===
 The above drag and drop behaviour requires that a mimetype be registered for kjots books.
@@ Line 46: / Line 102: @@
 The mimetypes application/x-app-kde-kjots-book and application/x-app-kde-kjots-page will be used for these features.
-=== Books and Pages ===
+==== Books and Pages ====
 For akonadi support, KJotsBooks and KJotsPages wil be represented by simple structs and books will serialized/deserialized with a
@@ Line 59: / Line 115: @@
 I'm not sure if the same class can be used for serialization/deserialization and nepomuk tags. I will probably need AkonadiNoteBook, AkonadiNotePage, and  NepomukNoteBook, NepomukNotePage.
-=== Bookshelf ===
+==== Bookshelf ====
 The kjots bookshelf will be replaced with an [http://api.kde.org/4.1-api/kdepimlibs-apidocs/akonadi/html/classAkonadi_1_1CollectionModel.html Akonadi::CollectionModel]. Each book in the application will be a collection (which can be nested).

@@ Line 53: / Line 53: @@
 There are two options for what to serialize. The current state could be preserved, and top-level books would be [http://api.kde.org/4.1-api/kdepimlibs-apidocs/akonadi/html/classAkonadi_1_1Item.html Akonadi::Item]s and would be serialized. The payload would be the pages and nested books within the top-level book.
-Alternatively, the system could be changed to represent each book and page as a distinct file. Each page/book would be a [http://api.kde.org/4.1-api/kdepimlibs-apidocs/akonadi/html/classAkonadi_1_1Item.html Akonadi::Item] and could be serialized/deserialized individually. The payload would be the page content or the list of pages and nested books in the book.
+Alternatively, the system could be changed to represent each book and page as a distinct file. Each page would be a [http://api.kde.org/4.1-api/kdepimlibs-apidocs/akonadi/html/classAkonadi_1_1Item.html Akonadi::Item] and could be serialized/deserialized individually. The payload would be the page content. Books would be Akonadi::Collection objects.
 For tagging, nepomuk requires that either books/pages be saved in individual files, or custom book and page classes exist (or both). An ontology will be defined which describes how books and pages relate to each other, and tag capable classes will be generated from that.
 I'm not sure if the same class can be used for serialization/deserialization and nepomuk tags. I will probably need AkonadiNoteBook, AkonadiNotePage, and  NepomukNoteBook, NepomukNotePage.
 === Bookshelf ===