unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: martin rudalics <rudalics@gmx.at>
To: Eli Zaretskii <eliz@gnu.org>
Cc: eenliu@gmail.com, 14326@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	[thread overview]
Message-ID: <51835DBB.1060609@gmx.at> (raw)
In-Reply-To: <838v3xnpdo.fsf@gnu.org>

 >> 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





  reply	other threads:[~2013-05-03  6:48 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-01  1:34 bug#14326: 24.3; Conflict of w32-send-sys-command and set-default-font Eric Liu
2013-05-01  9:15 ` martin rudalics
2013-05-01 15:02   ` Eli Zaretskii
2013-05-01 17:33     ` Eric Liu
2013-05-01 17:37       ` Eli Zaretskii
2013-05-02  9:23     ` martin rudalics
2013-05-02 17:08       ` Eli Zaretskii
2013-05-02 18:32         ` martin rudalics
2013-05-02 18:55           ` Eli Zaretskii
2013-05-02 19:08             ` martin rudalics
2013-05-02 19:38               ` Eli Zaretskii
2013-05-03  6:48                 ` martin rudalics [this message]
2013-05-03  7:12                   ` Eli Zaretskii
2013-05-03  7:28                     ` martin rudalics
2013-05-03 14:59                   ` Drew Adams
2013-05-03 15:48                     ` Eli Zaretskii
2013-05-03 15:54                       ` Eli Zaretskii
2013-05-03 16:26                       ` Drew Adams
2013-05-03 18:04                         ` Eli Zaretskii
2013-05-03 18:19                           ` Drew Adams
2013-05-03 19:25                             ` Eli Zaretskii
2013-05-03 18:59                       ` martin rudalics
2013-05-03 20:06                         ` Drew Adams
2013-05-03 20:18                           ` Eli Zaretskii
2013-05-03 20:31                             ` Drew Adams
2013-05-04  6:37                               ` Eli Zaretskii
2013-05-04  7:50                                 ` martin rudalics
2013-05-04 14:17                                 ` Drew Adams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51835DBB.1060609@gmx.at \
    --to=rudalics@gmx.at \
    --cc=14326@debbugs.gnu.org \
    --cc=eenliu@gmail.com \
    --cc=eliz@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).