bug#19990: 24.4; Bad resizing interaction when WM ignores size hints

[Jan D.]

> 6 mar 2015 kl. 11:53 skrev Yuri D'Elia <yuri.delia@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.