Creating a tab group with shaded windows doesn't work: The tab group is splitted and the windows are resized to about 150px height Reproducible: Always Steps to Reproduce: 1. Open two dolphin windows 2. Shade them 3. Group them in tabs Actual Results: Both windows resized and tab group removed Expected Results: A new tab group is created and windows stay shaded
works here - what's your focus policy and do you use hover shading? - How do you group the tabs (drag or use the context menu) - does the alternative way differ? - is it limited to dolphin or does it affect all applications?
(In reply to comment #1) > works here > > - what's your focus policy and do you use hover shading? > - How do you group the tabs (drag or use the context menu) - does the > alternative way differ? > - is it limited to dolphin or does it affect all applications? - Focus follows mouse, but I can reproduce with any of them. I use it, but it also occurs if it is disabled here - I've tried drag, auto and context menu. Same result - Any application. I first noticed it in kopete since it is the one where I use both features most of the time.
I've forgot to add this in my reply. I've checked this again and it is generalized in this order for many settings I've tried (even as a new user): - Open two windows - Group them - Shade the group
=) You might or might not have noticed, but that's the reverse order (and reproducible)
I've just checked it with everything set to manual (no hover unshade, no auto group...). It happens when I shade the group. If I group shaded windows, it works. Then, I unshade it; ok, works. I shade it again: bug. Doesn't it happen like this in your case? I'm a bit confused
The bug occurs here is i group two unshaded windows and then shade them (as you described in comment #3 but not in the original report) The weird thing is that the geometry match fails for qDebug() << c->geometry() << main->geometry() << bool(main == m_current); QRect(225,343 878x23) QRect(225,343 878x27) true QRect(225,343 878x27) QRect(225,343 878x23) false It seems like the current window cannot shrink under that size. The issue is related to the oxygen border setting, set it to "No Border" and it's gone. @Hugo Do you have special casing code for the dimensions of shaded active and inactive windows?
I also ran into this problem, and it's extremely annoying for me. I'm used to have a Dolphin window (having two tabs, each with a split view) grouped to a Konsole, and most of the time they are shaded so they do not take up space. Since 4.9.2 this is broken, as reported here. Hope this will be fixed soon. Thanks Thomas for finding the workaround of setting the border size to zero. This is also a problem, because, well, there are no borders :) But most of the time I resize windows with Alt-Right mouse button anyway, so I'll think I'll use this for now.
@Thomas Not sure I understand the question, but here is attempted answer: if the question is whether geometry (::LayoutMetric) changes between shaded and unshaded window, in oxygen, the answer is yes: LM_BorderBottom is 0 for shaded windows and non zero for unshaded. Left and right are unchanged. if the question is whether geometry changes between active and inactive shaded windows, answer is no. Not that I know of. In general: no geometry change between active and inactive window, whatever the other state of the window. Hope this helps, Hugo
Question: ok NoBorder works. Does "no side borders" work ? If not, indeed the issue might be due to the change in LM_BorderBottom between shaded and unshaded windows. (right ?)
(In reply to comment #9) No, "no side borders" also triggers the problem.
It's likely about when the shade state is updated compared to the borders query (shading also breaks more than 3 grouped windows apart) Commenting the shaded special case on the return "fixes" it. How do i run into the (respectWindowState && maximized) condition?
@Thomas: with any maximized window, I think. The "respect window state" is on by default it is off, (I think) when you click somewhere that you can move/resize maximized window (and maybe this option is gone now ...)
... this was a kwin option iirc
It's still there but has no impact (ie. maximizing doesn't break ever) so it's about when the border is updated compared to the shading. Gonna have a look.
Created attachment 74707 [details] fix Attached patch. Seems to not cause side effects and carry only ignorable overhead. -> Gonna create review request when having a somewhat aligned branch again, but you can test if you want.
https://git.reviewboard.kde.org/r/107040/
Git commit 992fae00acf14d6c5ae3bc427e51eb32a9c0c32c by Thomas Lübking. Committed on 21/10/2012 at 17:42. Pushed by luebking into branch 'KDE/4.9'. update deco borders on shade before aligning tabs FIXED-IN: 4.9.3 M +5 -3 kwin/client.cpp http://commits.kde.org/kde-workspace/992fae00acf14d6c5ae3bc427e51eb32a9c0c32c