Bug 398731 - Search wrapped info message at wrong position
Summary: Search wrapped info message at wrong position
Alias: None
Product: frameworks-ktexteditor
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: 5.52.0
Platform: Compiled Sources All
: NOR normal
Target Milestone: ---
Assignee: KWrite Developers
URL: https://phabricator.kde.org/D19416
: 410725 (view as bug list)
Depends on:
Reported: 2018-09-16 20:19 UTC by David Hurka
Modified: 2019-08-08 14:39 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.57

patch to revert to simplified previous behaviour (1.07 KB, text/plain)
2018-11-20 09:24 UTC, RJVB
snapshot (113.83 KB, image/png)
2018-11-20 09:26 UTC, RJVB
The new position of the search wrapped popup messages (148.99 KB, image/png)
2019-05-22 17:52 UTC, David Hurka

Note You need to log in before you can comment on or make changes to this bug.
Description David Hurka 2018-09-16 20:19:51 UTC
When incrementally searching using the find bar, the info message appears in the middle of the text area, sometimes hiding the found result.

Steps to reproduce:
1) Open a large text file
2) Search a word that occurs in the middle of a line using the find bar
3) Hit Enter (find next) until the search continues from top

The info message appears in the middle, covering the middle of the centered search result.
Additionally it stays there for a long time, and blocks/queues other info messages.

Expected result:
Info messages appear instantly at the top/bottom next to the scroll bar with the text "Continuing search from top/bottom", like it did until some days ago.
This feature is annoying because:
I need to jump through long dataset summary files, where many datasets look very similar. One dataset is lokated some pages below the other, and I want to compare them. I use the search bar to jump between them. Now, this centered info message doesn't change and hides the dataset number, so I don't know where I am just now.

Unfortunately I couldn't downgrade katepart via aptitude, so I don't know which module causes the problem. But I think it's katepart.
Comment 1 Dominik Haumann 2018-09-17 19:34:37 UTC
@Alex: Any ideas on how to improve this? :/ Whatever we do, someone always complains.
Comment 2 Michael D 2018-10-08 07:42:54 UTC
I thought it was fine before in the corner, but now I have the same issue of obscured text. Probably the middle of the window is the worst place it could be in terms of possible text obfuscation. To me, it makes sense to put it somewhere at the bottom near the search bar, and I would recommend the bottom right since (i) that is the default location of notifications in KDE, and (ii) there is more likely to be no text there than on the left (unless your language reads from right-to-left).
Comment 3 RJVB 2018-11-19 20:44:56 UTC
I was just going to report this too and observe that the message was fine where it was.

Consider this: searching through a body of text is an inherently visual activity where you look at your screen attentively. Even if you look at the centre of your editing view (where the search results are (almost) always shown) your peripheral vision will still pick up a message that flashes at the top or bottom of that view. It will be pretty obvious why if that happens when you just hit the key to jump to the next search hit.

The easiest way out of this regression would be to make the location configurable. Some will still complain, but at least we can chose whatever is least annoying.
Alternatively, why not mark the startpoint of a search in the left margin, or by making the location stand out otherwise in a way that doesn't affect readability? Even a brief view background flash would do the trick for me.

FWIW, 2s is really long for something to remain posted right in front of your eyes, hiding your text.

