Closed
Bug 954815
Opened 11 years ago
Closed 11 years ago
Unread ruler confusing when coming back to conversation with no new messages
Categories
(Instantbird Graveyard :: Conversation, defect)
Instantbird Graveyard
Conversation
Tracking
(Not tracked)
RESOLVED
FIXED
1.2
People
(Reporter: benediktp, Assigned: aleth)
Details
Attachments
(1 file, 2 obsolete files)
2.16 KB,
patch
|
benediktp
:
review+
|
Details | Diff | Splinter Review |
*** Original post on bio 1380 at 2012-04-16 10:23:00 UTC *** The unread ruler is only moved when there were new messages between now and previous focusing of the conversation. If there were no new messages, I run into the following problem: coming back to the window and still finding it there makes me look at the messages below only to notice that I already know them. I think we should remove it if the ruler and all 'new' messages were visible before already.
Assignee | ||
Comment 1•11 years ago
|
||
*** Original post on bio 1380 at 2012-04-17 09:07:11 UTC *** It's probably not that easy to track whether the user has scrolled past the ruler. Simpler alternatives up for discussion (apart from the current behaviour): - remove the ruler whenever the window loses focus - remove the ruler whenever the window loses focus and the ruler is visible on the screen
Reporter | ||
Comment 2•11 years ago
|
||
*** Original post on bio 1380 at 2012-04-17 09:39:19 UTC *** (In reply to comment #1) > It's probably not that easy to track whether the user has scrolled past the > ruler. > > Simpler alternatives up for discussion (apart from the current behaviour): > > - remove the ruler whenever the window loses focus > > - remove the ruler whenever the window loses focus and the ruler is visible on > the screen I should have written: "I think we should remove it if the ruler and all 'new' messages were visible _at once_ already." i.e. your second case with the condition that the conversation wasn't scrolled up.
Comment 3•11 years ago
|
||
*** Original post on bio 1380 at 2012-04-17 10:16:09 UTC *** Another alternative: - remove the ruler when the window gains focus again but the "unread" messages have actually been read already. (This avoids the visual distraction of the content of a window loosing focus jumping around.)
Assignee | ||
Comment 4•11 years ago
|
||
*** Original post on bio 1380 at 2012-04-17 15:51:20 UTC *** (In reply to comment #3) > Another alternative: > - remove the ruler when the window gains focus again but the "unread" messages > have actually been read already. (This avoids the visual distraction of the > content of a window loosing focus jumping around.) I'm not sure this is a good idea because if the idea of this bug is to avoid a window that has lost focus having a visible unread ruler until there are actually new messages again, then this will not help (e.g. if a window is partially covered). And I suspect it would be less distracting to remove it when one is switching _away_ from the window as the user's attention is already elsewhere.
Comment 5•11 years ago
|
||
*** Original post on bio 1380 at 2012-04-17 15:59:44 UTC *** (In reply to comment #4) > the user's attention is already elsewhere. The user's attention is elsewhere until something moves ;). Note: I don't mind much either way, so don't take the above comment as a strong objection.
Assignee | ||
Comment 6•11 years ago
|
||
*** Original post on bio 1380 at 2012-04-17 16:03:00 UTC *** (In reply to comment #5) > (In reply to comment #4) > > > the user's attention is already elsewhere. > > The user's attention is elsewhere until something moves ;). > > Note: I don't mind much either way, so don't take the above comment as a strong > objection. It's the sort of thing that needs experimentation ;) I wasn't sure about what to do when I put in the current behaviour. The argument for the current behaviour is that you wouldn't lose the ruler if you came back to your PC, IB had focus, but you switched away to check your email or something first before looking at new messages.
Comment 7•11 years ago
|
||
*** Original post on bio 1380 at 2012-04-17 16:35:04 UTC *** (In reply to comment #1) > It's probably not that easy to track whether the user has scrolled past the > ruler. > > Simpler alternatives up for discussion (apart from the current behaviour): > > - remove the ruler whenever the window loses focus Personally I'd like this, but I'd be OK with when the window gains focus again too.
Assignee | ||
Comment 8•11 years ago
|
||
*** Original post on bio 1380 as attmnt 1371 at 2012-04-18 23:47:00 UTC *** This removes the ruler if it is visible when the window loses focus. Removing the ruler when the window gains focus doesn't add movement when switching away from the window, but it doesn't actually fix the issue Mic originally complained about ("when I see an unread ruler I think there are new messages") and seemed odd in testing. To avoid visible movement I suspect the current behaviour is best. This patch seems an improvement, but I'm not 100% sure about the visibility-testing if clause (in a sense it would be more consistent to always remove the ruler, but when it's not on the screen it's more jarring to potentially see messages move).
Attachment #8353124 -
Flags: review?(benediktp)
Assignee | ||
Comment 9•11 years ago
|
||
*** Original post on bio 1380 at 2012-04-19 00:09:04 UTC *** (to clarify, by "current behaviour" I meant that from bug 954293 (bio 860), not this patch)
Assignee | ||
Comment 10•11 years ago
|
||
*** Original post on bio 1380 as attmnt 1406 at 2012-04-26 12:43:00 UTC *** Alternative patch that simply removes the ruler when the window loses focus. I think this is probably more consistent behaviour for the user. Having used this for a while, I think either this patch or the other one is a definite improvement over the present behaviour. Leaving the choice up to the reviewer :)
Attachment #8353159 -
Flags: review?(benediktp)
Assignee | ||
Updated•11 years ago
|
Assignee: nobody → aleth
Status: NEW → ASSIGNED
Reporter | ||
Comment 11•11 years ago
|
||
*** Original post on bio 1380 as attmnt 1462 at 2012-05-11 09:42:00 UTC *** I've used this patch for a while and it seemed to work as I expected. The code looks fine, too. I attached a new diff, with line numbers matching the file on HG now, so the patch should apply easily. If there's a way to make hg import an otherwise good patch that has just wrong line numbers, don't hesitate to let me know. Thanks for fixing this!
Attachment #8353215 -
Flags: review+
Reporter | ||
Comment 12•11 years ago
|
||
Comment on attachment 8353124 [details] [diff] [review] Patch *** Original change on bio 1380 attmnt 1371 at 2012-05-11 09:42:48 UTC was without comment, so any subsequent comment numbers will be shifted ***
Attachment #8353124 -
Attachment is obsolete: true
Attachment #8353124 -
Flags: review?(benediktp)
Reporter | ||
Comment 13•11 years ago
|
||
Comment on attachment 8353159 [details] [diff] [review] Alternative patch *** Original change on bio 1380 attmnt 1406 at 2012-05-11 09:42:48 UTC was without comment, so any subsequent comment numbers will be shifted ***
Attachment #8353159 -
Attachment is obsolete: true
Attachment #8353159 -
Flags: review?(benediktp)
Reporter | ||
Updated•11 years ago
|
Whiteboard: [checkin-needed]
Comment 14•11 years ago
|
||
*** Original post on bio 1380 at 2012-05-16 15:58:32 UTC *** https://hg.instantbird.org/instantbird/rev/1167b92422a8
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Whiteboard: [checkin-needed]
Target Milestone: --- → 1.2
You need to log in
before you can comment on or make changes to this bug.
Description
•