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: Yuri D'Elia <yuri.delia <at> eurac.edu>
Cc: martin rudalics <rudalics <at> gmx.at>, 19990 <at> debbugs.gnu.org
Subject: bug#19990: 24.4; Bad resizing interaction when WM ignores size hints
Date: Fri, 6 Mar 2015 18:05:26 +0100

> 6 mar 2015 kl. 11:53 skrev Yuri D'Elia <yuri.delia <at> eurac.edu>:
> 
> On 03/06/2015 10:21 AM, martin rudalics wrote:
>> 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 should have never said 'full screen height', since this keeps
> confusing you. In my particular configuration, I have no window borders,
> so two windows side-by-side will automatically fit the screen height.
> This is *not* a special case for a tiling window manger.
> 
> A tiling window manager will force the frame to fit a screen region,
> _possibly_ ignoring size hints. That's all there is to it. It does that
> *intentionally*, since you can imagine that having gaps between the
> tiles is just plainly annoying. In a side-by-side configuration, you
> don't want gaps on the lower corner of the screen.
> 
>> 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.
> 
> The problem with Gtk+ is that it tries to handle hints both on behalf of
> the window manger and on the client. I have *no* clue of why it does
> that. Maybe to handle TWM? Or more probably to handle the "Windows" port
> which has no such feature?

Thats sounds reasonable.  Probably also Wayland which has no window manager.

> 
> The second issue with Gtk+ is that it notifies the application while
> doing his own hint handling (or again, is that intentional?).
> 
> I would be perfectly happy to discuss this issue with Gtk+ folks, but I
> remember that back in Gtk 1.3/2.0 days, many of my patches where
> rejected since they fixed behavior that wasn't really intended "for the
> common user", whatever that means. Gtk 3 seems to have regressed even
> more in this area, so I just gave up in trying to argue.

I have no better experience than you.

> 
> To sum up, however, what about this:
> 
> Since we receive the first ConfigureNotify event with the unhinted
> width/height, we *can* detect that the size hints have been ignored.
> Couldn't we disable them at that point?

At what point would we re-enable them?

> This would fix Gtk+ trying to do
> a reconfiguration attempt and remove the following two useless events.
> This looks like a simple fix that would already improve the current
> configuration, but I would need experience with the Mac/Win port to tell
> if Gtk would fail in this scenario. Maybe an "ifdef X11" is required.

The NS/W32 port of Emacs can't use Gtk+ so it is already X11 only.

> 
> The question then becomes: would actually be possible to set the hints
> immediately back on, so that in a further resize request the WM sees the
> hints, but *without* having Gtk+ do it's mess? This would mean that we
> would need to set the hints back on when the resize request has been
> fully settled. Tricky. Setting them back-on on a further repaint/focus
> in/out event is either too late or not enough.
> 
> As mentioned in my first request, this is a minor nuance fix for folks
> with tiling window managers. My point is "can we handle it better?".

	Jan D.

Previous Next

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