Knotes overwriting LAST-MODIFIED field when loading notes #38

Closed
opened 4 years ago by deloptes · 10 comments
Collaborator

Basic information

  • TDE version: 14.1
  • Distribution: Debian Buster
  • Hardware: amd64

Description

When working on knotes patch it was discovered that knotesapp causes LAST-MODIFIED field to be updated.

Steps to reproduce

  1. Close knotes
  2. Save a copy of notes.ics
  3. Open knotes
  4. Do diff on both files

Screenshots

<!-- This is a comment. Please fill in the required fields below. The comments provide instructions on how to do so. Note: You do not need to remove comments. --> ## Basic information - TDE version: 14.1 - Distribution: Debian Buster - Hardware: amd64 <!-- Use SL/* labels to set the severity level. Please do not set a milestone. --> ## Description When working on knotes patch it was discovered that knotesapp causes LAST-MODIFIED field to be updated. ## Steps to reproduce 1. Close knotes 2. Save a copy of notes.ics 3. Open knotes 4. Do diff on both files ## Screenshots <!-- If it seems useful, please provide provide one or more screenshots. -->
Owner

I think the ics file is updated on exit, not on start. So the correct steps to reproduce should be:

  1. Save a copy of notes.ics
  2. Open knotes
  3. Close knotes
  4. Do diff on both files
I think the ics file is updated on exit, not on start. So the correct steps to reproduce should be: 1. Save a copy of notes.ics 2. Open knotes 3. Close knotes 4. Do diff on both files
Poster
Collaborator

I was also thinking the same - but the work around shows it is when loading - also the debug I did shows setLastModified() is called 2-3 times when loading.

I was also thinking the same - but the work around shows it is when loading - also the debug I did shows setLastModified() is called 2-3 times when loading.
Owner

Nope, I just tested it again. The ics file is definetely modified when knotes is closed.

Probably the value is updated on loading as you have described (when title or content of the knote widget is set) and later saved to file when the program is closed.

Anyhow we are talking about the same issue 😄

Nope, I just tested it again. The ics file is definetely modified when knotes is closed.<br/> Probably the value is updated on loading as you have described (when title or content of the knote widget is set) and later saved to file when the program is closed.<br/> Anyhow we are talking about the same issue :smile:
Poster
Collaborator

It is setting also colors - may be this is root cause. I checked the text and title.

It is setting also colors - may be this is root cause. I checked the text and title.
Poster
Collaborator

Try adding debug around the loading and also in the ikcal when calling setLastModified.

You will see when the loading is done it also calls the setLastModified().

It might be I am wrong as I observed this when working on the patch, of course, but I am wuite sure this was the reason for the workaround at that place.

Unfortunately the code is spagetti and not easy to read - at least for me.

thank you in advance

Try adding debug around the loading and also in the ikcal when calling setLastModified. You will see when the loading is done it also calls the setLastModified(). It might be I am wrong as I observed this when working on the patch, of course, but I am wuite sure this was the reason for the workaround at that place. Unfortunately the code is spagetti and not easy to read - at least for me. thank you in advance
Owner

I will take a look during the week, want to close this point quickly if we can 😄

I will take a look during the week, want to close this point quickly if we can :smile:
Owner

I will take a look during the week, want to close this point quickly if we can 😄

I will take a look during the week, want to close this point quickly if we can :smile:
Poster
Collaborator

This is my experiment
(added debug in setLastModified in libikcal) and in resource local.

Seems that manager()->registerNote( this, *it ); is triggereing this.


bool ResourceLocal::load()
{
    kdDebug(5500) << k_funcinfo << endl;
    mCalendar.load( mURL.path() );

    KCal::Journal::List notes = mCalendar.journals();
    KCal::Journal::List::ConstIterator it;
    for ( it = notes.constBegin(); it != notes.constEnd(); ++it ) {
        kdDebug(5500) << (*it)->lastModified() << endl;
        manager()->registerNote( this, *it );
        kdDebug(5500) << (*it)->lastModified() << endl;
    }

    return true;
}

