GNU bug report logs - #19990
24.4; Bad resizing interaction when WM ignores size hints

Previous Next

Full log

View this message in rfc822 format

From: "Jan D." <jan.h.d <at> swipnet.se>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 19990 <at> debbugs.gnu.org, Yuri D'Elia <yuri.delia <at> eurac.edu>
Subject: bug#19990: 24.4; Bad resizing interaction when WM ignores size hints
Date: Fri, 6 Mar 2015 18:00:14 +0100

> 6 mar 2015 kl. 10:21 skrev martin rudalics <rudalics <at> gmx.at>:
> 
> > The window manager can resize the window, for example when you drag on
> > its corners, or when you maximize it.  Or it can intercept Emacs
> > resize request and modify it, so it is consistent with size hints.  In
> > both cases a ConfigureNotify is sent.  Gtk+ does receive it.
> 
> In gtk_window_configure_event?

No, in the Gtk+ event handler.

> 
> > The
> > problem is that Gtk+ then tries to apply size hints also.
> 
> Via gtk_window_move_resize?  Which, in principle, is not entirely wrong.

Yes it is.  They are called window manager hints for a reason.

> Emacs gets what it asked for.  Can't we reset the size hints in between?
> That's what I earlier meant by "interception".

I don't follow.

> 
> > Focus events does not contain any information about width/height and
> > can't be taken as a resize request.  That would be kind of perverse,
> > focus has nothing to do with resize.
> 
> Didn't the OP mention that during a focus event a resize also took
> place?  That's what he said:
> 
>   However, when receiving a FocusIn event (just by cycling focus),
>   emacs properly aligns the minibuffer to the bottom, and displays a
>   partially-visible line just above the minibuffer (test_after.png).

Emacs must have received a ConfigureNotify to adjust its size.  It is possible the OP missed it.

> 
> >> Apparently no such measure is needed for fullheight/-width frames.
> >
> > The bug report that lead to the change mentioned no such problems.
> 
> The OP said that:
> 
>   I force the emacs frame to take the height of the entire screen.
> 
> So this looks like a fullheight frame to me without, apparently,
> explicitly specifying it as such.

I meant the bug report that prompted our resetting size hints for fullscreen.
I think he said that he used a tiling window manager, so it is not a fullheight frame.

> 
> > The window manager is what does the fullscreen happen, so it is free
> > to ignore any hints, i.e. hints should not matter, fullscreen takes
> > precedence.  But in principle hints during fullscreen may not reflect
> > the "true" state of affairs.
> 
> Maybe the OP's problem is that the Window manager conceptually gives
> Emacs the full height of the screen and Gtk+ is not aware of that.
> Maybe also Gtk+ doesn't even understand fullheight.  At least I can't
> detect an entry for it in GtkWindowPrivate which OTOH has a 'tiled'
> entry.

It is none of Gtk+ business to know about fullscreen.  It is something between Emacs and the window manager.  Gtk+ gets sizes from the X server and the window manager via ConfigureNotify and should just accept what it gets.

	Jan D.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.