[COMMIT] Merge Ben's recent GUI changes into Carbon2 by hand.
ben at 666.com
Sat Mar 6 01:52:18 EST 2010
On Fri, Mar 5, 2010 at 11:56 AM, Aidan Kehoe <kehoea at parhasard.net> wrote:
> Ben, this is a manual commit that integrates the changes you warned
> about. I’m a bit suspicious of the code with
> /* Redisplay still thinks the window has the old height if these
> are not changed. */
> from Choi, but with the below it runs, anyway. If you see any obvious
> problems with it, shout.
I was actually just wondering how those values got set. I went and
figured it out and added this comment:
+ /* Set the value of FRAME_WIDTH/FRAME_HEIGHT and
+ Question: Where is FRAME_PIXWIDTH/FRAME_PIXHEIGHT set?
+ Answer: In the device-specific code, as a result of a callback from
+ the window system indicating that the frame has changed size.
+ This happens:
+ (1) in the WM_SIZE processing in event-msw.c
+ (2) in update_various_frame_slots() called from EmacsFrameResize()
+ (called from Xt when the frame is resized) in EmacsFrame.c for X
+ (3) in resize_event_cb() in frame-gtk.c
+ (4) For TTY's, there is no such callback, so we have to set it
It looks like you should be setting these in
handle_window_bounds_changed_event(), assuming that it's called
whenever a window is resized, including programmatically, which I
assume to be the case, based on that infinite loop in the frame-sizing
code that you had to code around. I have no idea what's going on
there -- I don't recall changing anything that should affect this.
However, it doesn't look like the resize callback should be calling
the set_frame_size() device method at all -- it's understandable that
this would produce an infinite loop, and neither the MS Windows nor Xt
code does anything similar.
More information about the XEmacs-Patches