[knotes] Fri Feb 21 00:09:22 2020
[knotes] [void KNotesResourceManager::registerNote(ResourceNotes*, KCal::Journal*)]
[knotes] [void KNotesApp::createNote(KCal::Journal*)]
[knotes] [KNote::KNote(TQDomDocument, KCal::Journal*, TQWidget*, const char*)]
[knotes] [void KNote::setName(const TQString&)]
[knotes] [void KNote::updateLabelAlignment()]
[knotes] [virtual bool KNote::event(TQEvent*)]
[knotes] [void KNote::slotApplyConfig()]
[knotes] [void KNote::setColor(const TQColor&, const TQColor&)]
[libkcal] [void KCal::IncidenceBase::setLastModified(const TQDateTime&)]
[libkcal] [void KCal::IncidenceBase::setLastModified(const TQDateTime&)]
[libkcal] [void KCal::IncidenceBase::setLastModified(const TQDateTime&)]
[knotes] [TQString KNote::noteId() const]
[knotes] [virtual bool KNote::event(TQEvent*)]
[knotes] [void KNote::updateBackground(int)]
[knotes] [void KNote::createFold()]
[knotes] [void KNote::updateFocus()]
[knotes] [void KNote::updateLabelAlignment()]
[knotes] [void KNote::slotUpdateShowInTaskbar()]
[knotes] [void KNote::slotUpdateReadOnly()]
[knotes] [void KNote::updateFocus()]
[knotes] [void KNote::slotUpdateKeepAboveBelow()]
[knotes] [virtual bool KNote::event(TQEvent*)]
[knotes] [TQString KNote::noteId() const]
[knotes] Fri Feb 21 00:34:20 2020
This is my experiment (added debug in setLastModified in libikcal) and in resource local. Seems that `manager()->registerNote( this, *it );` is triggereing this. ``` bool ResourceLocal::load() { kdDebug(5500) << k_funcinfo << endl; mCalendar.load( mURL.path() ); KCal::Journal::List notes = mCalendar.journals(); KCal::Journal::List::ConstIterator it; for ( it = notes.constBegin(); it != notes.constEnd(); ++it ) { kdDebug(5500) << (*it)->lastModified() << endl; manager()->registerNote( this, *it ); kdDebug(5500) << (*it)->lastModified() << endl; } return true; } [knotes] Fri Feb 21 00:09:22 2020 [knotes] [void KNotesResourceManager::registerNote(ResourceNotes*, KCal::Journal*)] [knotes] [void KNotesApp::createNote(KCal::Journal*)] [knotes] [KNote::KNote(TQDomDocument, KCal::Journal*, TQWidget*, const char*)] [knotes] [void KNote::setName(const TQString&)] [knotes] [void KNote::updateLabelAlignment()] [knotes] [virtual bool KNote::event(TQEvent*)] [knotes] [void KNote::slotApplyConfig()] [knotes] [void KNote::setColor(const TQColor&, const TQColor&)] [libkcal] [void KCal::IncidenceBase::setLastModified(const TQDateTime&)] [libkcal] [void KCal::IncidenceBase::setLastModified(const TQDateTime&)] [libkcal] [void KCal::IncidenceBase::setLastModified(const TQDateTime&)] [knotes] [TQString KNote::noteId() const] [knotes] [virtual bool KNote::event(TQEvent*)] [knotes] [void KNote::updateBackground(int)] [knotes] [void KNote::createFold()] [knotes] [void KNote::updateFocus()] [knotes] [void KNote::updateLabelAlignment()] [knotes] [void KNote::slotUpdateShowInTaskbar()] [knotes] [void KNote::slotUpdateReadOnly()] [knotes] [void KNote::updateFocus()] [knotes] [void KNote::slotUpdateKeepAboveBelow()] [knotes] [virtual bool KNote::event(TQEvent*)] [knotes] [TQString KNote::noteId() const] [knotes] Fri Feb 21 00:34:20 2020 ```
Owner

Emanoil, I have prepared PR #40 where I propose a different solution rather than a workaround. This consist in avoiding to incorrectly update the journal when loading a note from an .ics file.

I have tested locally, appreciate if you could test as well before we proceed with a merge.

EDIT: more work is required for fixing Kontact too.

Emanoil, I have prepared PR #40 where I propose a different solution rather than a workaround. This consist in avoiding to incorrectly update the journal when loading a note from an .ics file.<br/> I have tested locally, appreciate if you could test as well before we proceed with a merge. EDIT: more work is required for fixing Kontact too.
Owner

Fixed by PR #40.

Fixed by PR #40.
MicheleC closed this issue 4 years ago
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

No dependencies set.

Reference: TDE/tdepim#38
Loading…
There is no content yet.