Created attachment 107857 [details] Screenshot of window after debug session has completed. Overview -------- Every time I enter debug mode, then quit and return to code view, the window's minimum width increases. This is so bad that the scroll bar disappears after the second debugging session. The window can not be resized to anything smaller (i.e. it already appears to be at its minimum size). There is no way to reset this other than restarting. Steps to Reproduce ------------------ 1) Be using awesome-wm (awesome window manager) 2) Have two screens (although I'm not entirely sure whether this matters or not) 3) Enter debug mode once and return to normal code view. Actual Results -------------- Your window should now stretch beyond your screen size. Pressing mod+m (in awesome, this maximizes and restores the window) Expected Results ---------------- Window's minimum size should remain unchanged, as it was before debugging. Build Date & Platform --------------------- This first occurred in the gentoo package kdevelop-5.0.0. 4.12.5-gentoo #1 SMP Sun Aug 20 00:59:26 CEST 2017 x86_64 AMD Phenom(tm) II X6 1090T Processor AuthenticAMD GNU/Linux Additional Information ---------------------- I am running awesome-wm. I have attached a screenshot.
This width limit increase happens to me too. DE : KDE KDevelop version : 5.2.1 (I am using the «Display window geometry when moving or resizing» feature to report the scale limits) It looks like the values are quite random, since after some testing, I got different values. It looks like Debug still has a bigger impact than Execute. And Execute does not have to be clicked for Debug to make changes. (I just did a test with Debug only : two first times, looking ok, third time, width=1719) State 1 : Resize working well I open the application and code. Width limit : 1159 State 2 : Minimum width limit growing a bit I click on «execute current launch». Width limit : 1320 At this stage, when using an older 4/3 ratio screen (resolution: 1280×1024) maximizing the window cuts part of it out of the screen. State 3 : Minimum width limit growing even more I click on «Debug current launch». Width limit : 1421 Now, both sides are hidden. On a 1366×768 screen, the window starts to be cut too. State 4 : Minimum width limit increasing more or less arbitrarily I feel like clicking on those buttons some times does increase (never decrease) the width limit, but not always. The panels & co. are always in the same state when testing.
Created attachment 109275 [details] Commented test output Launched KDevelop from the shell and commented and detailed it's output.
I did some testing, and it looks like it comes from the toolviews, specifically from the bottom one. I attached a commented testing session with the different actions I made. The Bottom Toolbar has a constraint on its size driven by the size of the names of the tools it is showing. Plus an extra empty space on the right. Where the left and right toolbars can overflow, the bottom one can't, so it resizes the whole window and forces it to follow its constraints. Furthermore, when changing modes (main/debug/execute/…), the Toolbox statuses aren't saved completely (saved when «right click>Tool View Position>…» but not when «right click>Remove Tool View» and «right click>…(add tool view)»), and when changing modes back, some tools change to other toolboxes, making them grow suddenly. So the ideal case would be to always remember where the tools where, and to be able to overflow the bottom toolbox too, or even better, wrap the tools, in all of the toolboxes. In the code, I came across this code block: kdevelop/kdevplatform/sublime/idealbuttonbarwidget.cpp: 164-170 //apol: here we set the usual width of a button for the vertical toolbars as the minimumWidth //this is done because otherwise when we remove all the buttons and re-add new ones we get all //the screen flickering. This is solved by not defaulting to a smaller width when it's empty int w = button->sizeHint().width(); if (orientation() == Qt::Vertical && w > minimumWidth()) { setMinimumWidth(w); } Even though it is talking about the vertical bars, it's the minimumWidth that is set. There might be a link between this code and the strange behaviour.
*** Bug 333060 has been marked as a duplicate of this bug. ***
(In reply to tuxtoriel from comment #3) > I did some testing, and it looks like it comes from the toolviews, > specifically from the bottom one. Can confirm, the effect persists when switching between main and debug view and back but the minimum width remains small enough for a 1920x1080 if enough tools from the bottom bar have been removed.
Git commit b95bc1c3452562e12d8ebd9ba106e0b080b8c27c by Amish Naidu. Committed on 15/09/2018 at 10:54. Pushed by anaidu into branch '5.3'. Sublime: Fix window growing larger by making tool view buttons shrinkable Summary: Items will be shrinked in the IdealButtonBarLayout, instead of overflowing and forcing the window larger. Geometries are calculated so that only the bigger will be contracted while items smaller than a relative threshold won't contract. Consequently, the window will no longer grow when changing from Debug to Code. IdealToolButtons: Instead of simply truncating text, they will elide text while painting. IdealButtonBarWidget: Previously the layout attached to the object was being used to add buttons, which for the bottom bar wrongly meant a super-layout while the IdealButtonBarLayout added to this super-layout was being ignored, introduced a new member to use the proper layout for all orientations. Reviewers: #kdevelop, kossebau Reviewed By: #kdevelop, kossebau Subscribers: kossebau, kdevelop-devel Tags: #kdevelop Differential Revision: https://phabricator.kde.org/D15450 M +15 -18 kdevplatform/sublime/idealbuttonbarwidget.cpp M +2 -0 kdevplatform/sublime/idealbuttonbarwidget.h M +74 -27 kdevplatform/sublime/ideallayout.cpp M +24 -6 kdevplatform/sublime/idealtoolbutton.cpp https://commits.kde.org/kdevelop/b95bc1c3452562e12d8ebd9ba106e0b080b8c27c
*** Bug 335578 has been marked as a duplicate of this bug. ***