[prev in list] [next in list] [prev in thread] [next in thread]
List: kwin
Subject: Re: Review Request 115396: fix handling of window size hints with PResizeInc
From: Martin_Gräßlin <mgraesslin () kde ! org>
Date: 2014-01-30 13:57:48
Message-ID: 20140130135748.32672.93525 () probe ! kde ! org
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
> On Jan. 30, 2014, 12:30 p.m., Martin Gräßlin wrote:
> > I tried to create a test application demonstrating the behavior using the values \
> > from https://bugzilla.gnome.org/attachment.cgi?id=193285 but with pure xcb, \
> > KWin/5 does not show this problem.
> > It would probably help if I could see the xprop of the affected windows. \
> > Unfortunately I don't have any gtk development environment set up, so I cannot \
> > just test myself.
> > For reference the test code I used:
> > #include <stdlib.h>
> > #include <xcb/xcb.h>
> > #include <xcb/xcb_icccm.h>
> >
> > int main(int, char **)
> > {
> > int screenNumber;
> > xcb_connection_t *c = xcb_connect(nullptr, &screenNumber);
> >
> > auto getScreen = [=]() {
> > const xcb_setup_t *setup = xcb_get_setup(c);
> > auto it = xcb_setup_roots_iterator (setup);
> > for (int i = 0; i < screenNumber; ++i) {
> > xcb_screen_next(&it);
> > }
> > return it.data;
> > };
> > xcb_screen_t *screen = getScreen();
> >
> > xcb_window_t w = xcb_generate_id(c);
> > const uint32_t values[2] = {screen->white_pixel, XCB_EVENT_MASK_BUTTON_PRESS | \
> > XCB_EVENT_MASK_BUTTON_RELEASE};
> > xcb_create_window(c, 0, w, screen->root, 0, 0, 80, 36, 0, \
> > XCB_WINDOW_CLASS_INPUT_OUTPUT, screen->root_visual, XCB_CW_BACK_PIXEL | \
> > XCB_CW_EVENT_MASK, values);
> > // set the normal hints
> > xcb_size_hints_t hints;
> > hints.flags = XCB_ICCCM_SIZE_HINT_P_MIN_SIZE | XCB_ICCCM_SIZE_HINT_BASE_SIZE | \
> > XCB_ICCCM_SIZE_HINT_P_RESIZE_INC; hints.min_width = 8;
> > hints.min_height = 15;
> > hints.base_width = 0;
> > hints.base_height = 0;
> > hints.width_inc = 8;
> > hints.height_inc = 15;
> > xcb_icccm_set_wm_normal_hints(c, w, &hints);
> >
> > // and map the window
> > xcb_map_window(c, w);
> > xcb_flush(c);
> >
> > while (xcb_generic_event_t *event = xcb_wait_for_event(c)) {
> > bool exit = false;
> > if ((event->response_type & ~0x80) == XCB_BUTTON_RELEASE) {
> > exit = true;
> > }
> > free(event);
> > if (exit) {
> > break;
> > }
> > }
> >
> > xcb_disconnect(c);
> > return 0;
> > }
> >
>
> Thomas Lübking wrote:
> The Problem is that the gnome terminal class (also powers emacs and gvim - famous \
> bugs ;-) tries to play WM and "fixes" the size set by the WM. The KWin code is \
> ultra-twisted and the comments do not match exactly what is done. Also the code \
> seems to stem from fvwm -> KWM -> KWin =)
> Atm, the code seems correct (while reads wrong)
> KWin merges base_width into min_width and uses min_width as base_width - this seems \
> due to the different demands on aspect ratio calculation, where the claim is:
> // According to ICCCM 4.1.2.3 PMinSize should be a fallback for PBaseSize for size \
> increments, // but not for aspect ratio.
>
> I could not verify this statement, but *that* is what causes the divergence and \
> needs to be sorted out.
> Marek Marczykowski-Górecki wrote:
> The problematic case is when application provides both min size and base size - \
> then KDE uses only min size for ResizeInc handling and ignores base size. The code: \
> if (xSizeHint.flags & PBaseSize) { // PBaseSize is a fallback for PMinSize \
> according to ICCCM 4.1.2.3 // The other way around PMinSize is not a complete \
> fallback for PBaseSize, // so that's not handled here.
> if (!(xSizeHint.flags & PMinSize)) {
> xSizeHint.min_width = xSizeHint.base_width;
> xSizeHint.min_height = xSizeHint.base_height;
> }
> (...)
> int basew_inc = xSizeHint.min_width; // see getWmNormalHints()
> int baseh_inc = xSizeHint.min_height;
> w = int((w - basew_inc) / width_inc) * width_inc + basew_inc;
> h = int((h - baseh_inc) / height_inc) * height_inc + baseh_inc;
>
>
> Aspect ratio code is ok (which uses directly xSizeHint.base_*), only ResizeInc \
> handling is wrong.
> Yes, that gnome terminal "behaviour" is also a bug, but separate one, not the only \
> one.
> BTW hints of affected window:
> WM_NORMAL_HINTS(WM_SIZE_HINTS):
> program specified minimum size: 356 by 104
> program specified resize increment: 9 by 18
> program specified base size: 15 by 64
> window gravity: NorthWest
>
>
> Martin Gräßlin wrote:
> @Thomas: I just verified and the comment is correct
>
> I just tried with the values from the provided size hints and the problem is not \
> reproducable. Thus the shrinking is related to client "playing WM".
> Marek Marczykowski-Górecki wrote:
> Yes, only in combination with clients "playing with WM" (which is separate bug, \
> gnome-terminal this time) it causes window shrink, in all other cases, window \
> simply will gets wrong size. Every sane application should simply accept those \
> sizes, but still - there are inconsistent with hints because of bug, not because of \
> some real need of WM.
> For example window with:
> WM_NORMAL_HINTS(WM_SIZE_HINTS):
> program specified minimum size: 352 by 104
> program specified resize increment: 9 by 18
> program specified base size: 15 by 64
>
> Can get size 775x320, which is (352 + 47*9) x (104 + 12*18), but not in form of (15 \
> + i*9) x (64 + j*18).
> To reproduce this bug, simply install and run gnome-terminal under KDE, it doesn't \
> require whole Gnome installed.
ok I'm convinced ;-) I have my test-application in a state that it shows the problem \
and switching to base_width and base_height fixes the problem.
- Martin
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115396/#review48596
-----------------------------------------------------------
On Jan. 30, 2014, 6:56 a.m., Marek Marczykowski-Górecki wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/115396/
> -----------------------------------------------------------
>
> (Updated Jan. 30, 2014, 6:56 a.m.)
>
>
> Review request for kwin.
>
>
> Repository: kde-workspace
>
>
> Description
> -------
>
> Use base_width/base_height if provided by the application and fallback to \
> min_width/min_height only if not (according to ICCCM 4.1.2.3). Previously always \
> min_width/min_height was used (if provided), even if base_width/base_height was \
> also provided.
> This fixes long standing bug with shrinking gnome-terminal window. Haven't found it \
> in KDE Bugs, but described here: https://bugzilla.redhat.com/show_bug.cgi?id=707664 \
>
> Diffs
> -----
>
> kwin/geometry.cpp 6ae9666
>
> Diff: https://git.reviewboard.kde.org/r/115396/diff/
>
>
> Testing
> -------
>
> Tested patched kde-workspace-4.10.5 (Fedora 18), I don't any significant changes \
> until now. Patched version allows normal gnome-terminal use, previously it was \
> shrinking to minimal size.
>
> Thanks,
>
> Marek Marczykowski-Górecki
>
>
[Attachment #5 (text/html)]
<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 \
solid;"> <tr>
<td>
This is an automatically generated e-mail. To reply, visit:
<a href="https://git.reviewboard.kde.org/r/115396/">https://git.reviewboard.kde.org/r/115396/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <p style="margin-top: 0;">On January 30th, 2014, 12:30 p.m. CET, <b>Martin \
Gräßlin</b> wrote:</p> <blockquote style="margin-left: 1em; border-left: 2px solid \
#d0d0d0; padding-left: 10px;"> <pre style="white-space: pre-wrap; white-space: \
-moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: \
break-word;">I tried to create a test application demonstrating the behavior using \
the values from https://bugzilla.gnome.org/attachment.cgi?id=193285 but with pure \
xcb, KWin/5 does not show this problem.
It would probably help if I could see the xprop of the affected windows. \
Unfortunately I don't have any gtk development environment set up, so I cannot \
just test myself.
For reference the test code I used:
#include <stdlib.h>
#include <xcb/xcb.h>
#include <xcb/xcb_icccm.h>
int main(int, char **)
{
int screenNumber;
xcb_connection_t *c = xcb_connect(nullptr, &screenNumber);
auto getScreen = [=]() {
const xcb_setup_t *setup = xcb_get_setup(c);
auto it = xcb_setup_roots_iterator (setup);
for (int i = 0; i < screenNumber; ++i) {
xcb_screen_next(&it);
}
return it.data;
};
xcb_screen_t *screen = getScreen();
xcb_window_t w = xcb_generate_id(c);
const uint32_t values[2] = {screen->white_pixel, XCB_EVENT_MASK_BUTTON_PRESS | \
XCB_EVENT_MASK_BUTTON_RELEASE};
xcb_create_window(c, 0, w, screen->root, 0, 0, 80, 36, 0, \
XCB_WINDOW_CLASS_INPUT_OUTPUT,
screen->root_visual, XCB_CW_BACK_PIXEL | XCB_CW_EVENT_MASK, \
values);
// set the normal hints
xcb_size_hints_t hints;
hints.flags = XCB_ICCCM_SIZE_HINT_P_MIN_SIZE | XCB_ICCCM_SIZE_HINT_BASE_SIZE | \
XCB_ICCCM_SIZE_HINT_P_RESIZE_INC; hints.min_width = 8;
hints.min_height = 15;
hints.base_width = 0;
hints.base_height = 0;
hints.width_inc = 8;
hints.height_inc = 15;
xcb_icccm_set_wm_normal_hints(c, w, &hints);
// and map the window
xcb_map_window(c, w);
xcb_flush(c);
while (xcb_generic_event_t *event = xcb_wait_for_event(c)) {
bool exit = false;
if ((event->response_type & ~0x80) == XCB_BUTTON_RELEASE) {
exit = true;
}
free(event);
if (exit) {
break;
}
}
xcb_disconnect(c);
return 0;
}
</pre>
</blockquote>
<p>On January 30th, 2014, 12:49 p.m. CET, <b>Thomas Lübking</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">The Problem is that the \
gnome terminal class (also powers emacs and gvim - famous bugs ;-) tries to play WM \
and "fixes" the size set by the WM. The KWin code is ultra-twisted and the \
comments do not match exactly what is done. Also the code seems to stem from fvwm \
-> KWM -> KWin =)
Atm, the code seems correct (while reads wrong)
KWin merges base_width into min_width and uses min_width as base_width - this seems \
due to the different demands on aspect ratio calculation, where the claim is:
// According to ICCCM 4.1.2.3 PMinSize should be a fallback for PBaseSize for size \
increments, // but not for aspect ratio.
I could not verify this statement, but *that* is what causes the divergence and needs \
to be sorted out.</pre> </blockquote>
<p>On January 30th, 2014, 1:04 p.m. CET, <b>Marek Marczykowski-Górecki</b> \
wrote:</p> <blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; \
padding-left: 10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; \
white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">The \
problematic case is when application provides both min size and base size - then KDE \
uses only min size for ResizeInc handling and ignores base size. The code: if \
(xSizeHint.flags & PBaseSize) { // PBaseSize is a fallback for PMinSize \
according to ICCCM 4.1.2.3
// The other way around PMinSize is not a complete fallback for PBaseSize,
// so that's not handled here.
if (!(xSizeHint.flags & PMinSize)) {
xSizeHint.min_width = xSizeHint.base_width;
xSizeHint.min_height = xSizeHint.base_height;
}
(...)
int basew_inc = xSizeHint.min_width; // see getWmNormalHints()
int baseh_inc = xSizeHint.min_height;
w = int((w - basew_inc) / width_inc) * width_inc + basew_inc;
h = int((h - baseh_inc) / height_inc) * height_inc + baseh_inc;
Aspect ratio code is ok (which uses directly xSizeHint.base_*), only ResizeInc \
handling is wrong.
Yes, that gnome terminal "behaviour" is also a bug, but separate one, not \
the only one.
BTW hints of affected window:
WM_NORMAL_HINTS(WM_SIZE_HINTS):
program specified minimum size: 356 by 104
program specified resize increment: 9 by 18
program specified base size: 15 by 64
window gravity: NorthWest
</pre>
</blockquote>
<p>On January 30th, 2014, 1:26 p.m. CET, <b>Martin Gräßlin</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">@Thomas: I just verified \
and the comment is correct
I just tried with the values from the provided size hints and the problem is not \
reproducable. Thus the shrinking is related to client "playing WM".</pre> \
</blockquote>
<p>On January 30th, 2014, 1:42 p.m. CET, <b>Marek Marczykowski-Górecki</b> \
wrote:</p> <blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; \
padding-left: 10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; \
white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Yes, only \
in combination with clients "playing with WM" (which is separate bug, \
gnome-terminal this time) it causes window shrink, in all other cases, window simply \
will gets wrong size. Every sane application should simply accept those sizes, but \
still - there are inconsistent with hints because of bug, not because of some real \
need of WM.
For example window with:
WM_NORMAL_HINTS(WM_SIZE_HINTS):
program specified minimum size: 352 by 104
program specified resize increment: 9 by 18
program specified base size: 15 by 64
Can get size 775x320, which is (352 + 47*9) x (104 + 12*18), but not in form of (15 + \
i*9) x (64 + j*18).
To reproduce this bug, simply install and run gnome-terminal under KDE, it \
doesn't require whole Gnome installed.</pre> </blockquote>
</blockquote>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">ok I'm convinced ;-) \
I have my test-application in a state that it shows the problem and switching to \
base_width and base_height fixes the problem.</pre> <br />
<p>- Martin</p>
<br />
<p>On January 30th, 2014, 6:56 a.m. CET, Marek Marczykowski-Górecki wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" \
style="background-image: \
url('https://git.reviewboard.kde.org/static/rb/images/review_request_box_top_bg.ab6f3b1072c9.png'); \
background-position: left top; background-repeat: repeat-x; border: 1px black \
solid;"> <tr>
<td>
<div>Review request for kwin.</div>
<div>By Marek Marczykowski-Górecki.</div>
<p style="color: grey;"><i>Updated Jan. 30, 2014, 6:56 a.m.</i></p>
<div style="margin-top: 1.5em;">
<b style="color: #575012; font-size: 10pt;">Repository: </b>
kde-workspace
</div>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" \
style="border: 1px solid #b8b5a0"> <tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: \
-moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: \
break-word;">Use base_width/base_height if provided by the application and fallback \
to min_width/min_height only if not (according to ICCCM 4.1.2.3). Previously always \
min_width/min_height was used (if provided), even if base_width/base_height was also \
provided.
This fixes long standing bug with shrinking gnome-terminal window. Haven't found \
it in KDE Bugs, but described here: \
https://bugzilla.redhat.com/show_bug.cgi?id=707664</pre> </td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Testing </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: \
1px solid #b8b5a0"> <tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: \
-moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: \
break-word;">Tested patched kde-workspace-4.10.5 (Fedora 18), I don't any \
significant changes until now. Patched version allows normal gnome-terminal use, \
previously it was shrinking to minimal size.</pre> </td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>kwin/geometry.cpp <span style="color: grey">(6ae9666)</span></li>
</ul>
<p><a href="https://git.reviewboard.kde.org/r/115396/diff/" style="margin-left: \
3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>
_______________________________________________
kwin mailing list
kwin@kde.org
https://mail.kde.org/mailman/listinfo/kwin
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic