My previous fix for this broke the progress bar in epiphany. This fix
makes it work again, and keeps the gimp bug fixed.
Basically, whenever we do a non-double-buffered rendering we have to
flush the entire window as it might be drawn outside the double
buffering machinery.
Once we've made them popup windows we must also implement the popup_done event
handler on the shell surface listener. The best we can currently do is to hide
the window. This will then signal up to GTK which could then deactivate the
appropriate menu (see https://bugzilla.gnome.org/show_bug.cgi?id=670881)
This allows us to get the device if we need to make the window a popup. This
relies on the side effect that GTK calls into GDK to take a grab before the
popup window is shown.
Since it's generated, we install the header by putting it into
gdkinclude_HEADERS, so it's wrong to put it again into
gdk_public_h_sources.
This fixes the build.
This patch changes all uses of GDK_DEPRECATED(_FOR) in gdk headers
by the versioned variants, GDK_DEPRECATED_IN_3_x(_FOR). At the same
time, we add GDK_AVAILABLE_IN_3_x annotations for all API additions
in 3.2 and 3.4.
These macros follow the recent changes in GLibs deprecation
setup. We now annotate deprecated functions with the version
they were deprecated in, and you can define the macro
GDK_VERSION_MIN_REQUIRED to cut off deprecation warnings for
'recent' deprecations.
At the same time, we introduce version annotations for new API
and allow you to avoid 'recent' API additions by defining
GDK_VERSION_MAX_ALLOWED.
This last slave device (stored per master) is used to fill
in the missing slave device in synthesized crossing events
that are not directly caused by a device event (ie due to
configure events or grabs).
The F keys have no unicode mapping, and UCKeyTranslate() returns
a bogus 0x10 as mapping to unicode. Instead of checking for this
random and undocumented return value, simply assign all function
keys explicitly. This patch also splits the ill-named "known_keys"
array into "modifier_keys" and "function_keys" which is much
more obvious.
(cherry picked from commit 55f9e5cbaf)
Move g_return_if_fail() stuff from the backends to the public
functions in gdkscreen.c itself, and some fixes for ugly formatting in
the various gdkscreen-backend.c files.
_gdk_x11_keymap_key_is_modifier() never tries to set min/max_keycode
if they haven't been set before, meaning that until another function
sets those, all the keys will be seen as non-modifiers.
This causes GdkKeyEvents to be wrongly tagged with "->is_modifier = 0"
when in actual fact the key is a modifier. This fixes keyboard
shortcuts captured with GtkCellRendererAccel in "raw" mode thinking
a modifier without any actual keys is a valid shortcut.
https://bugzilla.gnome.org/show_bug.cgi?id=670400
We used to set a flushed boolean whenever we flushing double buffered
areas to the window due to a non-db draw. We then read back from the
window if this was set. This broke when we were doing multiple paints
of the same area after a flush as we were re-reading the window each
time, overdrawing what was previously draw.
This fixes issues where the new default bg of transparent
didn't work, making offscreen windows black.
I don't think this is a practical performance problem.
Offscreen windows are rarely used and generally used for
graphics tricks like alpha anyway.
This implements the following part of the EWMH spec:
"The special value _NET_WM_MOVERESIZE_CANCEL also allows clients to cancel the
operation by sending such message if they detect the release themselves
(clients should send it if they get the button release after sending the move
resize message, indicating that the WM did not get a grab in time to get the
release)."
In particular, it fixes the case of clicking widgets that use
gdk_window_begin_[resize|move]_drag*() and the click "sticking", i.e. the
mouse button getting released but the resize or move operation remaining in
effect.
https://bugzilla.gnome.org/show_bug.cgi?id=669208
Sometimes we need to read back the window content into our double
buffer due to rendering a window with alpha when there is
no implicit paint or it has been flushed due to non-db drawing
before.
However, in this case we can't use gdk_cairo_set_source_window as
it might trigger an implicit paint flush as we detect what we
think is a direct non-double buffered window draw operation, which
will flush the implicit paint operation that we're just setting up.
To fix this we use the raw gdk_window_ref_impl_surface operation
to get the source surface.
There was a sign issue in a coordinate transform that made us
flush the wrong region when flushing an implicit paint.
The non-double buffered drawing would then be drawn over the
right area, but then at the end of the implicit paint this
would be overdrawn with the area we didn't properly remove
from the implicit paint.
Also, the translation from window coords to impl window
coords is now done before removing any active double
buffered paints, as these are also in impl window coords.
With the changes in default CSS to make the default background transparent
we ran into issues where intermediate GdkWindow (for instance the
view_window in GtkViewport) where we didn't set an explicit background
(because before they were always covered). So instead of showing throught
the transparent windows were showing the default backgroind of the intermediate
window (i.e. black).
With this change we also needed to fix GtkViewport, as it was previously
relying on the bin and view windows to cover widget->window so that the
border was not visible if shadow_type was NONE.
When calling gtk_window_present(), gdk_win32_window_raise did not
actually raise the window anymore. Replacing BringWindowToTop() with
SetForegroundWindow() fixes this.
During testing, we also discovered that sometimes SetForeGroundWindow()
will (correctly) refuse to raise the window and fail(for example: sometimes
when dragging a different application at the time of a gtk_window_present()
call). To prevent a GdkWarning from being produced, usage of the API_CALL
macro has been removed for this case.
Additional goodies of SetForeGroundWindow:
- it brings the window to the front when the process owning the
window to raise is the foreground process (for example when
gtk_window_present is called from a GtkStatusIcon's activate
signal handler)
- it limits itself to flashing the task bar button associated
with the window if the process owning the window to raise
is *not* the foreground process (for example when gtk_window_present
is called from a g_timeout_add callback function)
https://bugzilla.gnome.org/show_bug.cgi?id=665760
Due to changes in the behaviour of the virtual modifiers around MOD1 the
implementation of the map_virtual_modifiers vfunc was mangling the modifiers
and making keybindings not work correctly.
This change updates the implementation to match the X11 implementation's
behaviour.
Callers of this function were passing in -1, -1 for the width and height if
they just wanted the window moving - rather than the size changing. We need to
respect that behaviour and don't try and set the width/height to those
dimensions.
Now pop-up windows (ala combo-boxes) work!
"The child window MUST also have the _NET_SUPPORTING_WM_CHECK property set to
the ID of the child window. […] If the _NET_SUPPORTING_WM_CHECK window on the
client window is missing or not properly set, clients SHOULD assume that no
conforming Window Manager is present."
This commit implements that, which allows us to not have to do a
XGetWindowProperty() every N seconds when running under a compliant WM.
This is also a more correct fix for the bug handled in commit
daf29bffed.
https://bugzilla.gnome.org/show_bug.cgi?id=666921
The part in gdkwindow-x11.c which uses XIEvent and friends is "protected"
by HAVE_XGENERICEVENTS, i.e., XGetEventData() has been found. (Xlib.h)
XIEvent and friends are defined in <X11/extension/XInput2.h> which is
included by gdkdisplay-x11.h if XINPUT_2 is defined.
The patch makes sure XIEvent is only used if XINPUT_2 is defined.
https://bugzilla.gnome.org/show_bug.cgi?id=667534
When we receive a configure event from Wayland telling us to resize our
surface we check against the geometry constraints for the window to ensure we
do not resize below the minimum and maximum limits.
Now that grab and ungrab vfuncs are implemented on GdkDevice then we can use
gdk_device_ungrab to break the implicit grab created by the button press that
triggered the resize and move.
An implicit grab is created inside GTK+ when the button is pressed down on a
window. The semantics of wl_shell_surface_resize means that you don't get a
corresponding release event that would ordinarily break the implicit grab. So
we must do it as part of the resize request.
This change follows on from a change in semantics in Wayland where calling
wl_input_device_attach with nil would make the compositor set the pointer
sprite to it's default cursor sprite.
When the X server does not support the shape extension (as some
vnc implementations seem to), our DND code was always seeing
an empty input shape, so drops always missed their target.
http://bugzilla.gnome.org/show_bug.cgi?id=620240
Apparently the deprecation warning macros are placed into gdkconfig.h
during the configure stage, so put these in the pre-configured
gdkconfig.h.win32 as well, as their definitions are needed for all builds.
Reading a card32 property into a long may lead to undefined high
bits, so mask them off. Also, make the conditions for setting and
unsetting the stick flag opposites, to avoid unintended changes.
Patch by John Lindgren, bug 666842
The current EWMH has added 'source indication' fields to a number
of client messages. Set these to 1 to indicate a regular client.
Also fill the button field of _NET_WM_MOVERESIZE.
==23282== 64 bytes in 2 blocks are definitely lost in loss record 8,069 of 13,389
==23282== at 0x4A074CD: malloc (vg_replace_malloc.c:236)
==23282== by 0x39A1C3E2EA: cairo_region_create (cairo-region.c:196)
==23282== by 0x6D9AF3D: recompute_visible_regions_internal (gdkwindow.c:964)
==23282== by 0x6D9B4B8: recompute_visible_regions (gdkwindow.c:1126)
==23282== by 0x6DA3450: gdk_window_hide (gdkwindow.c:5689)
==23282== by 0x6D9CED9: _gdk_window_destroy_hierarchy (gdkwindow.c:2042)
==23282== by 0x6D9D040: gdk_window_destroy (gdkwindow.c:2109)
==23282== by 0x655B5E4: gtk_entry_unrealize (gtkentry.c:3012)
==23282== by 0x7068BF3: g_cclosure_marshal_VOID__VOID (gmarshal.c:85)
==23282== by 0x706710B: g_type_class_meta_marshal (gclosure.c:885)
==23282== by 0x7066DF9: g_closure_invoke (gclosure.c:774)
==23282== by 0x7080585: signal_emit_unlocked_R (gsignal.c:3340)
==23282== by 0x707F619: g_signal_emit_valist (gsignal.c:3033)
==23282== by 0x707FB71: g_signal_emit (gsignal.c:3090)
==23282== by 0x679E243: gtk_widget_unrealize (gtkwidget.c:4458)
==23282== by 0x64E83C7: gtk_bin_forall (gtkbin.c:172)
==23282== by 0x6548BBD: gtk_container_forall (gtkcontainer.c:2014)
==23282== by 0x67A966D: gtk_widget_real_unrealize (gtkwidget.c:10253)
==23282== by 0x672D002: gtk_tool_item_unrealize (gtktoolitem.c:474)
==23282== by 0x7068BF3: g_cclosure_marshal_VOID__VOID (gmarshal.c:85)
https://bugzilla.gnome.org/show_bug.cgi?id=666552
This is a boolean property that will be set to TRUE if the current
desktop environment is capable of displaying the application menu as
part of the desktop shell.
If it is FALSE then the application will need to display the menu for
itself.
We want to avoid handling focus events for the private focus window,
otherwise the keyboard grab taken by for example buttons will cause a
spurious FOCUS_OUT/FOCUS_IN on the toplevel.
The code that did this seems to have been lost in the XI2 transition for
GTK3.
https://bugzilla.gnome.org/show_bug.cgi?id=657578
The function returns the part of a monitors area that should be
used for positioning popups, menus, etc. The only non-trivial
implementation atm is in the X backend, all the other backends
just return the full monitor area. The X implementation is
currently suboptimal, since it requires roundtrips to collect
the necessary information. It should be changed to monitor
the properties for changes, when XFixes allows to monitor
individual properties.
https://bugzilla.gnome.org/show_bug.cgi?id=641999
Dealing with disabled devices may turn into hierarchy/device
changed events on device IDs with no backing GdkDevice yet,
so protect against that. The device attachment will be handled
correctly when the device is enabled later.
