« Setting up timeline for soc project
General design of knotes improvement »

Some Thought on KNotes Catagory

Tags:

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. Please tell me your opinion.
    These days I will continue study the source code and method of developing kdepim.

    This entry was posted on Friday, May 12th, 2006 at 8:35 pm and is filed under Open Source. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

    Leave a Reply