> So this isn't a bug, but a limitation caused by the way Emacs's
 > interaction with the GUI systems is designed.

The first thing xg_frame_set_char_size (the function responsible for
dispatching the 'set-frame-size' call to GTK) does is to call
gtk_window_get_size to get the "current size" of the window showing the
frame.  The doc of that function says that

  * Depending on the windowing system and the window manager constraints,
  * the size returned by this function may not match the size set using
  * gtk_window_resize(); additionally, since gtk_window_resize() may be
  * implemented as an asynchronous operation, GTK+ cannot guarantee in any
  * way that this code:
  *
  * |[<!-- language="C" -->
  *   // width and height are set elsewhere
  *   gtk_window_resize (window, width, height);
  *
  *   int new_width, new_height;
  *   gtk_window_get_size (window, &new_width, &new_height);
  * ]|
  *
  * will result in `new_width` and `new_height` matching `width` and
  * `height`, respectively.

where gtk_window_resize (window, width, height) corresponds to our
(set-frame-size my/frame 10 10) and the gwidth and gheight used in the
earlier mentioned

       if (outer_width != gwidth || outer_height != gheight)

check are the new_width and new_height values returned by
gtk_window_get_size.  So since we've been warned by the GTK people, the
attached patch which removes that conditional seems in order.

Note that all other uses of gwidth and gheight remain in place and may
cause the above mentioned problems so maybe we should warn about this in
PROBLEMS.

martin