https://bugs.kde.org/show_bug.cgi?id=425560
--- Comment #13 from RJVB ---
(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
https://bugs.kde.org/show_bug.cgi?id=425560
--- Comment #12 from tcanabr...@kde.org ---
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
https://bugs.kde.org/show_bug.cgi?id=425560
--- Comment #11 from RJVB ---
(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.
https://bugs.kde.org/show_bug.cgi?id=425560
--- Comment #10 from tcanabr...@kde.org ---
"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
https://bugs.kde.org/show_bug.cgi?id=425560
--- Comment #9 from RJVB ---
(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
https://bugs.kde.org/show_bug.cgi?id=425560
--- Comment #8 from RJVB ---
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
https://bugs.kde.org/show_bug.cgi?id=425560
--- Comment #7 from tcanabr...@kde.org ---
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
https://bugs.kde.org/show_bug.cgi?id=425560
--- Comment #6 from RJVB ---
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
https://bugs.kde.org/show_bug.cgi?id=425560
--- Comment #5 from tcanabr...@kde.org ---
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
https://bugs.kde.org/show_bug.cgi?id=425560
--- Comment #4 from RJVB ---
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.
https://bugs.kde.org/show_bug.cgi?id=425560
tcanabr...@kde.org changed:
What|Removed |Added
CC||tcanabr...@kde.org
--- Comment #3 from
https://bugs.kde.org/show_bug.cgi?id=425560
Christoph Feck changed:
What|Removed |Added
Status|REPORTED|RESOLVED
Resolution|---
https://bugs.kde.org/show_bug.cgi?id=425560
--- Comment #1 from RJVB ---
I'd appreciate knowing which commits are responsible for this new behaviour so
I can look into a fix or even a local workaround.
--
You are receiving this mail because:
You are watching all bug changes.
13 matches
Mail list logo
