Highlight lines coming into view when scrolling
Needs ReviewPublic

Authored by thsurrel on May 6 2019, 8:31 PM.

Details

Reviewers
hindenburg
tcanabrava
Group Reviewers
Konsole
VDG
Summary

When scrolling or searching in a terminal with lots of
repeating lines it can be difficult to keep track by how much
the view has been moved when scrolling.
This is a proposal to add a profile option that would, when
enabled, highlight the lines that are scrolled into view.

Test Plan

Open the profile settings and enable the highlighting option
in the Scrolling section.
Move the terminal up or down using the keyboard, the scroll
bars or by searching.

Diff Detail

Repository
R319 Konsole
Branch
arc_highlight
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 11614
Build 11632: arc lint + arc unit
thsurrel created this revision.May 6 2019, 8:31 PM
Restricted Application added a project: Konsole. · View Herald TranscriptMay 6 2019, 8:31 PM
Restricted Application added a subscriber: konsole-devel. · View Herald Transcript
thsurrel requested review of this revision.May 6 2019, 8:31 PM
thsurrel edited the test plan for this revision. (Show Details)May 6 2019, 8:31 PM

@ngraham as this needs input from the VDG
I personally love the idea, I would change the half of the page dimm effect by a thin line on the side (like kdevelop shows for edited lines)

I tried several things, this full-size dimming was the option I liked best, but I am opened to other ideas of course.
VDG input will be usefull indeed.

thsurrel added a reviewer: VDG.May 8 2019, 9:22 AM

When I test this patch on dmesg output, I only see the top or bottom two lines becoming highlighted in this way. Is this intentional? Or am I doing something wrong? Or is it buggy with this output?

src/EditProfileScrollingPage.ui
227

Remove the word "the" from this

Oh hmm, that was only with my wheel mouse. With touchpad scrolling I see more lines highlighted.

To be honest I don't feel like this is very useful. But maybe I'm not using it right? Or maybe we should step back consider alternative ways to solve the problem as stated in the description.

mglb added a subscriber: mglb.May 16 2019, 1:45 AM

Maybe like this?


Fading out solves additional use cases:

  • something sometimes outputs always the same line (debug message) to a terminal. Does it spams the line in a loop right now, or I'm looking at previous lines? (for this the feature would need to work for new lines too)
  • Repeated scrolling is distinguishable

With indicator on a side instead of full lines animation should be lightweight.

For a search, or bigger jumps in general, semi-smooth scroll (like 0→50 scroll above, but faster) could be nice (or annoying, I'm not sure yet). But thats something for separate and independent feature.

I can see how this could be useful. If we use the current visual effect, we'll have issues w/ different colors (ie the fade not being easily seen). Perhaps the side visual might be better? At one time, there's a wish to have the scroll bar similar to Kate in that it shows a representation of what's in the window in the scrollbar.

Hi everyone,
I would like to carry on working on this patch, I keep compiling my own version of konsole just for it. This patch is very valuable in situations where I have to go through logs with _very_ similar lines (which happens quite too often for my job) and I need to keep precise track of where I am while navigating. As Nate pointed it, this is not so useful when scrolling one line at a time, but when using the half-page jump with Ctrl-PageUp/PageDown, it becomes essential to have a visual hint of what lines have come into view.

In D21055#465869, @mglb wrote:


Fading out solves additional use cases:

  • something sometimes outputs always the same line (debug message) to a terminal. Does it spams the line in a loop right now, or I'm looking at previous lines? (for this the feature would need to work for new lines too)
  • Repeated scrolling is distinguishable

This looks really nice and would indeed make this patch useful in the case of scrolling. But fading based on a timer would kill the main feature I see in this: having a visual reference to be able to see what has moved. Maybe we have to find something in between the original proposal and this. What do you think ?

Other question: should I keep this on Phabricator ?

mglb added a comment.Oct 31 2019, 1:54 AM

This looks really nice and would indeed make this patch useful in the case of scrolling. But fading based on a timer would kill the main feature I see in this: having a visual reference to be able to see what has moved. Maybe we have to find something in between the original proposal and this. What do you think ?

What about: quickly fade down to e.g. 50%, keep this for N seconds (configurable, up to infinity) or until next scroll happen, then fade to 0%? This should solve your problem (new lines are marked as long as you want) and indicate that new scroll happened.

You can use phabricator for now if that works for you - setting up a merge request https://invent.kde.org/kde/konsole/merge_requests would also work. Until phabricator is removed, it is up to you which patch is easier to maintain.