https://bugs.kde.org/show_bug.cgi?id=500015
--- Comment #10 from Ivan B. <frostygam...@gmail.com> --- (In reply to Rok F from comment #9) > (In reply to Ivan B. from comment #8) > > I have the same issue and changing from '<' to '<=' the 'if' condition in > > Window::nextInteractiveMoveGeometry and then patching kwin fixes the freeze. > > However, now windows can be easily dragged under the top panel and when you > > try to drag the window in that state it moves slowly. > > Before changing the code windows wouldn't go under the top panel that > > easily. > > The operator only fixes part of the problem. The loop can still go through a > hundred iterations, lagging the whole system and making the window movement > appear slow. There is currently no upper limit on this loop. For my test, i > limited the for loop to a max of 20, and it behaves normally, although i > don't know what a realistic limit should be. I've decided to experiment with this code. Limiting the loop to a small value has the same effect as just simply commenting it out all together. Also there is code that runs only when amount of outputs in the workspace is > 1. ( if (workspace()->outputs().count() > 1) ) If I create a virtual output (or connect another screen), then the amount of outputs is > 1 and the code runs. And it fixes the issue with windows going under the panel when dragged (with code changes) and the freeze (with and without code changes)! -- You are receiving this mail because: You are watching all bug changes.
