I'd appreciate knowing which commits are responsible for this new behaviour so I can look into a fix or even a local workaround.

See bug 425408 comment 3 for the commit.

*** This bug has been marked as a duplicate of bug 425408 ***

Configure Profile -> Scrolling -> Unmark "Highligth lines comming into view", but be assured that the new behavior with the blue line comming to view is really userful, and not a bug but intended behavior.

I was wondering if this wasn't a feature. Thing is, I don't see what it is useful for except for Konsole devs, so why turn it on automatically?

Turning off the feature also got rid of the margin issue, thank goodness.

FWIW: adding a timer so the bar disappears even without a viewport refresh would make it clear that this is a feature. As it is it can disappear for no apparent reason (for more casual users) esp. when focus-follows-mouse is on.

Well, I don't use this while developing konsole, but to scroll trough compilation  errors or log files when I'm reading. sometimes the text is too similar and it's hard to keep track what scrolled, so this helps me.
The enabled on by default is to encourage people to test the features, as most of the features - if off bu default - will not be visible to users.

That's called change blindness and it's a real thing, but apparently not so much in terminal emulators. I've been trying a whole bunch of those recently and if they offer the feature it's off by default. Not too surprising either, because change blindness usually occurs only when you do not induce change yourself, as with scrolling.

Turning new features on by default is a good idea if they're not intrusive and likely to be useful for a majority of the user population and don't look like a weird bug. How would you feel if someone added a "reset to default" feature to the profile settings dialog and turned that on by default because it's useful to review your settings during an upgrade ... or would you prefer to get a suggestion to do so (as I think vlc still does after an upgrade)?

Created attachment 131022 [details]
attachment-9748-0.html

We are thinking in adding for next version the information of what changed
on first run, so this will not happen again, I mean, things will be
implemented, and enabled by default - but we will showcase them before the
app runs, with luck this is approved.

On Wed, 19 Aug 2020 at 20:52 RJVB <bugzilla_noreply@kde.org> wrote:

> https://bugs.kde.org/show_bug.cgi?id=425560
>
>
>
> --- Comment #6 from RJVB <rjvbertin@gmail.com> ---
>
> That's called change blindness and it's a real thing, but apparently not so
>
> much in terminal emulators. I've been trying a whole bunch of those
> recently
>
> and if they offer the feature it's off by default. Not too surprising
> either,
>
> because change blindness usually occurs only when you do not induce change
>
> yourself, as with scrolling.
>
>
>
> Turning new features on by default is a good idea if they're not intrusive
> and
>
> likely to be useful for a majority of the user population and don't look
> like a
>
> weird bug. How would you feel if someone added a "reset to default"
> feature to
>
> the profile settings dialog and turned that on by default because it's
> useful
>
> to review your settings during an upgrade ... or would you prefer to get a
>
> suggestion to do so (as I think vlc still does after an upgrade)?
>
>
>
> --
>
> You are receiving this mail because:
>
> You are on the CC list for the bug.

I'll repeat myself once more, new features should only be enabled by default if they're truly useful for most users and/or if similar applications also do that. A showcase mechanism would remove the justification of enabling things just to throw them in the users' faces so they don't miss them.

My guess is that terminal users are a conservative bunch who for the most part aren't interested in fancy new bells and whistles at all, but rather in continuity - who prefer to discover features when they discover a need for one.

BTW, the feature that got on my wrong side is flawed in its concept of what new lines are. I haven't check if the highlight on the last set of lines disappears if you wait long enough before you cause the next scroll, but if there is such a timeout it'd be too long for me.

(Posted too quickly, because speaking of flaws:)
I *could* see myself use this kind of feature if it had a quick, easily accessible toggle, with long-running jobs in background tabs or windows. But in its currently implementation it will probably not be of any help because bringing the window or tab to the foreground will almost certainly remove the highlighting from the output that you hadn't seen yet.

"new features should only be enabled by default if they're truly useful for most users and/or if similar applications also do that" - That really depends, most tools just follows the status quo and don't really inovate, and for inovation to happen we need to show what we are doing.
This specific feature has been showcased on the kde app release news, my blogpost about changes in konsole and nate's "kde weekly blogpost", so it's not really a surprise.

