bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[martin rudalics <rudalics@gmx.at>]

 > But if we somehow could provide Drew with the frame dimensions that
 > _should_ have resulted from the two changes his code does, then he
 > could add a call to set-frame-size to request precisely those
 > dimensions, and that should fix his problem, no?

I'm not sure.  In principle Drew should be able to thumbify as follows:

(1) Save the current pixel sizess, font and scrollbar width.

(2) Set the new font size.

(3) Set the new scrollbar width.

(4) Set the new pixel sizes to some calculated from the ones saved in
     (1) and the scale factor used in (2).

To dethumbify he would have to

(5) Set the new font size to the one saved in (1).

(6) Set the new scrollbar width to the one saved in (1).

(7) Set the new frame pixel sizes to the ones saved in (1).

I don't know whether this correctly restores window start positions but
at least it seems the only sane way to fix his problem with the current
trunk.

We could obviously store the new pixel values and either let any size
changing functions use the new values or provide a Lisp interface to
them and let Drew use that value in his calculations.  Doing so would,
however, not eliminate the fact that the state of Emacs is inconsistent
while a resize operation is pending because the value returned by
`frame-pixel-height' is not in line with that of `frame-height'.  The
programmer would still have to be aware of this inconsistency and
explaining such a thing in the manual or a doc-string would be quite a
nuisance.  BTW, when creating a new frame, the inconsistency should be
observable on GNU/Linux as well.

I see only two ways to solve this inconsistency:

(1) Find some way to synch with the window manager as we do on
     GNU/Linux.

(2) Apply the size changes with the commented-out code.  The comment
     motivating why we should not do this on Windows because of the
     menubar wrapping issue doesn't make sense to me anyway: If we and
     Windows can handle wrapping, we'll do that when Windows gets back to
     us.  And the worst thing that could happen to us is that parts of
     the frame (including the modeline) might get obscured.  But this is
     something I plan to do anyway when shrinking a frame below the
     minimum size to accomodate all of its windows.

WDYT?

martin