On the other side of cloud

Tags:

2007

Finally, I abandon this, after I saw basKet. Also, I don’t have time to work on it after I join OTC. But I am appreciate to this, which lead me to the Open Source world. Thanks, my mentor Brade, and KNotes.

2007-03-23

Continue developing…
Fix a bug in trunk. I want to released this project before KDE 4 freeze trunk(May this year). It takes too long….

2006-08-24

Now I completed the classified note menu. The categories information was stored in journal object, as it was. So I only set the categories and classified it.

Now click the icon in systray will show sub menus, with different categories name. There is a “Default” categories, which was provided for note with no category. The next step was adding setting function of category. I supposed to implement it as a sub menu with can be checked and unchecked. Also a function provide adding.

2006-08-05

Completed setting up enviorment. Using KDE4.

BTW: I found a horrible fault. I missed last serveral paragraphs on this page! I don’t know how long it lasted, but for about a month…I am terribly sorry for not discover this fault, and I fixed it.

2006-07-20

KDE e.V. will held an activity like socSeason of KDE, so I will continue my work…..

2006-05-24

I am failed to get KNotes Improvement project. And this page became history which contains my effort on this, maybe helpful for other developers.

Advice from Jason ‘vanRijn’ Kasper ( kdepim-users mailing list):

This would actually be very nice to see implemented. It’s one of those things
that don’t work quite well when syncing between kpilot and knotes. Speaking
along these lines (and to hopefully address your question), I think it would
be best to have only one level of categories (i.e. not nested, but a flat
list). If possible, to maintain compatibility with kpilot, it would be best
if you set an upper limit on the number of categories that users are able to
choose from. Palm devices are limited to 16 categories that the user can
customize, iirc (Personal, Business, Notes, etc., etc.).

Something like flickr tags would be an interesting feature, to be sure, but
I’d personally rather see that implemented in addition to, not instead of,
traditional categories.

2006-05-23

I send a survey to kde-linux and kdepim-user yesterday in order to find users thoughts of knotes’ categories.

Thanks to Grahma Cobb in kdepim-user. He not only give me useful suggest on categories, but also spent time on correcting my English. That’s very kind of him. I am appreciate him.
Cobb says he didn’t mind only one level category, and not mind no “new”/”delete” button. He suggested a very useful feature: filter for categories. He wrote:

I think the most important feature, however, is to be able to filter the notes view by category. For example, in Outlook I have notes which I want to keep but which I don’t want to clutter up the view normally. I have a category called “Obsolete” which I assign to the notes I don’t want to see and my normal default view only displays notes which do not have the Obsolete category.

I am thinking over this. This is a very useful feature I believe, but not clear in details. For example, how to show all notes? KNotes didn’t provide another view of notes. Maybe Kontact can help. Or you must change filter every time. But it’s really a good idea. I am willing to implement it.

Thanks to Jim Philips in kde-linux.
He suggested that KNotes/Kontact can be associated with GTD, a influential time management technique
formalized by David Allen. Last year, there is a SoC KDE project called GTD,
targeted on “make Kontact much more efficient and comfortable as “the system you can trust'’”. And he provide MonkeyGTD as a example for GTD Application. I also found some articles on GTD, which is very helpful for understanding.

2006-05-22

The improvement will effect following class at least:

KNote: Add a item or something other to choose categories.

KNotesApp: Improve the implement of note list( KNotesApp::updateNoteActions, NotesApp::m_noteActions, etc.) . It seems that a big changed using KXMLGUIClient is needed for implement tree. Also a new initialization for single note is needed.

Because categories should be managed, a new config dialog is needed., or we can add a option to KNotesGlobalConfig (knotesglobalConfig.kcfg) .

Are the different default settings needed in different categories? Considerable.

I prefer Method B as the implement method, but not decided yet.

I am planning to carry out the improvement in the following way(something really standard…):
1. Left click on the icon will generate a menu with sub menues(categories). In fact, one note can be displayed under different sub menues.
2. When right click on the icon, you can find a way to manage all categories, like rename. I don’t think the new and delete action is needed here. Because I preferred( so did my mentor ) Method B, which means if there is no note with this tag, the tag won’t exist. I don’t know if it is properly, and if it is can be accepted by most people. But I know the idea of tag is very popular with web2.0 like delicious. At least, I think this method has very good flexibility.
3. When you editing a note, you can setting its tags by right click on the title or something other. The exist tags will be provided to choose, you can also create a tag.

I have send a survey to mailinglist(kdepim-user and kde-linux). I want to know if tags-style can be accepted.

The other thing is about knotes in kontact. I skimmed the source code, and it is seems another story… I am planning to add something like QListWidget for users to choose categories.

2006-05-12

KNotes uses KCal::Journal(which provides a Journal in the sense of RFC2445) to save info. After read RFC2445，I found Journal has some good properties to meet our demands, like “categories”
or “related”. These two property also can occur more than once. That’s perfect.

I summed up the main threads of bug#41341 discussion as following:

1. Taking category as some kind of note, which reduce the amount of change.

2. Using drag and drop to operate the entries(consider later).

I don’t quite agree take category as a note. The most inportant meaning of doing so is that it reduce the change, because some function like “New” or “Rename” can be reused.
But I don’t think so. In fact, I found the functions can be reused may be only “New” ,”Rename”. Surely many function can be override, but many other function like “Delete” will be changed a lot.

Another question is if it is necessary to set up a “ROOT” note as the parent of all notes and categories? Otherwise if you delete a category note and want to save the notes, how can you use same function move these notes to root or to another category? It’s certain that a if can work, but I don’t like it… But if a ROOT note must be added, there will be a extra work on upgrade.

After thinking over the serveral method, I found the focus is on “How to store category information”. There are serveral ways:

Method A:
Using category node. Store related information in parent using property “related”.
Advantage:

1. Some functions can be reused.

2. The structure of logic is very clear.

3. Advanced in the efficiency of most operations.

Disadvantage:

1. Is that a ROOT note needed?

2. In my opinion, most functions must be rewrited all the same.

3. In any case, category is not a note. And no class fit for inherit. Strange feeling…

Method B:
Store related information in notes using property “categories”. In fact, no catagory instance exists.
Advantage:

1. The operation of single note is very easy to implement.

2. The operation of catagory is easy to implement, but low efficiency.

Disadvantage:

1. Maybe a lot of work needed.

2. Not clear structure of logic.

3. Low efficiency(at most o(m*n) in searching).

4. Difficult to implement more than one levels.

5. Can’t keep the sort.

More:
Because there aren’t many notes to deal with, I don’t think the efficiency is very important here.

Method B+:
On the basis of Method B, add temperory catagories instance to assist.
Advantage:

1. High efficiency.

2. Clear structure of logic.

Disadvantage:
How to implement, seems a little complex… Maybe counteract the advantage of Method B.

Method C:
Bring in catagory instance.
Advantage:

1. Very clear structure of logic.

2. High efficiency.

Disadvantage:
How to implement….

The four method below is my initial ideas.