[COMMIT] Merge Ben's recent GUI changes into Carbon2 by hand.

[Ben Wing]

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
+     FRAME_CHARWIDTH/FRAME_CHARHEIGHT.
+
+     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
+         ourselves.
+  */
+

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.

ben