Search window location in new Konsole

[Duncan]

René JV Bertin posted on Tue, 21 Aug 2018 14:19:52 +0200 as excerpted:

> I concur! The old location wasn’t glamorous but near perfect in
> usability terms. Function over form any day!
> 
> Sent from a pocket terminal
> 
>> On 21 Aug 2018, at 10:45, Florian Lindner <mailinglists at xgm.de> wrote:
>> 
>> Hello,
>> 
>> since recently, konsole has moved the window to input search patterns
>> from a bar at the bottom to a small window at the upper right. I find
>> this very unpleasant from a usability point of view. Usually you are
>> focused on the very bottom left of the terminal window, where the
>> cursor is. Now, if you use the search, you have to shift your focus all
>> the way up and right to the search bar.
>> 
>> Is there a way to move the search window somewhere else or retain the
>> old behavior?

Based on the commit log (which I follow to some degree as I'm running 
live-git kde including konsole, which I use enough for the commit log to 
be worth at least keeping an eye on, to get a heads-up on things like 
this as well as because having some idea what they were doing helps when 
I find and need to bisect a new bug) when the new "overlay" find feature 
was introduced, the idea is to keep the find UI from changing the number 
of lines in the terminal window, disturbing various full-terminal "semi-
gui" apps that check that when they start and don't cope well with it 
changing while they run, probably because they were written as a full-
screen CLI without X-based terminal apps in mind, and thus don't properly 
deal with the "SIGWINCH" (signal window changed) signal they get sent 
when the window size changes.

And once it's an overlay not an adjustment of the terminal size to 
accommodate the find UI, placing it at the bottom would be irritating 
precisely /because/ that's where the newest output normally is, and the 
overlay would cover it up.  So (for left-to-right, top-to-bottom 
languages, anyway, not sure about for instance R2L Hebrew, or vertically-
first written languages) it was placed in the top right corner, the place 
likely to interfere least with the terminal display.

Besides, once you actually /use/ the find, the hit could appear anywhere 
in the window, particularly when there's multiple hits, so the bottom 
focus is likely to be disturbed in any case.

That seems to be the thinking anyway, and I can definitely understand the 
disturbance changing the number of lines could cause.  Personally, the 
change didn't bother me much, again, precisely because once I resorted to 
find, I was already no longer as focused on the bottom left corner.  But 
just as I understand the sigwinch issue, I also understand the 
disturbance to long established work flows and habits.  Still, I expect 
once people adjust, /most/ will appreciate the new find behavior, because 
unlike the old behavior, it doesn't take up precious display lines that 
could be used to display terminal content instead.

Tho I'd probably make it an option, if it were me.  But while I 
appreciate kde precisely because they /do/ make more things options, I 
also understand, perhaps better than most since I tend to customize 
things quite a bit and I do run live-git kde, so I tend to come across 
bugs that the devs don't see, that every option made available creates at 
least one less tested than normal path that's potentially buggy, that 
will break the app for people trying to change that option from the 
default, until that bug is reported and subsequently fixed.  But too many 
options and reproducing the bug in ordered to fix it becomes a problem as 
well.  So options do have their down side.  But I'd still probably make 
this an option, because I /do/ understand how many people's work flows 
it's going to negatively affect.

... And I don't see such an option...

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman