GNOME Bugzilla – Bug 508798
Changing Notebook in Search All marks Note as used
Last modified: 2008-02-26 20:51:49 UTC
Please describe the problem: When I updated to 0.9.3 I wanted to make use of the new Notebook feature and I created a few Notebooks. I wanted to categorize my notes, so I opened up Search All and started drag and droping notes over the notebooks. The problem is that once I drop a note over a notebook Tomboy would mark it as used, refresh the notes list and put the note on top. I have not used the note and I haven't opened it why should it do that? That made sorting my notes very hard because I couldn't go linearly through the list because Tomboy would change the notes order + will refresh the list so I have to scroll down again and find the next note by memory. Steps to reproduce: Actual results: Expected results: Does this happen every time? Other information:
Yeah, this is definitely a problem we need to resolve soon. I think it's just going to be a matter of making sure that when we add a new system tag (that tomboy uses for notebooks) does not mark the note as "content changed." Thanks for reporting this.
We should be careful about how we fix this bug. It's important that Tomboy can internally know that the note has changed when it moves between Notebooks (for sync purposes, if nothing else). But I do agree that having the recent notes list reorder as you organize your notes is a pain in the ass. Do we need multiple "last changed" dates stored in a note? One for data and one for content?
Created attachment 102635 [details] [review] fix This patch fixes the issue I had by doing two things: 1) Do not mark set content_changed when tags are added and removed from the note. This means that the Note.ChangeDate will not be updated. IMHO that's the correct behavior, because modifying the tags doesn't mean modifying the note. This will prevent the note order changing when the tree is sorted by "Last Changed". 2) When the notes tree is refreshed in addition to restoring the selected note it will also scroll to it. :) Tell me what do you think?
2) is good, but 1) will cause problems for sync. As mentioned before, we might need to resort to having each note have a DataChangeDate and ContentChangeDate, instead of just ChangeDate. I will look at this before Monday's release.
(In reply to comment #4) > 2) is good, but 1) will cause problems for sync. > > As mentioned before, we might need to resort to having each note have a > DataChangeDate and ContentChangeDate, instead of just ChangeDate. > > I will look at this before Monday's release. > I understand the issues this poses for sync, but I'd be cautious about adding too much complexity with change dates/etc. If it's the only way to do it, then alas, fine. Could we preserve ChangeDate as-is and add a "needs sync" flag (thinking out loud). Maybe this isn't much better, but at least it wouldn't cause confusion between what's data and what's content.
(In reply to comment #5) > I understand the issues this poses for sync, but I'd be cautious about adding > too much complexity with change dates/etc. If it's the only way to do it, then > alas, fine. Could we preserve ChangeDate as-is and add a "needs sync" flag > (thinking out loud). Maybe this isn't much better, but at least it wouldn't > cause confusion between what's data and what's content. I definitely agree that adding a second date to the note is not exactly beautiful. In the context of tags, though, changing a note's notebook represents an important change to the note. That needs to be reflected somehow, and not just for sync (dbus clients might care, etc). I'll explore several options, and make sure to post patches here before committing anything. And to be clear...I would envision ChangeDate staying as-is in the XML (for backward compatibility, at least), and adding a second date property to the note, if we were to follow my original suggestion.
(In reply to comment #3) > 2) When the notes tree is refreshed in addition to restoring the selected note > it will also scroll to it. :) This works great when adding/modifying notes causes the list to update, but it has no effect when searching. Do you think it should, or no?
(In reply to comment #7) > (In reply to comment #3) > > 2) When the notes tree is refreshed in addition to restoring the selected note > > it will also scroll to it. :) > > This works great when adding/modifying notes causes the list to update, but it > has no effect when searching. Do you think it should, or no? > IMHO it shouldn't. Currently focused item is not important for the search and scrolling to focus it doesn't make sense.
Okay, I committed that part of the patch in r1771.
Created attachment 102824 [details] [review] One way to fix the problem. Add another date. This adds a MetadataChangeDate property to Note and NoteData and a "last-metadata-change-date" element to the note XML. QueueSave takes in an enumerations specifying the change type (content/other/no). MetadataChangeDate is always >= ChangeDate. Sync uses it instead of ChangeDate. When a tag is applied/removed, it calls QueueSave and passes in "other". I did some rudimentary testing and this works fine. I can't say it's exactly elegant, though. I didn't have time to try any other approaches.
Oh, and I forgot to mention...with the change date fixed, I found the auto-scrolling patch behavior kind of irritating. I drag a note onto a notebook, and although the order of the list doesn't change, the location of everything does because it scrolls to the selected note. I think we can probably remove that behavior once the change date thing is fixed?
(In reply to comment #11) > Oh, and I forgot to mention...with the change date fixed, I found the > auto-scrolling patch behavior kind of irritating. I drag a note onto a > notebook, and although the order of the list doesn't change, the location of > everything does because it scrolls to the selected note. I think we can > probably remove that behavior once the change date thing is fixed? > Location changes, but order not? I don't quite understand. There should be no visual change when someone adds a note to a notebook. If there is then that's a bug.
(In reply to comment #12) > (In reply to comment #11) > > Oh, and I forgot to mention...with the change date fixed, I found the > > auto-scrolling patch behavior kind of irritating. I drag a note onto a > > notebook, and although the order of the list doesn't change, the location of > > everything does because it scrolls to the selected note. I think we can > > probably remove that behavior once the change date thing is fixed? > > > > Location changes, but order not? I don't quite understand. There should be no > visual change when someone adds a note to a notebook. If there is then that's a > bug. The list is commanded to refresh itself, and when it does, it automatically scrolls to the selected note. That's what I meant when I said the location changes. I can no longer think of any scenario where it would be useful for the list to automatically scroll to the selected note. Or am I forgetting something?
(In reply to comment #13) > (In reply to comment #12) > > (In reply to comment #11) > > > Oh, and I forgot to mention...with the change date fixed, I found the > > > auto-scrolling patch behavior kind of irritating. I drag a note onto a > > > notebook, and although the order of the list doesn't change, the location of > > > everything does because it scrolls to the selected note. I think we can > > > probably remove that behavior once the change date thing is fixed? > > > > > > > Location changes, but order not? I don't quite understand. There should be no > > visual change when someone adds a note to a notebook. If there is then that's a > > bug. > > The list is commanded to refresh itself, and when it does, it automatically > scrolls to the selected note. That's what I meant when I said the location > changes. > > I can no longer think of any scenario where it would be useful for the list to > automatically scroll to the selected note. Or am I forgetting something? > Please reread the second part of paragraph 2 of the inital bug description. :)
(In reply to comment #14) > (In reply to comment #13) > > (In reply to comment #12) > > > (In reply to comment #11) > > > > Oh, and I forgot to mention...with the change date fixed, I found the > > > > auto-scrolling patch behavior kind of irritating. I drag a note onto a > > > > notebook, and although the order of the list doesn't change, the location of > > > > everything does because it scrolls to the selected note. I think we can > > > > probably remove that behavior once the change date thing is fixed? > > > > > > > > > > Location changes, but order not? I don't quite understand. There should be no > > > visual change when someone adds a note to a notebook. If there is then that's a > > > bug. > > > > The list is commanded to refresh itself, and when it does, it automatically > > scrolls to the selected note. That's what I meant when I said the location > > changes. > > > > I can no longer think of any scenario where it would be useful for the list to > > automatically scroll to the selected note. Or am I forgetting something? > > > > Please reread the second part of paragraph 2 of the inital bug description. :) Right, but assuming that the note is not marked as changed when you organize it in notebooks, then that problem will not occur. So assuming that's fixed, I can't think of *another* scenario which would require the auto-scrolling feature.
This bug sucks, but it doesn't necessarily need to be fixed by feature freeze. Retargetting for 0.9.x.
FWIW, I inadvertently commented out ScrollToIter for the time being. Let's re-evaluate ScrollToIter once we've got this sorted out.
Fix committed in r1876, based on my earlier patch.