Also, it can be quickly disabled as stated.

Now, for some real implementation issues:
The konsole settings is currently a mess, a lot of things that should not be settings are settings, things that should be profile are in settings, things that should be settings are in profile. We are aware of those but currently we have one developer looking for code inconsistencies and one developer trying to implement new ideas, that's not much.

My next iteration of changes are going to be:

Toolbar for access to toogable options (ease of discoverability, better usability)
Future-proofiness of the codebase.

If you would like to help I'd be grateful as we don't have too many developers on konsole.

(In reply to tcanabrava from comment #10)
> This specific feature has been showcased on the kde app release news, my
> blogpost about changes in konsole and nate's "kde weekly blogpost", so it's
> not really a surprise.

Does it come as a surprise that most users who rely on their systems to be productive on other things than the system itself don't have time to follow those things - if they are even aware that they exist?!

I'd say that if you really want to look into implementing new ideas in something as basic and crucial as a terminal emulator, do it in a branch or fork that people/distributions can provide as an alternative, a konsole-ng or something similar that will pop up when using command completion (cf. iTerm and iTerm2). Now *that* would incite even me to go see what that's all about, while not obliging me to waste time figuring out what and why the heck something was changed in my user experience (my main workspace has consisted of 2 side-by-side, vertically maximised terminal windows for the past 30+ years).

A toolbar with toggle buttons might sound like a good idea, but I wouldn't want to waste space on it, so make sure you use kxmlgui or something of the sort so one can assign actions to menus too.

As to helping: KDE's move away first from ReviewBoard (ideal for me) and now from Phabricator to a service that doesn't match my way of working at all has made me much less inclined to make the smallish here-and-there contributions I've been making the past few years. As long as Microsoft don't drive me off github I'll be staying there and off gitlab (but even that wouldn't change much because my main gripe is with having to jump through the PR circus).

