GPOINTER_TO_UINT() *does* drop the upper 32 bits on 64-bit
Windows. After all, it by definition produces a (32-bit) unsigned int.
The GLib commit mentioned in the reverted commit's log message just
means that it does this without any compiler warning about casting
from pointer to integer of smaller size, as it first casts to a 64-bit
integer, then casts that to a (32-bit) int.
We must use the GdkNativeWindow cast here so that on 64-bit Windows
the gpointer data in embedded_list is converted to a (64-bit) native
window handle without going through 32-bit truncation. If ifdefs are
required to avoid compiler warnings on X11, so be it then. Probably it
would be best to introduce a GDK_GPOINTER_TO_NATIVE_WINDOW() macro in
gdktypes.h.
This reverts commit 78151dc7d4.
Add support for putting widgets in the tab area, before or after
the tabs. This was requested a long time ago in bug 116650. The
implementation is the work of Johannes Schmid.
Either g_type_register_static_simple (used by G_DEFINE_TYPE_EXTENDED)
and G_IMPLEMENT_INTERFACE use automatic variables for GTypeInfo and
GInterfaceInfo structs, while tutorials and source code often use
static variables. This commit consistently adopts the former method.
https://bugzilla.gnome.org/show_bug.cgi?id=600158
When we just invalidate some area from the app we don't need to clear
windows with no exposure mask, because that wouldn't have happened pre-csw
anyway. Additionally we can avoid such clearing for native windows in cases
where the xserver already did the clearing like on exposes or when resizing
toplevels.
This means we don't fully redraw a GtkSocket when it resizes, thus
avoiding flicker in gnome-mplayer as reported in this bug:
https://bugzilla.gnome.org/show_bug.cgi?id=598050
Backends that support native window background setting (and that clears
new window areas to this color/pixmap) should set this to true.
Currently only X11 supports this.
When moving or scrolling a window with native children, there is no
need to expose the areas that are copied by the windowing system
as part of moving/resizing the native windows anyway.
Just use the C library instead to create the file. Helps building
using Wine. Not that I think we want to endorse that way to build GTK+
for Windows, proper cross-compiling surely probably more sense, but
accepting this minimal patch doesn't hurt. From bug #590017.
Signed-off-by: Tor Lillqvist <tml@iki.fi>
