GNU bug report logs - #14326
24.3; Conflict of w32-send-sys-command and set-default-font

Previous Next

Full log

View this message in rfc822 format

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: eenliu <at> gmail.com, 14326 <at> debbugs.gnu.org
Subject: bug#14326: 24.3; Conflict of w32-send-sys-command and set-default-font
Date: Fri, 03 May 2013 08:48:27 +0200

>> That's what I'm wondering about.
>
> You cannot just call change_frame_size on Windows anyway.  It doesn't
> do what you'd expect.

I see no difference.  On Windows I call it when the window manager gets
back to me with the final frame size.  On X I call it after sending the
request to the window manager and a second time after the window manager
gets back to me (where the second call usually returns at "If we're not
changing the frame size, quit now.")  The first call on X makes no sense
as the event sequence on Windows demonstrates.

>> So w32-send-sys-command is handled differently from setting the
>> fullscreen frame parameter to maximized?
>
> Not really: the latter is implemented by calling the former (or
> actually doing the same independently).
>
>> Does this mean the OP could have used `set-frame-parameter' and it
>> would have worked in his sense?
>
> No, see above.

That's what I thought.  Hopefully `set-default-font`' at least resets
the maximized frame parameter.  In any case I'd consider it a bug that
`set-default-font' is allowed to resize a maximized frame.

>>  > By contrast, set-default-font works in the opposite direction: Emacs
>>  > _does_ understand what that means, it does know how to load a font and
>>  > get its metrics, and it does know how to resize the frame as result.
>>
>> But when x_set_window_size tells Windows that it wants to resize the
>> frame, it stumbles into some away-defined code.
>
> Not sure what x_set_window_size has to do with all this.

That's the routine we're talking about here (the one with the comment
about menubar wrapping, the one containing the ifdef'ed code, and the
one talking to the window manager via my_set_window_pos).

>> We do our own toolbar wrapping.  But the menubar is wrapped by Windows.
>
> And that is a problem because...?

... two.  Two problems.  Glad you asked.

When I fit the size of a frame to that of its buffer, I ideally would do
this in one `modify-frame-parameters' call to set the size of the new
frame.  But if this call shrinks the frame, both the menubar and the
toolbar may wrap and my calculations get ignored.  To avoid that I shall
have to proceed as below.

For the menubar the appropriate steps are:

(1) I calculate the new frame size and post a request to change the
    frame width.

(2) The window manager may decide that for the new frame width it has to
    wrap the menubar and does so by shrinking the height of my client
    rectangle and telling me the new sizes.

(3) I post a second request to set the new frame height.

This means that to handle the possibility that the menubar may wrap, I
have to post two separate resize requests to the window manager instead
of one.

For the toolbar the appropriate steps are:

(1) I calculate the new frame size and post a request to change the
    frame width.

(2) Emacs decides that for the new frame width it has to wrap the
    toolbar and does so by shrinking the height of my root window.

(3) I post a second request to set the new frame height.

This means that to handle the possibility that the toolbar may wrap I
have to split the resize request into two separate steps.  I don't have
to contact the window manager for the toolbar resizing case but since I
might have to do it for the menubar case anway I don't care.  Obviously,
this means that I send a second request to the window manager also when
only the toolbar wraps.

martin

Previous Next

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