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