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@xxxxxx> 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
