With gtk_window_set_position gone, we should never
come up with a new position to set in this code.
Leave a warning in place and remove the gdk_surface_move
calls.
On Windows that call resizes the native window immediately,
and the corresponding GDK event is emitted and processed
before the control is returned to gtk_window_move_resize().
Therefore, update freeze and configure_request_count increment
must happen before the call, not after it.
I can't think of a case where this is the desired
behavior. So, instead of setting an explicit cursor
on all popups, just stop walking the parents at
surface boundaries.
We want to use a gdk_surface_new_popup for popups,
and align the constructor names with the surface
types, so rename
gdk_surface_new_popup -> gdk_surface_new_temp
gdk_surface_new_popup_full -> gdk_surface_new_popup
The temp surface type will disappear eventually.
Now that roots can have parent widgets, we need to
carefully examine all calls of gtk_widget_get_toplevel,
and replace them with gtk_widget_get_root if we want
the nearest root, and not the ultimate end of the parent
chain.
We had code in gtkwindow.c that generated duplicate,
and defective, focus-change events, in the following
way:
- gtkmain.c generates a chain of focus-change events
for moving focus from one window to another
- gtkwindow.c catches a focus-in event in the middle
of this chain and sets itself as 'active'
- and then it proceeds to generate focus-change
events towards its own focus widget without a
related target
This is not necessary since we gtkmain.c already
generates a complete sequence of focus-change events.
So stop doing it.
Export gtk_widget_root/unroot privately,
make them work on roots, and use them in
gtk_window_set_display. This gets us to a
single way to listen for display changes,
the root property.
When a modal dialog is smaller than its parent,
we were keeping the resize cursor from the dialogs
edge all over the parent window, which looks
really irritating, since the resize cursors are
closely associated with the window edge. Fix
this by falling back to the default cursor
outside the grab widgets surface.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/23
Set the cursor on the surface of the target
widget, not the surface of some of its parents.
This does not make a difference currently.
But it will in the future, when we have
parented widgets with surfaces.
Activating this action will replace other
activate_default apis. It is more flexible,
since intermediate widgets can intercept the
action and do their own handling.
