Bug 246153 - Kwin dynamic tiling defaults to floating if there aren't at least two tiled windows active
Summary: Kwin dynamic tiling defaults to floating if there aren't at least two tiled w...
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: unspecified
Platform: Exherbo Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
: 287682 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-07-29 14:29 UTC by Johannes Nixdorf
Modified: 2011-11-30 16:06 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.7.4
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Johannes Nixdorf 2010-07-29 14:29:23 UTC
Version:           unspecified (using KDE 4.4.95) 
OS:                Linux

When a new window is opened while there are not at least two tiled windows opened the new window defaults to floating.

Reproducible: Sometimes

Steps to Reproduce:
- close or minimize all windows
- start a new window
- start another new window

Actual Results:  
Both windows take the whole screen while the second window is above the first.

Expected Results:  
Both windows are tiled according to the selected layout.

- tested with konsole and dolphin
- sometimes when using different programs it doesn't even work when two tiled windows are already active
- sometimes the first window is tiled but the second one started isn't
Comment 1 Kelytha 2010-08-11 10:26:19 UTC
It is still happening in 4.5.0, using Kubuntu packages.
Comment 2 kde 2010-10-01 17:45:19 UTC
Can confirm this for KDE 4.5.1 on gentoo.
Comment 3 z1r0un 2011-10-20 03:01:18 UTC
Can confirm for KDE 4.7.1 (Kubuntu Oneiric)
Also, some programs start floating no matter /what/, KWrite for example.
Comment 4 Thomas 2011-10-25 13:53:06 UTC
Also happening if you start a application on a clear desktop. It will take the whole screen as expected. If you close the application and start it again, it will start maximized as floating window and tiling will not work as expected when you start another application afterwards.
Comment 5 Marcus Harrison 2011-11-29 12:04:55 UTC
A temporary work-around until this behaviour is fixed is to go to System Settings --> Window Behaviour --> Window Behaviour --> Moving and tick, "Display borders on maximized windows". With this setting enabled, windows that start maximised are set to tile.
Comment 6 Thomas Lübking 2011-11-29 20:44:47 UTC
*** Bug 287682 has been marked as a duplicate of this bug. ***
Comment 7 Thomas Lübking 2011-11-29 20:45:30 UTC
From bug #287682

------- Comment #2 From Marcus Harrison 2011-11-29 11:54:52 (-) [reply] -------
I've done more testing, and it's a bit more complicated than I first thought.

What's happening is, creating a new window that doesn't open maximised makes it
tile. If the window opens maximised (e.g. because the last time that window was
opened it was maximised), it opens as a floating window that's maximised.

Now here's where the real problem lies: if a none-maximised window is tiled on
an empty desktop, it fills the whole screen _without becoming maximised_. When
that window is then closed and re-opened, it becomes maximised because the
window's borders are all touching the screen edge. Because it opens as a
maximised window, it opens as a floating window by default.

A better scheme might be to make tiled windows maximised by default: maximised
windows can be tiled next to each other, in which case they keep their
maximised status i.e. they lose window borders/resize handles/the window
controls hug the screen edges, but they are displayed in a tiled manner. Not
only does this solve the problem of maximised windows being floating by
default, but it results in something more aesthetically pleasing (and removes
the bug that resize handles/borders don't actually resize tiled windows) and
gives us a standard, clear behaviour for when a tiled window becomes a floating
window (it is maximised across the whole screen until the user moves it away).

One issue with the above is that maximised windows don't necessarily hide the
window borders, as that is a user-configurable setting (under, "Resize/Move
Maximised Windows" somewhere).
Comment 8 Thomas Lübking 2011-11-29 20:53:10 UTC
Many thanks for your detailed explanation, Marcus.

This makes clear why
a) i couldn't reproduce it (neither were any window closed maximized before i activated tiling nor do i have that option unchecked)
b) this is quite obvious. Maximized windows are not movable unless that option is checked and the tiling code doesn't use the forcing plainMoveResize (and shouldn't either)
Comment 9 Thomas Lübking 2011-11-29 21:11:52 UTC
fix: https://git.reviewboard.kde.org/r/103292/
Comment 10 Thomas Lübking 2011-11-29 21:27:17 UTC
Git commit 60ad35b0998f10a2fa8f3020ac76bdc521af70c3 by Thomas Lübking.
Committed on 29/11/2011 at 22:07.
Pushed by luebking into branch 'master'.

spellbind tiling and options->moveResizeMaximizedWindows

BUG: 246153

M  +2    -1    kwin/libkdecorations/kdecoration_p.cpp

http://commits.kde.org/kde-workspace/60ad35b0998f10a2fa8f3020ac76bdc521af70c3
Comment 11 Thomas Lübking 2011-11-29 21:30:39 UTC
Git commit 9b63684a92df4a8a59617ad7fa42b310622f7733 by Thomas Lübking.
Committed on 29/11/2011 at 22:07.
Pushed by luebking into branch 'KDE/4.7'.

spellbind tiling and options->moveResizeMaximizedWindows

BUG: 246153
REVIEW: 103292
FIXED-IN: 4.7.4
(cherry picked from commit 60ad35b0998f10a2fa8f3020ac76bdc521af70c3)

M  +2    -1    kwin/libkdecorations/kdecoration_p.cpp

http://commits.kde.org/kde-workspace/9b63684a92df4a8a59617ad7fa42b310622f7733
Comment 12 Marcus Harrison 2011-11-30 16:06:53 UTC
Thank you! It's good to hear this bug's been fixed. :)