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.
These functions will be gone in Gtk 3.0 and be replaced by Cairo
functions.
Includes not disabling deprecated functions in old widgets that aren't
going to be ported.
49a0ec6e95 added this hunk without
explanations and it's obviously wrong because failing to have a get_size
vfunc will now not set width and height and they'll end up with invalid
values.
In fact, the GdkDrawableImpl{X11,Win32,Quartz} functions do not have
get_size implemented, so the patch was most likely an attempt to work
around calling this function erroneously on the impl objects.
The correct fix is to call impl->wrapper instead.
WM_KILLFOCUS means that a keyboard grab (not a pointer grab), if any,
has been broken. I don't think this bug has matterd much as gtk
generates a grab-broken-event signal for both keybord and pointer
grabs being broken anyway.
In debian/ubuntu, builddir != srcdir. This trigger an error on
introspection_files where srcdir is added to x11/*.c. Indeed,
srcdir is added again later: $(addprefix $(srcdir)/,$(introspection_files))
making $(srcdir)/$(srcdir)/x11/*.c (not an issue on jhbuild as srcdir = .)
We now exit early from gdk_window_register_dnd() to avoid crashing if the
window type is GDK_WINDOW_OFFSCREEN and does not support dnd operations.
This makes it possible to use any dnd-enabled widgets, such as GtkEntry,
within a GtkOffscreenWindow.
This reverts commit 5616bdc3dc.
I always thought cairo_region_t was a Cairo 1.8 feature. Apparently it
isn't, so the 3 patches I just reverted made Gtk depend on an unreleased
Cairo version. This is obviously not a good thing.
Expect those patches to reland once there's a Cairo 1.10 out (probably
around Gtk 4...)
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
Bug 615853 - BadMatch when pressing keyboard volume keys while pointer in
secondary X screen
_gdk_windowing_get_shape_for_mask() is using the default screen, not taking
into account that its GdkBitmap could have been created for a different one,
causing BadMatch errors.
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.
It doesn't make sense to determine an index into an array, if
you are going to sort the array afterwards...pointed out in
bug 615128 by Florian Scandella.
Currently gdk_screen_get_primary_monitor just returns the first monitor,
in this case but both the panel and now gnome-shell use an additional
heuristic to prefer LVDS as primary if present.
Move this heuristic to gdk_screen_get_primary_monitor to avoid duplicating
it all over the place.
The fallback heuristic is also used when no primary output is set.
https://bugzilla.gnome.org/show_bug.cgi?id=614894
One needs to add an explicit dependency between the gir files and the
.la libtool wrapper as this dependency is not added automatically by
Makefile.introspection. Not adding these breaks parallel builds as make
does not wait for the .la to be generated before launching g-ir-scanner.
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
It turns out that my attempt at handling Super, Hyper and Meta better
is causing problems, mostly because Alt and Meta are commonly colocated
in the modmap, and apps do a check for the Alt modifier regularly.
See e.g bug 607697.
Cursor sizes in DirectFB can be large (4095x4095), limit to 128x128
though, because the x11 backend has this limit, too - for max.
compatibility.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=609201
Signed-off-by: Javier Jardón <jjardon@gnome.org>
Use G_TYPE_INSTANCE_GET_PRIVATE() instead
In the process, convert to using G_DEFINE_TYPE, too.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=609195
Signed-off-by: Javier Jardón <jjardon@gnome.org>
On X11 we receive enter notify and motion notify events for a window
regardless of its focus state. On Mac OS X this is not the case. This
commit improves the semantics to overcome this difference. It improves
on my earlier patch that sent a motion notify event when a window became
main.
Instead of sending a motion notify when a window becomes main, we now
send one when a window becomes key, which comes closest to a window
getting focus in X11. This motion notify is needed because Mac OS X does
not send motion events when an application is inactive (none of its
windows have focus), these events are sent in X11. This dummy motion
notify event (with current coordinates of the mouse cursor) allows an
application to get its prelight and other state right when it gets focus
and thus user attention.
Another change is to send an enter notify event when updating the
tracking rectangle of a GdkQuartView and the mouse cursor is currently in
this rectangle. This rectangle is at least updated on window creation.
This enter notify event is important for the case where a new window
appears right below the mouse cursor. The window has to receive an enter
notify event for the subsequent events to be processed correctly. Mac
OS X does not send one in this case, so we generate it ourselves.
Both of these synthesized events have to go through
_gdk_windowing_got_event() for updating statekeeping, etc.
append_event() has a boolean flag now to make this convenient.
If e.g. the right edge of the leftmost rectangle is near MIN_INT, and
the left edge of the rightmost rectangle is large then subtracting these
can lead to an integer overflow, making the resultant "width" falsely
positive, thus returning a very wide result instead of the expected
no-intersection result.
We avoid the overflow by not doing the subtraction unless we know the
result will be positive. There are still risks for overflow if x + width
or y + width is larger than MAXINT, but we won't ever overflow for valid
rects now.
This may fix#607687
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
