GNOME Bugzilla – Bug 708682
Move with 'End' key with collapsed threads fails
Last modified: 2013-09-30 16:30:48 UTC
Moving this from a downstream bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1010763 When my messages are grouped by threads, and the threads are closed, I cannot use the end key to get to the latest message thread. It works just fine if I expand all my threads. This is sort of a regression. I'm quite sure I could use the end key to get the the latest message irrespective of whether my threads were open or closed in F19. Version-Release number of selected component (if applicable): [asinha@ankur ~]$ rpm -qa \*evolution\* evolution-3.9.92-1.fc20.x86_64 evolution-data-server-3.9.92-1.fc20.x86_64 evolution-ews-3.9.92-1.fc20.x86_64 [asinha@ankur ~]$ How reproducible: Always Steps to Reproduce: 1.Collapse threads 2.Hit "end" key to go to latest message/thread 3. Actual results: Nothing happens. No movement at all. Expected results: Should go to latest thread, or lowest in the view depending on how it's sorted. Additional info: A one key "go to latest message/thread" is really handy :) ------------------------------------------------------------------------- In my F20 system here, the end key does not go to the last row (either last shown or last in the folder) if the threads are collapsed. The thread isn't supposed to be expanded on it's own. The bug is that the end key doesn't do *anything* when threads are collapsed.
This is caused by a fix for bug #702006.
Created attachment 255624 [details] [review] evo patch for evolution; This returns back the relevant part. I tested it, and I do not see count issues in the mail view. Matthew, by any chance, do you recall where you saw this count misbehaviour, or what led you to change this particular function, please?
It was for bug 702006. To resolve this without regressing either bug, I think ESelectionModel needs to have separate row_count() and visible_row_count() methods. For ETableSelectionModel the methods are equivalent, but for ETreeSelectionModel the row_count() method should include collapsed rows in its count.
(In reply to comment #2) > Matthew, by any chance, do you recall where you saw this count misbehaviour, or > what led you to change this particular function, please? ^^^ I didn't notice the count misbehaviour in the mail view, thus I'm wondering where you saw it, and/or why you did the change in this part.
I retested the change and I do not see any regression in message counts, thus I moved ahead and committed the change. Created commit 69e3c86 in evo master (3.11.1+) Created commit 1964f92 in evo gnome-3-10 (3.10.1+)