GNOME Bugzilla – Bug 740132
Don't trigger the overshoot indicator when getting to the top of message log
Last modified: 2021-06-10 11:04:46 UTC
Currently Polari is triggering the "overshoot indicator", hinting the user that he/she reached the top of the scroll buffer. But in fact it hasn't as it's loading older messages at that point and extends the scrollback. I think if we're trying to load a chunk, we should not trigger this visual feedback and prepend a line with content-loading-symbolic in the middle, instead and replace it with the chunk on success. Only if this fails and we can no longer load previous chunk, we should trigger "you've reached the top" rather than trying to load another one. Carlos hinted there is an edge-overshot signal in GtkScrolledWindow that might help.
Created attachment 291952 [details] [review] chatView: Fix handling of smooth scroll events Gdk.Event.get_scroll_direction() helpfully does not return a scroll direction of SMOOTH for smooth scroll events, but UP, which messes with our filtering out all non-UP scroll events. Make the filtering more explicit to take this case into account.
Created attachment 291953 [details] [review] chatView: Block overshoot when fetching logs GTK+ now displays an "overshoot indicator" when the users scrolls past the top/bottom to indicate the end of the buffer. However while we have history to load, scrolling past the top will prepend to the buffer - indicate that we are not at the end in that case by suppressing the overshoot indicator.
Created attachment 291954 [details] [review] chatView: Display a loading indicator while fetching backlog Provide some feedback to the user that we are fetching logs by displaying a line with a 'content-loading' icon while we are waiting for the result.
(In reply to comment #0) > Carlos hinted there is an edge-overshot signal in GtkScrolledWindow that might > help. It doesn't in its current form. If we didn't mind the overshoot indicator, we could use the signal to detect when to load history rather than tracking scrolling ourselves. As it stands, it does not allow us to suppress the overshoot indication, and as suppressing the indicators also blocks the signal, we cannot use it for history loading either. I'll see if there's interest on the GTK+ side to cover that use case, if not the attached patches should do the job ...
(In reply to comment #4) > (In reply to comment #0) > > Carlos hinted there is an edge-overshot signal in GtkScrolledWindow that might > > help. > > It doesn't in its current form. If we didn't mind the overshoot indicator, we > could use the signal to detect when to load history rather than tracking > scrolling ourselves. I think some edge resistance is due in ::edge-overshot, on one hand it's implicit in the name (meh...), on the other hand it doesn't trigger as accidentally and is a behavior that can be seen in other platforms/UIs. As such, the overshoot indicator here serves as an hint of how far you're reaching, something you lose if there's no indication whatsoever :(. If the entire point of edge resistance is moot here, polari should do better with adjustment value tracking. One middle ground I suggest is making the signal return a boolean, so if the handler returns TRUE, overshoot indicator disappears and the app is free to do delayed loading. This still doesn't fix the differentiation of edges with an action though...
(In reply to comment #5) > As such, the overshoot indicator here serves as an hint of how far you're > reaching, something you lose if there's no indication whatsoever :(. It's not about not having any indication whatsoever, it is about showing a different indication - there's a difference between "you have reached the end, nothing more here" and "you have reached the start of the currently loaded content, let me fetch some more". > If the entire point of edge resistance is moot here, polari should do better > with adjustment value tracking. It is not primarily about edge resistance, but I do think that it is better (because more explicit as you said earlier). > One middle ground I suggest is making the signal return a boolean, so if the > handler returns TRUE, overshoot indicator disappears and the app is free to do > delayed loading. Ideally (for my use case here) the signal behaved like event signals, returning TRUE would stop other event handlers from being run, and the default handler would be resposible for showing the (normal) overshoot indicator. > This still doesn't fix the differentiation of edges with an > action though... What do you mean? The signal already has an "edge_pos" parameter, so I don't see an issue here (I actually did move to the signal originally, but as there's not way of suppressing the indicator at the moment, I then moved back to this patch series) Anyway, pushing for now, but leaving the bug open in case the GTK+ API allows us to use the GtkWindow::edge-overshot signal in the future ... Attachment 291952 [details] pushed as b6181d5 - chatView: Fix handling of smooth scroll events Attachment 291953 [details] pushed as f498bd6 - chatView: Block overshoot when fetching logs Attachment 291954 [details] pushed as 649e750 - chatView: Display a loading indicator while fetching backlog
(In reply to comment #6) > > As such, the overshoot indicator here serves as an hint of how far you're > > reaching, something you lose if there's no indication whatsoever :(. > > It's not about not having any indication whatsoever, it is about showing a > different indication - there's a difference between "you have reached the end, > nothing more here" and "you have reached the start of the currently loaded > content, let me fetch some more". Nod, I guess I misintepreted with the "suppress the overshoot indication" bit in comment #4 :) > > > > If the entire point of edge resistance is moot here, polari should do better > > with adjustment value tracking. > > It is not primarily about edge resistance, but I do think that it is better > (because more explicit as you said earlier). > > > > One middle ground I suggest is making the signal return a boolean, so if the > > handler returns TRUE, overshoot indicator disappears and the app is free to do > > delayed loading. > > Ideally (for my use case here) the signal behaved like event signals, returning > TRUE would stop other event handlers from being run, and the default handler > would be resposible for showing the (normal) overshoot indicator. Thing here is that the signal just notifies of the end of the action, it looks like you want: gboolean (* overshoot_progress) (GtkScrolledWindow *sw, GtkPositionType pos, gdouble progress); with something like that in place, edge-overshot may stay with the purpose supposedly had (merely triggering actions). > > > > This still doesn't fix the differentiation of edges with an > > action though... > > What do you mean? The signal already has an "edge_pos" parameter, so I don't > see an issue here (I actually did move to the signal originally, but as there's > not way of suppressing the indicator at the moment, I then moved back to this > patch series) That remark was done assuming that the signal is just emitted at the end of the action, so there'd be still no way for the caller to actually supress the indicators mid-action.
(In reply to comment #7) > (In reply to comment #6) > > Ideally (for my use case here) the signal behaved like event signals, returning > > TRUE would stop other event handlers from being run, and the default handler > > would be resposible for showing the (normal) overshoot indicator. > > Thing here is that the signal just notifies of the end of the action, it looks > like you want: > > gboolean (* overshoot_progress) (GtkScrolledWindow *sw, GtkPositionType pos, > gdouble progress); > > with something like that in place, edge-overshot may stay with the purpose > supposedly had (merely triggering actions). So GtkScrolledWindow::overshoot-progress could be used whether the overshoot indicator should (still) be shown, and ::edge-overshot would always be emitted regardless of whether the indicator is visible? That would work for me, sure ... I do wonder if a simpler gboolean (* show_overshot_indicator) (GtkScrolledWindow *ws, GtkPositionType pos); would do as well though - I can't really think of a use case for changing the indicators' visibility half-way through (either way), so just having a single signal emission should be good enough (it would also be a good place to show the alternative indicator in case the normal one is suppressed).
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version of Polari, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/polari/-/issues/ Thank you for your understanding and your help.