Did this in the hope to reproduce infinite recursion bugs
with height-for-width in scrolled windows (see complex bgo #611740
for reference for now).

Add the composite overlay window to the cache, as this can be a reasonable Xdnd proxy as well.

This is only done when the screen is composited in order to avoid mapping
the COW. We assume that the CM is using the COW (which is true for pretty
much any CM currently in use).

https://bugzilla.gnome.org/show_bug.cgi?id=601731

The detail strings now have more "detail" by default, so gtkstyle.c
needed to be updated to properly handle this.  Tests like testtreeview,
testtreesort now have proper background drawing again.

This strncmp trick was the best I could think of so quickly, if anybody
has an idea to do this in a better way, let me know.

So that the symbol is not re-created each time the header is included.
The symbol is defined in gtktexttypes.c already.

h-align = START,END,CENTER,FILL
v-align = START,END,CENTER,FILL
margin-left,right,top,bottom
margin

These should obsolete all such similar properties on
layout containers, GtkMisc, GtkAlignment, GtkContainer::border-width

Margin is outside the size request.
If margin were not outside the set_size_request() it would not work the
same way as container-supplied (child property) padding.

Conceptually set_size_request() forces the value from the subclass
(the original unadjusted request) and then we go on to adjust
the request further by adding the margin.

A subclass calls gtk_container_class_handle_border_width()
in its class_init

This marks the subclass as expecting GtkContainer to deal with
border width automatically, which GtkContainer then does.

This will test size adjust, and interactions with other padding and border

Use these new methods to handle set_size_request (aka aux_info)
inside gtkwidget.c, instead of having external code mess with it.

The virtual functions can be used for other purposes in the
future. For example, GtkContainer::border_width could be
automatically implemented for all container subclasses.

Did not update uses in other files because the plan is to
get rid of those other uses anyhow. So don't want to make
this function available in the header.

This is better than peeking aux info then testing != NULL
in several ways:
- it returns const aux info so if we don't create we can't write
- it ensures that the default we assume if aux_info is NULL is
  the same as the default we set if we've created the aux info
- it avoids typing in != NULL checks

GtkFrame, GtkComboBox, GtkExpander, GtkMenu, GtkWrapBox

These are all the examples I could find so far.

https://bugzilla.gnome.org/show_bug.cgi?id=628829

We are not re-entrant and there is no reason for widgets to
do this, most likely they'll just get unexpected bugs because
the wrappers may modify the request.

Computing the request should logically rely only on the
widget itself, not on any adjustments caused by set_size_request,
size groups, and so forth.

https://bugzilla.gnome.org/show_bug.cgi?id=628829

In GtkBin and GtkWidget we tried to provide handy defaults that
call get_width if there's no get_width_for_height and
get_height for get_height_for_width.

However, they used the wrapper API on GtkSizeRequest instead of
chaining directly to the other method implementation.

This could result in all kinds of surprising behavior, for example,
get_width_for_height() would now already include the effects of set_size_request().

If nothing else it's inefficient. But it's just conceptually wrong,
because to chain to another implementation, we should call the other
implementation, not call a wrapper around the other implementation
(when we're already inside a previous invocation of the wrapper,
i.e. compute_size_for_orientation() ends up reinvoking itself
in the same orientation on the same object which it pretty
likely isn't intending to do)

https://bugzilla.gnome.org/show_bug.cgi?id=628829

32K of border ought to be enough for any pixel dimensions. At least
until screens are so huge we start using doubles.

This saves a nice 64 bits of space when we have a GtkBorder
stored somewhere.

Signed integers are used to avoid surprising unsigned math
issues. Just search GTK's whole git log from inception
for "unsigned" if you want to find any number of commits
fixing signed/unsigned bugs.

https://bugzilla.gnome.org/show_bug.cgi?id=629387

GScanner token field is declared as GTokenType instead a guint
See Glib bug: https://bugzilla.gnome.org/show_bug.cgi?id=627890

Fixes https://bugzilla.gnome.org/show_bug.cgi?id=627962

Point to gdk_device_manager_get_client_pointer(),
not gdk_display_get_client_pointer().

When writing the original code I erroneously assumed that the current
point of the cairo context would be saved by cairo_save/restore(), but
of course the current point is part of the path and therefor isn't
saved.

Also do a cairo_new_path() before rendering any text so that we are sure
the text ends up at the right spot.

We need to use gdk_threads_add_idle, in order to keep GDK code
under the GDK lock.

Bug 629277

This reverts commit 65b9fc3e.

Signed-off-by: Christian Dywan <christian@twotoasts.de>

Followup to bug 629093

This was the last exported variable; it wasn't multihead safe,
and there's easy replacement with gdk_display_get_default().
Also drop the GDK_DISPLAY() macro which was just a wrapper around
the variable.