This seems to be not enough. After testing it in "production" I noticed the revision is updated each time knotes program is stopped. It looks like it writes all the notes in the file each time it goes down and revision is updated.

I change the priority to normal from enhance, because it  does not look like normal behavior to change the LAST-MODIFIED field when journal was not modified.

I traced it down to m_editor->isModified() returning true, even if item was not modified.

Test to reproduce this

bool KNote::isModified() const
{
   if (m_editor->isModified())
	kdDebug(5500) << "KNote::isModified()  m_editor->isModified() false"<< endl;
   else
	kdDebug(5500) << "KNote::isModified()  m_editor->isModified() true"<< endl;
    return m_editor->isModified();
}

1. start knotes
2. close a note (being opened) => returns
  knotes: KNote::isModified()  m_editor->isModified() true
3. close knotes => returns for each item
  knotes: KNote::isModified()  m_editor->isModified() true

This is defined in
  /usr/include/tqt3/ntqtextedit.h

to be continued

Hi Emanoil,
it is not a problem to extend dcop interface for a program if the extension is a good addition ;-)
Just note that any extension will go to r14.1.x and not r14.0.x though.

Thank you Michele. 
I raised it against 14.1, so I am aware of this. I would rename the function from getRevision to getLastModified as revision is confusing with SEQUENCE. Until 14.1 I will rebuild from git as I did now.
My problem ATM is why it always updates the LAST-MODIFIED field as mentioned in the bug - editor->isModified returns true.
I'll try to find a better solution and update the patches

(In reply to deloptes from comment #3)
> I traced it down to m_editor->isModified() returning true, even if item was
> not modified.
> 
> Test to reproduce this
> 
> bool KNote::isModified() const
> {
>    if (m_editor->isModified())
> 	kdDebug(5500) << "KNote::isModified()  m_editor->isModified() false"<< endl;
>    else
> 	kdDebug(5500) << "KNote::isModified()  m_editor->isModified() true"<< endl;
>     return m_editor->isModified();
> }
> 
> 1. start knotes
> 2. close a note (being opened) => returns
>   knotes: KNote::isModified()  m_editor->isModified() true
> 3. close knotes => returns for each item
>   knotes: KNote::isModified()  m_editor->isModified() true
> 
> This is defined in
>   /usr/include/tqt3/ntqtextedit.h
> 
> to be continued

Hi my example is obviously wrong, thus the conclusion that m_editor->isModified() returns true

It should be

bool KNote::isModified() const
 {
    if (m_editor->isModified())
 	kdDebug(5500) << "KNote::isModified()  m_editor->isModified()  true"<< endl;
    else
 	kdDebug(5500) << "KNote::isModified()  m_editor->isModified() false"<< endl;
     return m_editor->isModified();
 }

It looks like the LAST-MODIFIED field gets populated internally when calendar/journal is loaded.
On the first write it does overwrite all LAST-MODIFIED.

Created attachment 2690 [details]
patch proposal to extend the knotes interface and fix for the LAST-MODIFIED field

After getting formal OK from Michele I updated the code (instead getRevision I added a method getLastModified). Also I added a fix for the setting of LAST-MODIFIED to current timestamp when saving notes.

The same needs to be done for the knotes_part in kontact, a patch will follow.

Created attachment 2691 [details]
patch proposal to extend the knotes interface and fix for the LAST-MODIFIED field in knotes and kontact notes part

Attached what I believe to be final patch for now.
As before extended the interface to be able to get the last modified
and both knotes and knotes_part in kontact can work on notes without loosing track of the modification time stamp.

regards

an update
This works extremely well. Syncing notes is very reliable so far.
Should I push the change or was it applied already?

Not applied yet, AFAIK.
Let me discuss with Slavek during the coming weekend (possibly).
And again thanks for your contribution ;-)

still nothing done here? Perhaps we could arrange a virtual meeting and have a discussion on pros and cons.
I would say it is important for syncevolution to work (with my plugins)

Emanoil,
can you create a PR on gitea for this? it will be easier to review, to feedback, to modify (if required) and to merge to the main trunk. I would like to finally work on this.
Thanks.

Also what be a good way to test this (before and after)?

I would love to but at the moment I still do not know how to work with Gitea. I did not have the time to read the introduction and so on and my git knowledge is anyway limited.
I simply need to catch up, but time is an issue, so if you are more specific and point me to a link where I could read how to create PR (I guess pull request), it will be nice, otherwise I will look into that in the next week.

regards

And BTW I am using since I created the request. I do not see any disadvantage, but you can decide for yourself perhaps after testing with all those different flavors etc.
It made use of syncevolution very robust - zero issues while syncing all those years.

regards

Hi Emanoil,
see this section of the gitea guide. This is specific for contributors and how to work with PR. As long as your are cloning your repo from gitea (e.g. "origin" points to gitea repo and not main server repo), it should work straight away. 
https://wiki.trinitydesktop.org/TDE_Gitea_Workspace#To_contribute_code_changes

It is good to know you have been using the code for quite a while, it means it is robust :-)

created https://mirror.git.trinitydesktop.org/gitea/TDE/tdepim/pulls/3

The extension of DCOP interface has been merged to R14.1 development branch, so we can consider this bug closed.
Some more work is still required to fix some issues with update of the last modified field in knotes, but this is handled in a separate issue.
https://mirror.git.trinitydesktop.org/gitea/TDE/tdepim/issues/38