For client-side windows, we need to queue a repaint when the background
changes. For native windows, the windowing system does take care of it,
but client-side windows are our own, so we gotta do it manually.
https://bugzilla.gnome.org/show_bug.cgi?id=652102
This adds missing annotations for gdk_window_get_position(),
gtk_window_get_position() and gtk_accelerator_parse().
Bug 644353, patch by Ulrik Sverdrup.
Previously we were copying from the toplevel window unconditionally.
This is wrong in two cases:
1) composited windows
2) different visuals
So when encountering such a window in the hierarchy, we stop going up
and just use the latest window as the source.
https://bugzilla.gnome.org/show_bug.cgi?id=643416
constructors which take an object of the same class as its first argument are
mis-detected as method call with "self" argument by the GIR scanner. Using the
new (constructor) annotation from bug 561264, mark some of them as proper
constuctors, so that you can call them with NULL as first argument from
bindings; in particular, this fixes gdk_window_new() and the
gtk_radio_button_new_with*() constructors.
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
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
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>
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.
Includes fixing all callers to use the cairo region API instead. This is
usually just replacing the function names, the only difference is
gdk_region_get_rectangles() being replaced by
cairo_region_num_rectangles() and cairo_region_get_rectangle() which
required a bit more work.
https://bugzilla.gnome.org/show_bug.cgi?id=613284
which also works for offscreen windows and their embedder.
Also add gdk_window_get_effective_parent() and
gdk_window_get_effective_toplevel() which are offscreen aware.
This commit was created using a script that searched for all docstrings
containing a parameter and the string 'or %NULL'.
Gdk backends and demos excluded as they are not part of a public API
https://bugzilla.gnome.org/show_bug.cgi?id=610474
We need to do this because otherwise the implicit button grab for this
(native) window will not deliver the button events not selected for
by this window. This is a problem because non-native child windows may
select using a wider event mask, and we can't emulate these events if we
don't get the native events.
Fixes bug #607508
When a cairo surface is requested for direct window access (i.e. not
when double-buffering) we can't really track when the actual drawing happens
as cairo drawing is not virtualized. This means we can't properly flush
any outstanding window moves or implicit paints.
This actually causes problems with e.g. abiword (bug #606009) where they
draw without double-buffering. If you press down it scrolls the window
and then draws the caret, but the caret drawing does not flush the
outstanding move from the scroll, so the caret gets drawn on the wrong
screen.
We fix this by never allowing either implicit paints or outstanding window
moves on impl-windows where any windows related to it has an outstanding
direct cairo surface. Luckily this is not very common so in practice this
doesn't matter much.
It may happen that a window gets destroyed during painting, if so
we should not draw the implicit paint double-buffered pixmap to it
as that will cause a BadDrawable X error.
This fixes bug 600865
The Gdk-custom.c file in gir-repository contained a number of
introspection annotations. Merge those into the GDK source files.
Some documentation was moved from the tmpl/ files to accomodate
the addition of annotations.
https://bugzilla.gnome.org/show_bug.cgi?id=592279
They don't need double buffer combination since they have no
client-side children, and creating pixmaps for them is risky
since they could disappear at any time.
May fix bug 598476 and 603652.
It may happen when turning a client side window into a native window
that the window, or some of its children with the same native parent
have extension events enabled, and thus have an input window enabled
for the native parent which needs to change as the window is made
native.
We fix this by temporarily disabling extension events on all the affected
windows while we create the native window, and then reenable them afterwards.
This fixes: https://bugzilla.redhat.com/show_bug.cgi?id=544624
We don't really need to filter these out, it was just a leftover
safety check to not override the GDK_POINTER_MOTION_MASK.
Furthermore when we changed behaviour to not always select for native
pointer motion it is actually wrong. We'll still get normal motion
events for the toplevel which we will emulate as button motion on the
child, but the button motion mask will not be inherited by implicit
grabs which makes us not get any motion events during grabs.
This fixes bug 601473
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
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.