The offending commit: cc8b2208
Comment 4 David Hurka 2018-11-19 22:44:05 UTC
(In reply to RJVB from comment #3)
> The offending commit: cc8b2208

That's what I was searching for for a long time, before I opened this report. (I did grep -r "Search Wrapped", but without success.)

It shouldn't be difficult to change the line
> 625:  m_wrappedMessage->setPosition(KTextEditor::Message::CenterInView);
to something configurable. (I never did something like that.)

D9394 (cc8b2208) doesn't provide any references (bug/whishlist reports, etc.), but says that the corner messages weren't prominent enough. Well, maybe they weren't for some users.

But I think, users who use the Find&Replace Bar (maybe with regular expressions), instead of the Find Bar, know very well what's going on, so the "more prominent" messages are not needed.

Would it be OK to change back to the corner messages at least for the Find&Replace Bar?
Comment 5 RJVB 2018-11-20 09:24:24 UTC
Created attachment 116422 [details]
patch to revert to simplified previous behaviour

I've patched the code for myself, back to using the Information colour (more appropriate IMHO, definitely for my colour scheme) and just pop the message at BottomInView. The previous implementation showed the message at the top or bottom depending on how the search wrapped, but that's needlessly complicated IMHO. We know in what direction we were searching, and I don't see the added value of knowing (confirming) in what sense the search wrapped (beyond the icon already displayed in the message).

Those are easy changes for anyone to apply, if they feel like building a framework from source (and installing all required dependencies to do that).
Comment 6 RJVB 2018-11-20 09:26:03 UTC
Created attachment 116423 [details]

(I also have a personal patch to make KMessage's less gaudy :) )
Comment 7 David Hurka 2018-11-20 11:49:42 UTC
With this patch the messages still queue, when you jump forward and back fast enough.

However, in my opinion the messages may do anything, unless they are in the middle of the screen...

(In reply to RJVB from comment #3)
> Even a brief view background flash would do the trick for me.
Hmm, that's like screen flickering. I think, I wouldn't like that.
Comment 8 RJVB 2018-11-20 12:21:00 UTC
I think the queuing isn't new. Shouldn't really be a problem because how often do you let the search wrap ("jump back and forth") under normal use?

I agree that a view flash is like the screen flickering and thus not very appealing - if you fill the entire screen with that view. But again it would be only once under normal use. Anyway, we'll see what the devs come up with.
Comment 9 David Hurka 2018-11-20 12:30:22 UTC
Under normal use: very rarely.

It was very convenient for these database summary files, to compare the first and the last entry of the same thing. I didn't install updates on that machine, to keep the corner messages.

Split view would have been another possible method, of course.
Comment 10 Dominik Haumann 2019-02-24 07:48:21 UTC
@René: Could you post the patch on Phabricator?
Comment 11 Christoph Cullmann 2019-03-04 18:44:13 UTC
Git commit ac35dba359887e1feb881d01ec15db32116943a6 by Christoph Cullmann, on behalf of René J.V. Bertin.
Committed on 04/03/2019 at 18:45.
Pushed by cullmann into branch 'master'.

Restore the search wrapped message to its former type and position.

This fixes issue 398731 by restoring the "search wrapped" info message to its former type and position.

Test Plan: works as intended (= as before #cc8b2208)

Reviewers: #ktexteditor, dhaumann

Reviewed By: #ktexteditor, dhaumann

Subscribers: dhaumann, neundorf, loh.tar, ngraham, kwrite-devel, kde-frameworks-devel

Tags: #ktexteditor, #kate, #frameworks

Differential Revision: https://phabricator.kde.org/D19416

M  +2    -2    src/search/katesearchbar.cpp

Comment 12 David Hurka 2019-05-22 17:52:57 UTC
Created attachment 120255 [details]
The new position of the search wrapped popup messages

(In reply to RJVB from comment #8)
> I think the queuing isn't new. Shouldn't really be a problem because how
> often do you let the search wrap ("jump back and forth") under normal use?
> [...]
Actually, I do that very often now. Use case is to compare usages of Okular class members. (They are often undocumented and I want to know why e. g. a signal is emitted.)

(In reply to Michael D from comment #2)
> [...] To me, it makes sense to put it somewhere at the bottom
> near the search bar, [...]
It’s not necessarily near the search bar, but it looks fine now. See attachment.

Thanks for fixing this.
Comment 13 Nate Graham 2019-08-08 14:39:59 UTC
*** Bug 410725 has been marked as a duplicate of this bug. ***