xfwm appears to ignore changes to WM_NORMAL_HINTS after mapping
Sam Varshavchik
mrsam at courier-mta.com
Mon Aug 24 13:24:07 CEST 2015
Olivier Fourdan writes:
> Hi
>
>
> Best way to investigate such issue is to provide a simple reproducer in C.
>
>
> Cheers,
> Olivier
Thank you for prodding me in the right direction. The simple reproducer is
below.
The problem I'm seeing can be triggered on or off simply by adding or
removing the extra xcb_flush() and sleep() statement. With the sleep in
place, wait for the "Ok" message. The app window will not be resizable.
Remove just the flush+sleep, and I can resize the app window horizontally,
just fine.
For the simple reproducer, I didn't bother adding the code to draw anything
in the app window. This is just sufficient to get xfwd to draw its frames to
indicate where the window is on the desktop.
Initially, I wrote the reproducer without the extra flush+sleep, just
replaying the X requests that I expected my app to send. I couldn't
reproduce it! After thinking about it, for a few minutes, I added the sleep,
and there you go!
The real app does quite a bit of work before computing the final window size
range and setting the final window manager hints, which is apparently long
enough for xfwm to look at its initial hints, and write it off as non-
resizable.
I cannot yet say with 100% certainty, but it looks to me like if the initial
WM_SIZE_HINTS that xfwm sees indicate that the window is resizable, xfwm
does pay attention to subsequent app updates to WM_SIZE_HINTS. If I have my
app set the initial WM_SIZE_HINTS to indicate that it's resizable, what I
see is that xfwm will honor any subsequent updates. If I update my app
window's WM_SIZE_HINTS so that the indicates maximum or minimum is outside
of the current actual window dimensions, it looks to me like xfwm will
obediently adjust my app window to comply.
The problem seems to happen only when xfwm sees the mapped window's initial
state as non-resizable. Thanks:
#include <xcb/xproto.h>
#include <xcb/xcb_icccm.h>
#include <string.h>
#include <unistd.h>
#include <stdio.h>
int main()
{
int screen_number_ret;
xcb_connection_t *conn=xcb_connect(0, &screen_number_ret);
const struct xcb_setup_t *setup=xcb_get_setup(conn);
xcb_screen_iterator_t iter=xcb_setup_roots_iterator(setup);
xcb_window_t root=iter.data->root;
xcb_window_t app=xcb_generate_id(conn);
xcb_size_hints_t hints;
xcb_atom_t wm_normal_hints;
char buffer[1024];
static const char wm_normal_hints_name[]="WM_NORMAL_HINTS";
xcb_create_window(conn, iter.data->root_depth, app, root,
100, 100, 300, 300, 0,
XCB_WINDOW_CLASS_INPUT_OUTPUT,
iter.data->root_visual, 0, 0);
memset(&hints, 0, sizeof(hints));
xcb_icccm_size_hints_set_min_size(&hints, 300, 300);
xcb_icccm_size_hints_set_base_size(&hints, 300, 300);
xcb_icccm_size_hints_set_max_size(&hints, 300, 300);
wm_normal_hints=
xcb_intern_atom_reply(conn,
xcb_intern_atom(conn, 0,
sizeof(wm_normal_hints_name)-1,
wm_normal_hints_name),
0)->atom;
xcb_icccm_set_wm_size_hints(conn, app, wm_normal_hints, &hints);
xcb_map_window(conn, app);
/*
** This flush and sleep is required to reproduce the bug.
** With this in place, the app window is not resizable.
**
** Without the sleep, the app window is resizable!
*/
xcb_flush(conn);
sleep(5);
xcb_icccm_size_hints_set_min_size(&hints, 1, 300);
xcb_icccm_size_hints_set_max_size(&hints, 1920, 300);
xcb_icccm_set_wm_size_hints(conn, app, wm_normal_hints, &hints);
xcb_flush(conn);
printf("Ok, go ahead and try to resize the window horizontally\n");
fgets(buffer, sizeof(buffer), stdin);
}
> On 23 August 2015 at 17:48, Sam Varshavchik <<URL:mailto:mrsam at courier-
> mta.com>mrsam at courier-mta.com> wrote:
>
> Currently I have an application window that, according to xprop(1), has
> the following properties:
>
> WM_NORMAL_HINTS(WM_SIZE_HINTS):
> program specified minimum size: 89 by 277
> program specified maximum size: 1912 by 277
>
> So, the application window claims that its horizontal size can be
> adjusted, and its vertical size is fixed. So I should be able to resize
> this application window horizontally.
> If I prepare to grab either the left or the right border with the pointer,
> immediately upon hovering over the border xfwm (4.12) changes the mouse
> icon to an arrow in the appropriate direction, supposedly indicating that
> the application window can, indeed, be resized.
>
> However, as soon as I actually grab the appropriate border, the mouse icon
> changes to a hand, and instead of resizing the application window, xfwm4
> drags the entire window, changing its position, but keeping its existing
> size the same.
>
> It appears to me that xfwm4 reads WM_NORMAL_HINTS only when the
> application window gets mapped. At the time this application window got
> mapped, its WM_NORMAL_HINTS indicated a fixed size, with minimum and
> maximum width being the same (about the middle of this range). But after
> the window got mapped, my application updated its WM_NORMAL_HINTS to the
> values shown above.
>
> If I change the application to indicate an adjustable horizontal range
> before the window gets mapped, xfwm4 will let me resize the application
> window normally.
>
> I have not done enough experimentation to determine whether or not xfwm
> pays attention to updated WM_NORMAL_HINTS, as long as the initial values,
> when mapped, indicate an adjustable size (meaning that this occurs only if
> the initial WM_NORMAL_HINTS, upon mapping, reported a fixed size).
>
> Does this look like a bug, or am I failing to implement some parts of
> icccm that prod the WM to look at WM_NORMAL_HINTS again?
>
> _______________________________________________
> Xfce mailing list
> <URL:mailto:Xfce at xfce.org>Xfce at xfce.org
>
> <URL:https://mail.xfce.org/mailman/listinfo/xfce>https://mail.xfce.org/mai
> lman/listinfo/xfce
> <URL:http://www.xfce.org>http://www.xfce.org
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://mail.xfce.org/pipermail/xfce/attachments/20150824/bedeae45/attachment.sig>
More information about the Xfce
mailing list