_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.
For maximized windows, titlebars cannot be used to reposition or
scale the window, so if an application does not use it to convey
useful information (other than the application name), the screen
space occupied by titlebars could be put to better use.
Add a new window property which requests from the window manager
to hide titlebars when windows are maximized to account for this.
https://bugzilla.gnome.org/show_bug.cgi?id=665616
Setup listener functions for the drag and drop events as well as the selection
events. Then create and save a data structure representing the data offer from
the other client.
This implementation is based on a hash table. The hard coded GtkSelection
atoms are preloaded into the hash table at the correct values. User generated
atoms start after the last preloaded atom.
The data device manager is a global object that provides the support
infrastructure around data devices. These data device objects are the basis
for handling drag and drop as well as selections in Wayland.
As pointed out in bug 665999, these were just not right.
Before this commit, the nicks were 'output' and 'only'.
After this commit, they are 'input-output' and 'input-only'.
This means we don't have to have hardcoded "/usr/share/wayland" to find the
cursors.
This change also fixes up the warning messages for when loading fails.
When an implicit paint is flushed during expose, e.g. because a
non-double buffered widget is painting, make sure to copy the existing
data from the window surface we rendered before flushing back to the
paint surface, instead of using an empty base.
Code was already handling that (and said so in the comment), but only
when no implicit paint was used at all, and not in the case when it's
flushed mid-expose.
Previously all the commands that acted on the shell took the surface that was
to be acted on as parameter. Now we retrieve an object from the shell that
represents its state for the surface. With that wl_shell_surface object we can
then call methods on that.
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
gdk_window_get_update_area is supposed to get the area where things
need painting, and remove them from the update areas. However, if
some area is covered by other windows with an alpha background we
can't just expect whatever the app choses to render in the update
area as correct, so we don't actually remove these areas, meaning
they will get correctly rendered when we get to the expose handlers.
gdk_window_move_region doesn't move children, so we can't copy
transparent child window regions with copyarea, so we remove these
from the copy region.
We track the areas that have alpha coverage so that we can
avoid using these as sources when copying window contents.
We also don't remove such areas from the clipping regions so
that they are painted both by parent and child.
This cleans up the expose handling a bit by using the existing
clip regions, and it allows us later to use painters algorithm
to do transparent windows.
This turns GdkWin32DragContext into a proper GdkDragContext subclass.
Because we now correctly initialize GdkWin32DragContext in
gdk_drag_context_new, we no longer crash immediatly when a DnD
operation is initialized (the find_window, drag_status, ... vfuncs
where all pointing to 0x0 instead of their proper win32 implementations).
We now try to consistently refer to GdkDragContext as "context",
GdkWin32DragContext as "win32_context" and the ole2 related
target_drag_context and source_drag_context as "ctx".
Members of GdkWin32DragContext only used by the ole2 DnD codepaths
are now explicitly marked with a ole2_dnd_ prefix.
gdk_cairo_region_create_from_surface doesn't work correctly on PPC.
This is most prominently seen with the GTK window resize grip, the
shape of which is mirrored every eight pixels horizontally.
At the same time, use an A1 surface for the resize grip shape to
eliminates an A8->A1 surface conversion.
Add GDK_MODIFIER_INTENT_SHIFT_GROUP to enum GdkModifierIntent
and handle it in gdk_keymap_get_modifier_mask(). Add an X11
impl of the method and return keymap_x11->group_switch_mask.
Return 0 from the default impl because we don't know.
If the keyboard group shifting modifier is *also* a normal
accelerator modifier, we need to special case it when calling
gdk_keymap_translate_keyboard_state(), so we get the right
key symbol for accelerators (for example we want Option-O,
not Option-Ø displayed in menu items). This patch should only
affect quartz where the Alt key both shifts the group and can
be used as accel modifier, and not X11 or Win32 where AltGr
is not used for accelerators.
- fix quartz' gdk_keymap_translate_keyboard_state() to return
the right consumed_modifiers
- add _gtk_translate_keyboard_accel_state() which does the
special casing
- use it everywhere instead of gdk_keymap_translate_keyboard_state()
g_checksum_get_digest checks to ensure that the passed digest_len is long
enough to hold the digest, before setting it to the actual length of the
digest returned. Digest_len is uninitialized in the code, so if you're
lucky it will be larger than 20 and everything will work fine. If you're
unlucky, g_checksum_get_digest will return either -1 or some number less
than 20, and the g_assert(digest_len==20) will fail.
Wake up the run loop unconditionally (don't check if it is waiting) because
it might go into waiting state right after we checked for it. Fixes GIMP
startup (which has a lot of GIOChannel I/O but zero NSEvents) from several
minutes to a few seconds.
(cherry picked from commit 0729cdc9a1)
We now do proper handling of existing invalid regions, and
we use ScrollDC which allows us to specify the right clip
region rather than just the bounding rect.
Positioning windows at 0,0 post creation failed, because it
was mapped with CW_USEDFAULT, but private->x/y still said 0,
so moving it to 0,0 did nothing. We now always position the
window at the right place, even when not mapped, but we
create it at CW_USEDEFAULT initially and store that position
before moving it to the right place.
This fixes the window sizing test in testgtk and the inital
position for the gimp toolbar.
The synaptics trackpad driver has some weird behaviour on scroll.
It pops up a window over the mouse pointer (looking like a scrollbar).
This has two problems:
* We get extra enter/leave events for the trackpad window
* We get back the trackpad window when we look for the window
under the mouse to deliver the mousewheel message.
So, we add some trackpad specific hacks to avoid this (sigh) based
on the trackpad window window class.
This fixes bug #542777 and was partially based on a patch there
from Peter Clifton.
gdk_flush() should gdk_display_sync() on all open displays.
Both for display_flush and display_sync it seems useful to call
GdiFlush, but we don't have anything extra to do for display_sync,
as there is no inherent roundtrip on win32.
This should close bug #84314
Windows with transients: center on parent
Splash screens: center on monitor
Also properly ignores initial moves of unmapped
windows that are not override redirect or HINT_POS
Fixes bugs #324254 and #612359
There were still cases where we didn't get a WINDOWPOSCHANGED after
a SetWindowPos() call, like e.g. with a larger minimum size than
the set size (bug #574935)
So, we revert the previous fix and now just always manually emit
a configure notify after the move_resize call. Also, we inhibit
the WINDOWPOSCHANGED configure event during the move_resize operation
to avoid multiple Configures.
There are some cases where we don't get a WINDOWPOSCHANGE such that
we generate a configure event, even if we called gdk_window_move_resize()
or similar. For instance:
* The window is fullscreen
* The window is maximized
* The specified pos/size is the same as the current one
However, as per X11 ConfigureNotify semantics we *always* want one, or
we could run into issue like e.g. bug #537296 where we're waiting for
the CONFIGURE to call gdk_window_thaw_toplevel_updates_libgtk_only().
We always get the WM_DESTROY message anyway, and we remove it there.
Bug #336416 even claims this could be a leak if the WM_DESTROY
message was not seen before the DestroyWindow call returned, as
the WM_DESTROY message could not be handled later without the
window in the handle table. I'm not sure this can happen, but we
might as well remove it.
