When setting no shape on an unshaped window, nothing changes,
so return early instead of recomputing lots of visibility
information.
Pointed out by Owen Taylor in bug 637156.
Previously we used the size of the csw window, which could easily be
huge and cause CAIRO_SURFACE_INVALID_SIZE errors. If we use the real
size, we work around this problem. The surface can now potentially be
bigger than before but we should handle that when clipping in csw.
https://bugzilla.gnome.org/show_bug.cgi?id=633701
Switch all usage of device color spaces to generic color spaces. Since
the former color spaces are no longer device-dependent as of Mac OS X
10.4, these yielded a very costly color space conversion when drawing
pixmaps to the screen. We now avoid this by using the generic color
space.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=624025
If the data that backs a bitmap context changes, then the CGImage that
is backed by this data might not always update due to caching effects.
By creating the CGImage on-demand, we ascertain ourselves that the
CGImage is up to date.
Allow -1 for the hotspot coordinates in gdk_cursor_new_from_pixbuf,
if the pixbuf contains the x_hot/y_hot options with appropriate values.
Bug #632140.
This commit adds
gdk_window_get_display
gdk_window_get_screen
gdk_window_get_visual
gdk_window_get_width
gdk_window_get_height
and deprecates the corresponding GdkDrawable APIs.
This will make it easier to prepare the port to GTK+ 3
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 keysyms create a lot of potential namespace conflicts for
C, and are especially problematic for introspection, where we take
constants into the namespace, so GDK_Display conflicts with GdkDisplay.
For C application compatiblity, add gdkkeysyms-compat.h which uses
the old names. In GTK2, this header is included by default.
https://bugzilla.gnome.org/show_bug.cgi?id=629093
Add an ugly workaround because GTK does not ensure surfaces get flushed
before directly accessing the drawable backed by the surface. This is
not visible on X11 (where flushing is a no-op), but can be seen on
Windows.
https://bugzilla.gnome.org/show_bug.cgi?id=628291
The attributes struct has some members that aren't covered by the
attributes_mask so they should always be filled in. The Win32 backend
was using the window type member when creating the window
implementation. Previously this was left uninitialized so it would end
up thinking the window is input_only and nothing would get painted.
https://bugzilla.gnome.org/show_bug.cgi?id=628049
Signed-off-by: Hans Breuer <hans@breuer.org>
Bug 628656 - _gdk_windowing_get_startup_notify_id memory leak
get_display_name() returns a newly allocated string, which was being fed
directory info a g_strdup_printf() call.
(cherry picked from commit bf3b5f785e)
TrackMouseEvent is present in user32.dll in all Windows versions we
support. No need to look it up dynamically. No need to fallback to
_TrackMouseEvent from comctrl32.dll.
When GDK looks for the window under pointer, the gdk-directfb backend
looks at windows starting from the root window to the upper window in
the stack. For this, it looks at window's size and position. This
patch fix the assumption that windows are always natives windows from
which we can retrieve backend's private data.
Signed-off-by: Lionel Landwerlin <llandwerlin@gmail.com>
Since GDK has introduced the offscreen window concept, pixmap can be
created using drawables which aren't native windows. This patch fix
this assumption.
Signed-off-by: Lionel Landwerlin <llandwerlin@gmail.com>
The window management code used to deal with gdk internals. It seems a
lot of code has been pushed to the generic gdk code, so we remove
useless code.
Signed-off-by: Lionel Landwerlin <llandwerlin@gmail.com>
Make it look more like the x11 backend. Also some people reported
crash early in the backend initialization about some colormap stuff,
this should avoid the problem.
Signed-off-by: Lionel Landwerlin <llandwerlin@gmail.com>
The event translation code used to deal a lot with gdk internals. It
seems a lot of code has been pushed to the generic gdk code, so we
needed to rewrite the things a little bit.
Signed-off-by: Lionel Landwerlin <llandwerlin@gmail.com>
The computation of abs_x,abs_y is done by the generic code of GDK when
events are raised. We don't care about that anymore.
Signed-off-by: Lionel Landwerlin <llandwerlin@gmail.com>
- attributes->wclass is not consistently set anymore,
use private->input_only instead [1]
- don't put window into parent->children a second time
(now there is no window reference problem anymore)
The button highlighting in testgtk works again, even with
GDK_NATIVE_WINDOWS. Unfortunately testgtk:menus still does
not work for the forced-native-window-case.
In _gdk_window_move_resize_child it tries to decide whether to pass
SWP_NOSIZE and SWP_NOMOVE based on whether the new size and position
is different from the window's existing position. However it seems
that GDK now ends up updating the window's position before calling
_gdk_window_move_resize_child so this would mean it would think the
window never changes size or position so SWP_NOSIZE|SWP_NOMOVE would
always be set. This causes child windows to never be resized.
This patch changes it so that it never passes either flag to
SetWindowPos. I don't know whether this will cause any side effects
but you'd think it shouldn't do any harm to reassert the current size.
https://bugzilla.gnome.org/show_bug.cgi?id=628049
Signed-off-by: Hans Breuer <hans@breuer.org>
This is an adapted version of commit
bde0f9a8f6 on master.
Mainly fixes to properly differentiate bewteen toplevel and offscreen
windows, since these sometimes need different treatment. Furthermore,
usage of gdk_window_get_effective_foo() instead of gdk_window_get_foo()
where applicable.
There is an drawing issue left when scrolling e.g. tree views in
offscreen windows. I think this is likely an issue with
gdk_quartz_draw_drawable() which is used for the copy area code in
offscreen windows. It works fine in master, since this was converted
to Cairo.
They were added as accessors for 2.22 even though querying the
background wasn't possible previously. As GTK 3.0 will change background
handling, it doesn't make sense at all to expose these getters.
