GNOME Bugzilla – Bug 627034
Tomboy deletes selected note when you right-click *some other one* and click "Delete"
Last modified: 2011-08-20 20:55:12 UTC
Reported downstream at https://bugs.launchpad.net/ubuntu/+source/tomboy/+bug/617365 Steps to reproduce: 0. Open the Search All Notes window. 1. Select some note by left-clicking it. Let's call it "Note 1". 2. Right-click some other note. Let's call it "Note 2" 3. Pick "Delete" from the menu. What happens: You get the confirmation dialog. When you press ok, "Note 1" is deleted. What should happen: "Note 2" should be deleted. Package: tomboy 1.2.1-0ubuntu1 Architecture: amd64
This is filed as "critical", yet the source says this: // Return true so that the base handler won't // run, which causes the selection to change to // the row that was right-clicked. args.RetVal = true; break; In other words, someone explicitly made sure that the behavior is as it currently is. I guess I could easily revert it. But - should I? Anyone following this bug that knows _why_ this behavior was chosen in the first place?
I filed is as critical, because https://bugzilla.gnome.org/page.cgi?id=fields.html#importance says: Critical Crashes, causes loss of data, or is a severe memory leak Well, this is unexpected and for most people practically irrecoverable loss of data.
I agree and - maybe you misunderstood me - didn't question the severity. I'm just confused because of a critical bug on the one hand vs. the (back then) desired behavior according to the code/comment. Since I'm new(ish) to Tomboy development this report above was mostly to attract The Old Ones to voice an opinion.
Yeah, this is critical (of course, technically, you don't lose data because the note is moved to ~/.local/share/tomboy/Backup , but still...). Benjamin, I don't know why that exists in the code. Maybe it's related to multiple selection right-clicks?
commit dc4685a04 It is related to mutliple selection. Removing it causes the item clicked to become selected/deselected. That means multiple selection doesn't work right without it. I'd say this is by design, because when you right click and hit delete, the item getting deleted is the one highlighted. Visually, we're not doing anything that doesn't make sense. To improve this: On right-click, if we have > 1 items selected, return true (don't change the selection) else if item right-clicked is not selected then change the selection and open the right-click menu else, just open the right-click menu Although, you could argue this behavior is also a bug.
Created attachment 174822 [details] [review] Improvement as suggested above Try this out, from a UI perspective, we're changing the behavior when 1 item is selected vs. multiple items selected. Either way, we're only deleteing the notes that are highlighted.
Created attachment 174851 [details] [review] Name the note being deleted in confirmation dialog Here's another take on this: The issue here is that the user is not clear on which note is being deleted. Visually, the note that is highlighted is being deleted, but there is an expectation that the note they are right-clicking on should be deleted. By including the name of the note in the confirmation, we remove all ambiguity. For multiple notes there's no issue, its pretty clear that if you see "Really delete 7 notes?" that somewhere, 7 notes are highlighted and the user should check to see which those are (in case they have been scrolled off-screen). I prefer this fix to the previous one.
Actually, the first fix makes a lot of sense. I think it really is what we would intuitively expect as a user. Try it out in Nautilus, it works exactly like that: if you right click on a file that is already selected, whether in a multiple selection or not, it stays selected, if you right-click on a file that is not selected, it gets selected. The second patch also makes sense, and it would be good to include it, but I would argue against applying only the second one: haven't we all clicked too quickly every once in a while? IMHO, the text being more precise is nice, but it isn't enough. (Arguably, there shouldn't be any confirmation dialog, and a nicer way to cancel the deletion. See this article on A List Apart[1] and bug #382007 about having a trash in Tomboy[2]). Just my 2c. [1] http://www.alistapart.com/articles/neveruseawarning/ [2] https://bugzilla.gnome.org/382007
Bump: this bug contains a patch with a string change
Review of attachment 174851 [details] [review]: Commit when ok to commit string changes
Review of attachment 174822 [details] [review]: Seems good.
Committed attachment 174851 [details] [review] as 6a3bb1c863cd775e1eb01780460c27d4457ee96d This will appear in the 1.7.4 version of tomboy.