When the reply to a TARGETS request comes in, the clipboard may already
be reclaimed by the local app. Deal with that case (in an ugly way,
strictly speaking we should use a cancellable here).
This happens for example at startup when the initial TARGETS requests
have not been answered until after the main widow popped up. And if such
a window immediately claims the primary clipboard (like when the initial
focus is inside an entry), this race will happen.
This object tracks the SelectionNotifyEvent that has to be sent in
response to a SelectionRequest.
Currently it just looks like code reshuffling, but it's a prerequisite
for handling MULTIPLE, which requires to only send the notify after
every stream has writtten at least once.
But anyway, code is cleaner now, so it's a win!
(1) Try all passed in formats in order if one of them fails.
(2) Don't blindly accept all formats, make sure they are mime types
(3) Add a bunch of special non-mime types that plug converters to
get to mime types
This allows us not just to pass any mime type to the read function, but
it also makes it possible to pass multiple mime types and the clipboard
can then try them in order until it finds a supported one.
This is so far not implemented though.
Turns out, way too many async operations are implemented by running the
sync operation in a thread. The easiest solution is to support that is
to use a GAsyncQueue for the buffers and deadlock if called from the
main thread.
(1) Turn X11 clipboard event handling into a regular filter function
(2) Maintain a timestamp in the clipboard, so we can pass it when
querying selections.
Make sure the API reflects the idea that GdkContentFormats is a set
containing mime types. In particular, treat the object itself as a
plural - it's named content format`S' after all - and therefor use
the correct verb form.
Also make GdkContentFormats keep an array instead of a list, now that
it's immutable.
Instead, turn the functions into backend API:
gdk_broadway_display_add_selection_targets()
gdk_broadway_display_clear_selection_targets()
Remove the old per-backend functions, too.
Instead of creating a GdkX11Cursor, create GdkCursors. Cache the XCursor
in a hash table instead.
Also, make use of the new fallback mechanism for fallback code: Make
sure to provide cursors for the names that are guaranteed to exist, but
do not do bad attempts at displaying texture surfaces.
Black/White/transparent is not a replacement for those.
Stop wrapping the xsettings manager window in a foreign
window. This means that we cannot use the gdk window filter
APIs anymore, so just do the filtering in a non-generic
way.
The preferred api to create cursors is by name, and the
GdkCursorType enumeration can directly trace its ancestry
to the horrible X cursor font. So lets stop using it.
gdk_display_get_default_screen is gone, but we still
have x11-specific screen apis that GTK+ is using, so
we need an alterative way to get the screen object.
GTK+ now uses the gtk-xft-dpi setting directly.
Note: this commit only fixes the backends that
currently provide this setting. The win32 and
Quartz backends still need to be fixed.
Drop the screen argument from gdk_dnd_find_window_for_screen
and rename the function to gdk_dnd_find_window. The screen
argument does not add anything here since the drag context
is already tied to the display. Update all backends, and
update all callers.
We are not emitting these events anymore, so lets remove them
from the api. The GdkSettingAction enum is moved to xsettings-client.c
where its only use remains.
Epoxy 1.4 has new ad hoc API that we can use to check whether GLX is
available on the current system.
If we didn't use this API, we'd have to manually dlopen libGL (or its
equivalent on different OSes) and check if it had GLX symbols; since
Epoxy already does all of this internally, we can simply ask it instead.
https://bugzilla.gnome.org/show_bug.cgi?id=775279
This patch makes that work using 1 of 2 options:
1. Add all missing enums to the switch statement
or
2. Cast the switch argument to a uint to avoid having to do that (mostly
for GdkEventType).
I even found a bug while doing that: clearing a GtkImage with a surface
did not notify thae surface property.
The reason for enabling this flag even though it is tedious at times is
that it is very useful when adding values to an enum, because it makes
GTK immediately warn about all the switch statements where this enum is
relevant.
And I expect changes to enums to be frequent during the GTK4 development
cycle.
-Wint-conversion is important because it checks casts from ints to
pointers.
-Wdiscarded-qualifiers is important to catch cases where we don't
strings when we should.
The behavior where a touchpoint takes over the pointer position is
really backend dependent. Since this went away from the generic code,
implement it here.
Instead of relying on special values of edge constraints, this
patch adds an internal-only gdk_window_supports_edge_constraints()
function that by default returns FALSE, and is implemented by
GdkWindowWayland and GdkWindowX11.
This way, we can properly detect server-side support for this
feature and adapt accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=783669
Following the previous patch, where edge constraints support
was added to the Wayland backend, this patch introduces the
necessary code to handle the _GTK_EDGE_CONSTRAINTS atom from
X11 backend.
https://bugzilla.gnome.org/show_bug.cgi?id=783669
Under X, we were not setting the right drag cursor initially,
because at current_action == action == 0, initially. Fix this
by explicitly using the right cursor when grabbing.
This property contains 5 integers, of which the last 2 respectively
contain the tool serial number and tool ID. We were only extracting the
first so far, but GdkDeviceTool also has API getters for the latter,
which remained 0.
https://bugzilla.gnome.org/show_bug.cgi?id=786400
Interpret NULL as "root window" here - we only have one
screen nowadays, so there is no choice involved, and this
will let us avoid dealing with the root window in the
fontend code.
Don't set the have_focused field of the window's toplevel to TRUE by
default and don't set the FOCUSED state in gdk_window_map. This a means
toplevel window's state is what the WM expects, and the FOCUSED state
will be set anyway when we map the window and receive a _NET_WM_STATE
message.
Wacom tablets often have a "pad" device which houses multiple buttons. At
present, these devices are incorrectly marked as GDK_SOURCE_PEN which can
cause problems for some software.
https://bugzilla.gnome.org/show_bug.cgi?id=782040
The common compiler and linker flags control, among other things, the
default visibility of symbols; without them, we leak symbols that ought
to be private.
We're mixing a lot of styles in the Meson build files. This is an
attempt at making everything slightly more consistent in terms of
whitespace and indentation.
This is how it's done in the autotools build. Also avoids problems
with multiple source files having the same name (gdkeventsource.c).
Also move broadway backend code into broadway subdir.
Otherwise we wait for the next gdk_drag_motion() call, which will
happen on the next motion event, making the drag window briefly visible
on the 0,0 root coordinates.
https://bugzilla.gnome.org/show_bug.cgi?id=778203
The Mesa Vulkan drivers need XInitThreads() being called, because their
implementation has to use threads.
And I don't want to make the call depend on if Vulkan is compiled in
because that makes GTK's X11 behavior depend on compile-time flags, so
it's always called.
We're not currently using this, and dropping it allows us to loose
a bunch of code which leads us towards the goal of having GdkWindow
only for toplevels (and reparenting makes not sense for toplevels).
We can't really support these on e.g. wayland anyway, and we're trying
to get rid of subwindow at totally in the long term, so lets drop this.
It allows us to drop a lot of complexity.
Instead, complain if somebody calls gdk_x11_window_get_xid() on a
non-native window.
We cannot make random windows native anymore because there's no GSK
renderer associated with them, so we cannot draw them.
