Fixes e.g. crashs when dropping from finder.
Turn the "getting_events" boolean into a counter to handle poll_func()
being called recursively, and track the loop depth correctly by
changing its counter before bailing out in run_loop_observer_callback().
This way we reallocate our autorelease pool at the right time, and
don't kill memory that is still in use by outer run loops.
Also drain, not release the pool, just for some defensive forward
compatibility.
(cherry picked from commit ef9a92d225)
When an NSEvent does not have the window field set, we already assumed
the event was not for us and discarded it. But for NSMouseMoved events
we now make an exception, because such events generated after
using/clicking the main menu bar have the window field set to NULL while
the application window still has focus.
We used to experience a loss of motion events after using the menu bar,
this could be seen in buttons that stopped prelighting and first
clicks often being ignored unless you clicked somewhere else first.
These issues are fixed by this patch.
Since the wmspec_check_window doesn't have a corresponding GdkWindow we can't
rely on the get_event_window() return value to get the XID from. Just use the
XID from the XEvent directly.
https://bugzilla.gnome.org/show_bug.cgi?id=662953
The new file defines GDK_DISABLE_DEPRECATION_WARNINGS so it can happily
use deprecated APIs.
This commit moves those functions there that use deprecated functions
and currently cause warnings.
With this commit, GDK compiles without deprecation warnings.
After consulting with Carlos, we agreed that it should be enough to grab
the core pointer instead of doing a full grab. If it turns out that's
wrong, we need to adapt the internal API for resizes to take the device
doing the resize.
When compiled with older SDKs, the original change for this bug caused a
compiler warning about NSWindow not being able to handle a setStyleMask
message. This tricks the compiler into thinking that it can.
In 2.x, the !HAVE_XCONVERTCASE fallback of keyval_convert_case() was
implicitly used as implementation for all !X11 backends.
In 3.x, when this function was virtualized in GdkDisplayManager,
this fallback was moved to the X11 backend and the other backends
"equipped" with /* FIXME implement */ implementations of
keyval_convert_case() which don't convert anything.
Move the fallback code back to gdk/ as default implementation
of GdkDisplayManager::keyval_convert_case() and remove its
implementations is all backends but X11. Also remove the
implementation in Wayland which was a plain copy of what
is now the default implementation.
(cherry picked from commit f46c1b76d8)
gdk_x11_device_manager_core_list_devices returns a new allocated
list, which has to be freed.
valgrind output:
==18686== 160,176 (80,088 direct, 80,088 indirect) bytes in 3,337 blocks are definitely lost in loss record 25,347 of 25,378
==18686== at 0x4C256DD: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==18686== by 0x6CD7752: g_malloc (in /lib64/libglib-2.0.so.0.3000.0)
==18686== by 0x6CEE2B6: g_slice_alloc (in /lib64/libglib-2.0.so.0.3000.0)
==18686== by 0x6CCB37D: g_list_prepend (in /lib64/libglib-2.0.so.0.3000.0)
==18686== by 0x654CADA: gdk_x11_device_manager_core_list_devices (gdkdevicemanager-core-x11.c:836)
==18686== by 0x6531489: gdk_display_pointer_is_grabbed (gdkdisplay.c:1270)
==18686== by 0x5162E1E: filter_func (ui.c:140)
==18686== by 0x6558B50: gdk_event_apply_filters (gdkeventsource.c:83)
==18686== by 0x6558CB3: _gdk_x11_display_queue_events (gdkeventsource.c:197)
==18686== by 0x6530680: gdk_display_get_event (gdkdisplay.c:311)
==18686== by 0x65589F1: gdk_event_source_dispatch (gdkeventsource.c:356)
==18686== by 0x6CD0A0E: g_main_context_dispatch (in /lib64/libglib-2.0.so.0.3000.0)
https://bugzilla.gnome.org/show_bug.cgi?id=660676
Those if() blocks don't have any reason being there, as x and y are not
pointers. If the window is destroyed, just set the out values to zero
and return.
As seen in valgrind:
==3306== Conditional jump or move depends on uninitialised value(s)
==3306== at 0x624C74F: gdk_window_get_root_coords (gdkwindow.c:6933)
==3306== by 0x5E193C3: gtk_tooltip_show_tooltip (gtktooltip.c:1160)
==3306== by 0x5E19C05: tooltip_popup_timeout (gtktooltip.c:1282)
==3306== by 0x623B102: gdk_threads_dispatch (gdk.c:754)
==3306== by 0x8592F3A: g_timeout_dispatch (gmain.c:3907)
==3306== by 0x859174C: g_main_context_dispatch (gmain.c:2441)
==3306== by 0x8591F47: g_main_context_iterate (gmain.c:3089)
==3306== by 0x8592494: g_main_loop_run (gmain.c:3297)
==3306== by 0x5D2E501: gtk_main (gtkmain.c:1362)
==3306== by 0x5C5652F: gtk_application_run_mainloop
(gtkapplication.c:115)
==3306== by 0x7C47C9D: g_application_run (gapplication.c:1323)
==3306== by 0x447B5F: main (nautilus-main.c:102)
==3306== Uninitialised value was created by a stack allocation
==3306== at 0x624D48A: gdk_window_get_device_position
(gdkwindow.c:4952)
gdk_unicode_to_keyval(uc) returning (uc | 0x01000000) is not an
error return value but simply the way to encode 24-bit unicode
characters directly as keyvals.
Add enum GdkModifierIntent which identifies use cases for modifier masks
and GdkKeyMap::get_modifier_mask(). Add a default implementation which returns
what is currently hardcoded all over GTK+, and an implementation in the
quartz backend. Also add gtk_widget_get_modifier_mask() which simplifies
things by doing widget->display->keymap->get_modifier_mask().
Handle dead keys in special_ucs_table and have them converted by
UCKeyTranslate(), so all dead key combinations can be entered.
Later, this should be handled in the input method, just as it's
done for X11/Win32.
Fixes bug #658379 - Disabled devices still added to list on startup,
spotted by Bastien Nocera. Do not create GdkDevices for disabled
devices on device manager construction, leading to a confusing initial
state.
This commit introduces a new setting, gtk-visible-focus, backed
by the Gtk/VisibleFocus X setting. Its three values control how
focus rectangles are displayed.
'always' is equivalent to the traditional GTK+ behaviour of always
rendering focus rectangles.
'never' does what it says, and is intended for keyboardless
situations, e.g. tablets.
'automatic' hides focus rectangles initially, until the user
interacts with the keyboard, at which point focus rectangles
become visible.
https://bugzilla.gnome.org/show_bug.cgi?id=649567
Functions dealing with native Xlib types were (skip)ed because
gobject-introspection did not have correct Xlib types declarations.
They are corrected now, so these GdkX11 functions can be enabled back
again.
https://bugzilla.gnome.org/show_bug.cgi?id=655495
I tried to suppress compiler warnings on pre-10.6 machines this way,
but it defeats its purpose when you compile for pre-10.6 machines on
a 10.6 machine. For now, we have to live with the warnings when
compiling on/for pre-10.6 machines, there does not seem an easy and proper
way to suppress the warnings.
https://bugzilla.gnome.org/show_bug.cgi?id=653947
It could happen that a cookie event has been already allocated/freed
in an event filter, as it can't be allocated a second time, all GDK
can do is skipping the event. Spotted by Guillaume Desmottes.
This function can be used to find the GdkDevice wrapping
an XInput2 device ID. For core devices, the Virtual Core
Pointer/Keyboard IDs (2/3) may be used.
This function can be used to find out the XInput2 device ID
behind a GdkDevice, mostly useful when you need to interact
with say Clutter, or raw libXi calls.
Fixes Bug 645993 - XIM has wierd behaviors. Some XIM modules
filter every key event, possibly replacing it with their own
one. These events usually have serial=0, so make
GdkDeviceManagerXI2 also listen on these.
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 is already done in gdk_event_source_get_filter_window(), and
could lead to wrong event assignment if an event translator happens
to return a window for an event it doesn't handle.
This method can be implemented by event translators so they
return the right window from XGenericEventCookie events, as
ev->xany.window isn't meaningful for these.
GdkEventSource now also uses this to find out the right window
filters to apply.
XKB and GDK both add "internal" bits to GdkModifierType. In C,
this typically doesn't cause problems as bitfields are just integers,
and there's no validation. However for bindings, it's normal to
convert enumerations to "native" enumeration types, which don't
support unknown bits. See bug 597292.
https://bugzilla.gnome.org/show_bug.cgi?id=634994
It could be the case that gdk_window_set_cursor() is called on
pointers not yet known to the device tracking code in GdkDisplay,
so update the cursor on all master pointers.
The code actually updating the cursor for the given window has
been refactored out to gdk_window_set_cursor_internal(), used
in gdk_window_set_device_cursor() as well, which makes it handle
root/foreign windows too.
https://bugzilla.gnome.org/show_bug.cgi?id=649313
-Update to distribute the VS2010 files.
-Added rules in Makefile.am's of GDK and GTK to fill in the
project/filter files templates with up-to-date source file
listings to simplify maintenace.
Any comments on the usage of the VS2010 files are welcome!
The zlib compressed xmlhttprequest thing was a nice hack, but it doesn't
really work in production. Its not portable, doesn't have enought API
(missing notification for closed sockets) and having to synchronize
between two different connections in a reliable way is a pain.
So, we're going everything over the websocket. This is a pure switch,
but after this we want to modify the protocol to work better over
the uncompressed utf8 transport of websockets.
Some special key keycode values as seen in keydown actually match
normal keys (like "." has a keyCode 46 on keyPress, which is the same
as Delete, but 190 for KeyDown). So we must match the special keys on
keypress. However, some things must be checked on keydown as they are not
generating keypress events.
We can't really know the client side keymaps, so we use the keysym
as the hardware keycode (essentially claiming to have a keyboard with
one key for all possible keysyms). This is not ideal, but its hard to
do better with no knowledge of the client side keyboard mappings.
(And html keyboard events suck badly...)
We're using the noVNC keyboard even handling model (and some of the
code with permissions). This means we combine data from keydown and
keypress to figure out the translated keysyms according to the keyboard
layout at the users machine.
This symbol needs to be exported for GDK (Win32) so that the
runtime checks for Win32 backend usage can be done on
MSVC-compiled versions of GTK+ too.
I did not add the corresponding symbols for the other backend
though-they are probably exported automatically by GCC AFAIK.
This is done to make commit
9db4accf9c
work on MSVC
The XI2 device manager was mistakenly setting the window user_time on
both ButtonPress and ButtonRelease, which meant that processes that
tried to launch another process based on the time of a ButtonPress
event would end up always focus-stealing-preventing the new app.
https://bugzilla.gnome.org/show_bug.cgi?id=647275
As soon as something changes, even if it was a request from the user
we send a configure event. If not we might race with a app-side
generated configure event.
For instance, a create + resize might create only a configure event for
the create in the browser, but that may get to the app after the app-side
configure event for the resize, overriding the new size.
* Always calculate the context, don't store in surface.
* Store the toplevel element (frame or canvas) for easy access.
* Always use visibility hidden rathern than display none to hide windows,
as this means we can always rely on dom positioning info.
When syncing windows, make sure we set transient-for before showing
the window to avoid it being visible with the wrong transient-for
(i.e. possibly on the wrong browser window).
_gdk_device_get_axis_use() dates back to pre-sealing, when the
xi2 work began, this remaining can be gone with a public
gdk_device_get_axis_use() function already in place.
Event times come from the browser and may change weirdly when we reconnect
with another browser, so we normalize these to be strictly increasing
and with a 5 second gap for each reconnect.
This mode makes each toplevel window get its own browser window, with
popup windows using the browser window of their transient parent.
Its not idea, as you can't get rid of all browser chrome by default, and
it means popups (like menus) can't extend outside the toplevels. But, it is
kinda cool.
Since we're really only initializing grabs (except for implicit
grabs at least) from the client side we might as well do all the grab
time checks on the client side to avoid unnecassary roundtrips.
The metacity theme format allows to use colors from the current
GTK+ theme in window decorations. Since GTK+ now gained support
for dark theme variants, window managers using that theme format
(metacity, mutter, compiz via gtk-window-decorator) should be able
to use colors from the correct variant; so in case a variant is
requested, export it in the _GTK_THEME_VARIANT property on
toplevel windows.
https://bugzilla.gnome.org/show_bug.cgi?id=645354
XSendEvent doesn't currently work with XI2 events, so add code to
translate core events when they have the send_event flag.
(We still don't actually select for core pointer/keyboard events, so
we will only receive send_event events that are sent with a 0
event_mask.)
https://bugzilla.gnome.org/show_bug.cgi?id=644847
Ensure that we're writing all the updates for a single rendering op
in one go without callbacks inbetween. That way some rendering will
be delayed, but the user will never see partial renderings.
We do this because we need to be able to switch to using sync reads
when we're doing a roundtripping call, and that is too complex
with the async code.
This incorrect assignment would cause asynchronous aborts from the X server
(they would occur if for instance, an offscreen GtkTreeView calls
gtk_widget_error_bell()).
GDK_NATIVE_WINDOWS was a way to keep some old apps running that did weird
things in gtk2. We should not have to carry this forwards in gtk 3.x.
We do however keep a g_warning() call reminding people of this fact to
ease debugging when they try to port their applications.
https://bugzilla.gnome.org/show_bug.cgi?id=644119
This code is a relic from GTK2 days and should not be necessary anymore,
as code now makes sure to only copy those parts of the window that are
not overlapped by parent windows.
By deleting it we fix potential issues with composited and translucent
windows copying the wrong data.
https://bugzilla.gnome.org/show_bug.cgi?id=643416
The monitor change detection code in _gdk_x11_screen_size_changed() and
process_monitors_change() goes to some length to make sure its only emitted
when there is an actual change to the data visible via the GdkScreen monitors
api.
However, commit 662e69ad added some code that always emits "monitors-changed"
in _gdk_x11_screen_size_changed when we have randr13 and get a ConfigureNotify
on the root window (even though we may already have emitted it in the
RRScreenChangesNotify event!).
As far as I can tell this is due to a comment in the bug referenced by the
commit (https://bugzilla.gnome.org/show_bug.cgi?id=601712#c4) where it says:
This version of the patch changes GdkDisplay to emit "monitors-changed" when
the primary monitor changes (see the change in _gdk_x11_screen_size_changed).
And, if you remove this part of the change the signal is not emitted when just
the primary is changed. However, this is not really the right approach. We
should just also check for if the primary changes in process_monitors_change()
to avoid spurious signal emissions.
https://bugzilla.gnome.org/show_bug.cgi?id=643216
The last paragraph still seems to be out of place though, as if it
was a previous attempt at an overview or part of some older text
elsewhere.
This overuses the passive too.
If a level 1 key maps to a key value passed to
gdk_test_simulate_key(), raise the GDK_SHIFT_MASK flag so the reqested
key value is generated. Also add a regression test for this fix.
On Windows and OS X we want to prefer the native backends over the X11
backend.
On Linux, nothing changes as nobody is going to enable those backends
(and if they do, they'll know what they get).
Previously we weren't installing the device headers when compiling
without XINPUT support. But we would include them from gdkx.h, so
essentially the build was broken.
With this patch the types will exist but not do anything.
At the same time, change the library sonames for -3.0 to just -3.
This is necessary since the 2.99 releases installed libraries like
libgtk-3.0.so.0.9903.0, and we want to prevent the library version
number from jumping back. So 3.0 will have libgtk-3.so.0.0.0.
