https://bugs.kde.org/show_bug.cgi?id=427288
--- Comment #3 from Igor Kushnir <igor...@gmail.com> --- (In reply to Igor Kushnir from comment #2) > How about this potential fix: when a tool view is automatically raised in a > dock where at least one tool view is already visible, the raised tool view > is added to the existing ones rather than replaces them (as it does now), > and the the newly visible tool view does not steal focus. Actually this behavior is already possible on user demand. One could classify the following workaround as another bug, but it strikes me as more useful than harmful, especially in this case. When you enter a command in Terminal tool view that can modify a CMake file and trigger CMake-configure, press Ctrl+Enter instead of Enter. Build tool view will appear to the right of Terminal tool view, be much narrower and won't steal focus from Terminal. This works, because the only function that can show a tool view in a dock (both in response to explicit user action and programmatic raising) - IdealButtonBarWidget::showWidget() - tests the Control modifier. See https://invent.kde.org/kdevelop/kdevelop/-/blob/5a67488618b66ab3994e32e4aae32e9123a5447f/kdevplatform/sublime/idealbuttonbarwidget.cpp#L331 Another questionable side effect of this moot bug is that when a tool view shortcut contains the Control modifier, triggering the shortcut shows the tool view alongside already visible one(s) in its dock. Furthermore, when both Terminal and Build tool views are visible in the same dock, there is no more need to hold the Control key, because an already visible tool view is not raised and does not hide other views. So even if the moot bug is fixed, the following workaround remains: open the Build tool view with Ctrl alongside the Terminal tool view beforehand. One can even change the widths of the two visible tool views by moving the splitter between them. -- You are receiving this mail because: You are watching all bug changes.