NB: the flaws I pointed out have nothing to do with the settings interface. No matter how much of a mess those are, it's one I'm used to (and thank goodness the dialog still looks like one you'd expect on a desktop).

Hey man, There's no need to be so assertive, we are usually on eachothers backs.

I don't understand a few points on your reply, so if you have time to explain them I would be grateful:

> Does it come as a surprise that most users who rely on their systems to be 
> productive on other things than the system itself don't have time to follow 
> those things - if they are even aware that they exist?!

Yes, it does come as a surprise for me, as those blogs are federated on the planet, and they usually appear on phoronix and other linux outlets. If they don't follow, I don't see a problem - new features are a sign that applications are evolving and a quick check on news will give you the answer if it's a bug or a feature.


> I'd say that if you really want to look into implementing new ideas in 
> something as basic and crucial as a terminal emulator, do it in a branch or 
> fork that people/distributions can provide as an alternative, a konsole-ng 

that exists in the form of git-branches, This specific one has been in test for almost six months with discussions and input from the visual design group, users and testers. Now, you can say that you where not part of the testing, and this is true. But it's a feature that we are experimenting since phabricator so we can't blame gitlab here. The majority consensus is that this feature is a nice addition and if users don't like they can simply deactivate, no harm done.

> Now *that* would incite even me to go see what that's all about, while not 
> obliging me to waste time figuring out what and why the heck something was 
> changed in my user experience (my main workspace has consisted of 2 side-by-
> side, vertically maximised terminal windows for the past 30+ years).

But we are not in the 80's anymore. If you want a terminal that mimics what we have in the 80's I ask you to test xterm or urxvt. with konsole you will have increased changes over time (since I'm driving those) and I don't plan to stop. you can test the new features and disable if you don't like, which is fine. Having new things disabled by default is a really good way to make sure nobody will use them. Things like Image Thumbnail, the `copy full path` and this slim line on the side for new lines on the scroll history are welcome change by the majority of people that tested konsole, for more than six months, before we launched the app.

> A toolbar with toggle buttons might sound like a good idea, but I wouldn't
> want to waste space on it, so make sure you use kxmlgui or something of the > > sort so one can assign actions to menus too.

XMLGui is being used. but I'd argue that 22pxs is not really a waste of space. I'm also experimenting with a new feature that you migth fancy, since you like to use two vertical terminals. What would you say about having an hability to say "This terminal on the right is the continuation of this terminal on the left", having double the scrollback lines visible?

> As to helping: KDE's move away first from ReviewBoard (ideal for me) and now 
> from Phabricator to a service that doesn't match my way of working at all has > made me much less inclined to make the smallish here-and-there contributions 
> I've been making the past few years.

That's sad, I quite enjoy your contributions. tooling is just tooling and we need to adapt to what projects that we like use. Gitlab is already helping KDE on the developers front as it's what newcomers used to github knows how to use.

> As long as Microsoft don't drive me off github I'll be staying there and off 
> gitlab (but even that wouldn't change much because my main gripe is with 
> having to jump through the PR circus).

I don't understand this, as you don't need a new account and gitlab quite similar to github, and does not askss you to use a different and unconventional tooling (like arcanist)

> NB: the flaws I pointed out have nothing to do with the settings interface. No 
> matter how much of a mess those are, it's one I'm used to (and thank goodness 
> the dialog still looks like one you'd expect on a desktop).

And they will continue to look like a sane dekstop settings - I just want to reorganize them.

(In reply to tcanabrava from comment #12)
> on eachothers backs.

Are you sure that's what you wanted to say?


> Yes, it does come as a surprise for me, as those blogs are federated on the
> planet, and they usually appear on phoronix and other linux outlets.

I did say people who's productivity is not aimed at but simply based on Linux? As a cheek-in-tongue example of something you're bound to use: how actively do you follow the federated blogs and what-have-you that are surely written by toilet designers or cleaning product developers?

> applications are evolving and a quick check on news will give you the answer
> if it's a bug or a feature.

You still have to know what to search for, and if the behaviour ressembles what's being described in QTBUG-78963 that you had already been following the idea it might be a feature doesn't spring to mind immediately. I had noticed the "highlight new lines" setting, but this implementation only highlights new canvas that has never been painted before.
> The majority consensus is
> that this feature is a nice addition and if users don't like they can simply
> deactivate, no harm done.

The big question here is how big and representative the tester population is. As long as branches are feature-specific and/or aren't well advertised so pre-built preview binaries become available to a large audience the testing population will remain small, and probably not very representative.

> But we are not in the 80's anymore. If you want a terminal that mimics what
> we have in the 80's I ask you to test xterm or urxvt.

There are a handful of things that are missing from those, but I'm not obliged to keep updating konsole nor forbidden from hacking out things I really can't stand - and I will be taking a look at QTerminal or whatever other Qt-based terminals there are.

> XMLGui is being used. but I'd argue that 22pxs is not really a waste of
> space. 

That must be (almost) 2 lines of text for me, and for something that gets to be used only occasionally that's a waste in my book, even on my larger screens.

> you like to use two vertical terminals. What would you say about having an
> hability to say "This terminal on the right is the continuation of this
> terminal on the left", having double the scrollback lines visible?

I'd say that might interest me as a feature in Kate or a GUI equivalent of `less`, but not in a terminal. I'm also pretty certain that curses-based implementations of this must exist but I've never had need for those.

The practice of using multiple on-screen windows that can be positioned freely so each shows something relevant and allows to do things based on what is being shown here and there seems to become an increasingly lost art. That's visible also in websites that assume everyone maximises their browser window. It took me a long time to adjust to MDI IDE designs and I only did that because there are no IDEs anymore that can be used as a loose collection of related windows.

> That's sad, I quite enjoy your contributions. tooling is just tooling and we
> need to adapt to what projects that we like use.

No, we don't. Call it voting with your wallet if you want.

> I don't understand this, as you don't need a new account and gitlab quite
> similar to github, and does not askss you to use a different and
> unconventional tooling (like arcanist)
Arcanist was a bit weird but it still allowed me to put up diffs for review without having to commit them in a local branch of a forked repo. I don't care if that's not the fashionable industry way of doing things, it's what's most convenient for me and doesn't oblige me to waste disk space or time. I too contribute because I feel like it and not because I'm paid and/or ordered to do so.