Currently a "window:resize" is emitted whe a toplevel moves about. Are you
saying that the name of the event should be changed or that an additional event
should be emitted?

"resize" ought to be emitted when a toplevel's size changes, and "move" ought to
be emitted when the toplevel is repositioned.  We could consider using a unified
"move-resize" event instead, of course.  But since we probably don't want to
remove the old event name altogether (for compatibility), perhaps add the new
one makes the most sense.  Is it difficult to distinguish between the two cases,
from an internal-implementation perspective?

It is possible to distinguish between move and resize.

One concern I have is that on a window resize we may not be able to find out the
new size of the window if the GtkWindow does not change its allocation.

Created attachment 28735 [details] [review]
Proposed patch

Patch committed to CVS HEAD.

I have found that this patch causes applets and menu not to be displayed on the
panel when GNOME is started with accessibility enabled. I have reverted the
patch.

IN order for magnifiers to track properly, we need a fix for this eventually.

I agree this should be fixed eventually.  However, is this really AP2 at this
point?  The two ways of moving/resizing a window at present are: (1) use the
mouse, or (2) use the keyboard [which moves the mouse].  Since magnification
tracking works when the mouse moves...

windows move and change size for reasons other than direct end-user action.

For instance, if panels/struts change, etc. or if users issue keyboard shortcuts
to the window manager, etc.

and of course, magnifier tracking isn't always using mouse-tracking mode.

I stand by AP2 since this means 'P3', i.e. not a stopper but still on the radar.

Created attachment 29894 [details] [review]
New proposed patch

This patch causes resize or move signal to be emitted when top level window
moves and gnome-panel starts correctly when using this patch.

New proposed patch committed to CVS HEAD.