Only set input, opaque and window geometry regions once per commit.
They are double buffered anyway, so the last one would only take effect
either way; this way reading protocol logs are much more pleasent.
https://bugzilla.gnome.org/show_bug.cgi?id=769937
The wayland tablet protocol allows notifying the compositor with
descriptions of the actions performed by each tablet element. This
API call allows to hook up in to this wayland-specific feature.
https://bugzilla.gnome.org/show_bug.cgi?id=770026
These devices are kind of an strange case. Their "master" device is
the keyboard, because they share toplevel focus with it, regardless
of stylus focus. Nonetheless, they are only expected to send the
GdkEventPad* set of events.
https://bugzilla.gnome.org/show_bug.cgi?id=770026
This is a subclass of GdkWaylandDevice that implements GdkDevicePad,
all pad features are looked up from the info obtained through the
tablet v2 interface.
https://bugzilla.gnome.org/show_bug.cgi?id=770026
This is an interface meant to be implemented by the "pad" devices.
This device-specific interface exposes the mapping of all pad features,
it allows retrieving:
- The number of buttons/rings/strips
- The number of groups
- The number of modes a group has
- Whether a given button/ring/strip belongs to a given group
https://bugzilla.gnome.org/show_bug.cgi?id=770026
We want the same treatment for those, the event will be emitted on the
toplevel, which will then decide what to do with the event.
It just doesn't make much sense to propagate those up/down the hierarchy,
when we want specifically one action being triggered from those.
https://bugzilla.gnome.org/show_bug.cgi?id=770026
GDK_PAD_BUTTON*,RING and STRIP will be emitted respectively when
pad buttons, rings or strips are interacted with. Each of those
pad components belong to a group (a pad can contain several of
those), which may be in a given mode. All this information is
contained in the event.
GDK_PAD_GROUP_MODE is emitted when a group in the pad switches
mode, which will generally result in a different set of actions
being triggered from the same buttons/rings/strips in the group.
https://bugzilla.gnome.org/show_bug.cgi?id=770026
An xdg-popup requires a serial that the compositor will compare against
its own serial and will dismiss the popup if it doesn't match.
gtk+ uses either a pointer or touch serial for its helper function
_gdk_wayland_seat_get_last_implicit_grab_serial() but if the menu is
triggered before the user has had any pointer or touch interaction with
the client, using a keyboard shortcut, there is neither pointer nor
touch serial available, and gtk+ will use 0 as the default.
As a result, the compositor will instantly dismiss the xdg-popup. In
this case, gtk+ should use the keyboard serial instead.
Track keyboard serial as well and use the keyboard serial as the value
if there is no newer pointer or touch serial available.
https://bugzilla.gnome.org/show_bug.cgi?id=768017
At the time of move_to_rect() is called, not all state may have been set
up on the impl gdk window, causing the position to sometimes be
slightly offset due to drap shadow margins. For now, work around this
by postponing the processing of the move_to_rect() parameters until
showing, when its more likely that all state (such as shadow margin)
has been set correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=769402
The Wayland backend manages a set of fake root coordinate spaces, where
each non-relative positioned toplevel (i.e. not popups, popovers,
tooltips etc) make up the basis of separate fake root coordinate spaces.
This means that the Wayland backend doesn't have the abilitiy get a
proper root coordinate when querying on a non-toplevel GdkWindow. To
avoid this issue, first find the toplevel, while translating the anchor
rect coordinates so that they are in the toplevel window coordinate
space. Then use this toplevel to translate the coordinates to root
window coordinate space.
https://bugzilla.gnome.org/show_bug.cgi?id=769402
The position of each transient-of will be in fake-root coordinate
space; thus we should not accumulate all the positions making it an
offset; each window is already in fake root coordinate space.
https://bugzilla.gnome.org/show_bug.cgi?id=769402
When using the set transient-for as a popup parent, fetch the effective
toplevel instead, otherwise we will position against the wrong
coordinate.
https://bugzilla.gnome.org/show_bug.cgi?id=769402
The order in which tooltips are created, drawn, shown and then positioned,
always requires repositioning the surface. The tooltip window type only has
limited capability to do so. An alternative could be to use bufferstreams.
https://bugzilla.gnome.org/show_bug.cgi?id=768138
When a dialog is created, the mir event source is already executed on the
call stack. So without the recurse flag it will not be run in the main loop
used for the dialog.
https://bugzilla.gnome.org/show_bug.cgi?id=768138
The event will be sent when the surface becomes visible on an output. With this change the GdkMirWindowImpl keeps track of the scale value and sends a configure event on change.
Signed-off-by: Andreas Pokorny <andreas.pokorny@canonical.com>
The event code could potentially dereference pointer_info if the
invariant that ENTER_NOTIFY and LEAVE_NOTIFY events are only emitted on
devices which have pointers is violated elsewhere.
Found with scan-build.
https://bugzilla.gnome.org/show_bug.cgi?id=712760
Pick the W32 API for possible deadkey+<something> combinations
and prefer these to other sources of deadkey combos.
Specifically, if W32 API supports at least one combo for a particular
deadkey, only use that data and do not attempt to do other, unsupported
combinations, even if they make sense otherwise.
This is needed to, for example, correctly support US-International
keyboard layout, which produces a combined character for <' + a>
combo, but not for <' + s>, for example.
This is achieved by stashing all the deadkeys that we find in
an array, then doing extra loop through all virtual key codes and
trying to combine them with each of these deadkeys. Any combinations
that produce a single character are cached for later use.
In GTK Simple IM context, call a new GDK W32 function to do a lookup
on that cached combination table early on, among the "special cases"
(which are now partially obsolete).
A limitation of this code is that combinations with more than
one deadkey are not supported, except for combinations that consist
entirely of 2 known deadkeys. The upshot is that lookups should
be relatively fast, as deadkey array stays small and the combination
tree stays shallow.
Note that the use of ToUnicodeEx() seems suboptimal, as it should
be possible to just load a keyboard library (KBD*.DLL) manually
and obtain and use its key table directly. However, that is much more
complicated and would result in a significant rewrite of gdkkeys-win32.
The code from this commit, though hacky, is a direct addition to
existing code and should cover vast majority of the use-cases.
https://bugzilla.gnome.org/show_bug.cgi?id=569581
This changes the group/level semantic.
Previously W32 backend used "group 0/1" to denote "AltGr OFF/ON"
and "level 0/1" to denote "Shift is OFF/ON".
Now "group" means "keyboard layout" and there can be up to 255 groups,
while AltGr and Shift are combined into a single level enum that
takes values between 0 and 4.
Unlike X, W32 doesn't do effective group overriding, meaning that
it will never tell the caller that a different group was actually
used (even for universal keys, such as Enter), because key symbol
table is completely fabricated and there's no point in trying to
save a few of kilobytes of RAM by not duplicating universal key
records for all groups.
Also contains many whitespace changes (tab elimination, fixed
indentation) and cleanup (axed a few global variables, these are
now accessed via the default keymap).
https://bugzilla.gnome.org/show_bug.cgi?id=768722
This matches the behaviour of Mutter, Metacity and traditional X11
window managers on the window manager side, and is what we want
for at least gnome-terminal. I can't think of any reason why we'd
want incremental resize in any other tiled window.
Signed-off-by: Simon McVittie <smcv@debian.org>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=760944https://bugzilla.gnome.org/show_bug.cgi?id=755947
Only update to using v2 headers/structs. The incompatible changes
to tool events are dealt with in the next commit. Pads aren't handled
in this commit either.
The sizes passed are in device pixels and do not take into account the
scaling factor of the window itself. We cannot change the semantics of
the function, so let's at least add a warning for this trap door.
On X11, device_query_state() uses XIQueryPointer() which will return a
child window only if the pointer is within an actual child of the given
window.
Wayland backend would return the pointer->focus window independently of
the given window, but that breaks the logic in get_device_state() and
later in gdk_window_get_device_position_double() because the window is
searched based on coordinates from another window without sibling
relationship, breaking gtkmenu sub-menus further down the line.
Fix the Wayland backend to mimic X11's XIQueryPointer() to return a
child only if really a child of the given window.
That's the most sensible thing to do to fix the issue, but the API here
seems to be modeled after the X11 implementation and the description of
gdk_window_get_device_position_double() is not entirely accurate.
https://bugzilla.gnome.org/show_bug.cgi?id=768016
This has most notably impact in selection buffers, because those were
shared across all selection atoms. This turned out wrong on 2 situations:
- Because the selection atom was set at SelectionBuffer creation time, the
GDK_SELECTION_NOTIFY events generated will have unexpected info if the
buffer is attempted to be reused for another selection.
- Anytime different selections imply different stored content for the same
target.
This is better separated into per-selection buffers, so it's not possible
to get collisions if a same target is used across different selections.
https://bugzilla.gnome.org/show_bug.cgi?id=768177
The sanitize_utf8() function has been copied from X11 so both
backends behave the same. This allows interaction with older clients
(mainly through Xwayland, and the STRING selection target) that
request non-utf8 text.
https://bugzilla.gnome.org/show_bug.cgi?id=768082
Debian stable currently ships with a 3.16 kernel, so
it doesn't have memfd available.
This commit adds shm_open fall back code for that case
(for now).
https://bugzilla.gnome.org/show_bug.cgi?id=766341
We currently use syscall() directly to invoke memfd_create,
since the function isn't available in libc headers yet.
The code, though, mishandles how errors are passed from syscall().
It assumes syscall returns the error code directly (but negative),
when in fact, syscall() uses errno.
Also, the code fails to retry on EINTR.
This commit moves the handling of memfd create to a helper function,
and changes the code to use errno and handle EINTR.
https://bugzilla.gnome.org/show_bug.cgi?id=766341
When disposing a GdkDrawingContext we should unset the association
between the instance and the Cairo context; this avoids stale pointers
in case a reference that has acquired on the Cairo context survives the
lifetime of the GdkDrawingContext.
Instead of associating the GdkWindow that created the GdkDrawingContext
we can directly bind the Cairo context to the GDK drawing context.
Cairo contexts created via gdk_cairo_create() go back to not having a
GdkWindow associated to them, like they did before we introduced the
gdk_window_begin_draw_frame() API.
https://bugzilla.gnome.org/show_bug.cgi?id=766675
Instead of giving out Cairo contexts, GdkWindow should provide a
"drawing context", which can then create Cairo contexts on demand; this
allows us to future proof the API for when we're going to use a
different rendering pipeline, like OpenGL.
https://bugzilla.gnome.org/show_bug.cgi?id=766675
Existing code drawing on a GDK window has to handle the direct drawing
and the buffered drawing by itself, by checking the window type and
whether or not the window is backed by a native windowing surface. After
that, the calling code has to create a Cairo context from the window and
keep an association between the context and the window itself.
This is completely unnecessary: GDK can determine whether or not it
should use a backing store to draw on a GdkWindow as well as create a
Cairo context, and keep track of it.
This allows to simplify the calling code, and enforce some of the
drawing behavior we want to guarantee to users.
https://bugzilla.gnome.org/show_bug.cgi?id=766675
A wl_buffer has a max size of 4096 bytes, of which 8 are needed for the
header and another 4 for the string argument length (in this case), so
make sure the we only save the first 4083 bytes that are still valid
UTF8.
https://bugzilla.gnome.org/show_bug.cgi?id=767241
xdg-shell allows desktop environments to extend the list of states
within a given range.
Use this possibility to add a new state for tiled so that gtk+ can
benefit from this.
https://bugzilla.gnome.org/show_bug.cgi?id=766860
The Wayland protocol does not share XI2's wealth of information
about individual devices, but it does provide discriminating
information about the source for scroll events. Pass this on to
the application by creating separate slave devices for these,
and setting them as source device on the scroll events.
These devices can be discriminated by their input-source property:
wheel - GDK_SOURCE_MOUSE
finger - GDK_SOURCE_TOUCHPAD
continuous - GDK_SOURCE_TRACKPOINT
https://bugzilla.gnome.org/show_bug.cgi?id=767093
fix up
Calling gdk_gl_context_realize() should always result in a valid result,
so we need to provide a default implementation, to avoid a call to a
NULL function pointer.
Given that Wayland has no global coordinate, the only way for gdk to
retrieve the monitor a window last entered is to retrieve it from the
GdkWaylandWindow itself.
Implement the backend specific get_monitor_at_window() to return the
monitor that was last entered by the window.
https://bugzilla.gnome.org/show_bug.cgi?id=766566
In Wayland, surfaces get an enter/leave notification each time they
enter or leave an output.
Add an API to GdkWaylandWindow to retrieve the output the window has
last entered.
https://bugzilla.gnome.org/show_bug.cgi?id=766566
Some backends (namely Wayland) do not support global coordinates so
using the window position to determine the monitor will always fail on
such backends.
In such cases, the backend itself might be better suited to identify
the monitor a given window resides on.
Add a vfunc get_monitor_at_window() to the display class so that we can
use the backend to retrieve the monitor, if the backend implements it.
https://bugzilla.gnome.org/show_bug.cgi?id=766566
The GdkDragContext should only listen to GDK_GRAB_BROKEN events sent to
its own pointer device. It turns out that the passive key grabs mistake
GDK into sending a GdkEventGrabBroken on the master keyboard, which the
DnD machinery mistakes as a signal to cancel the operation.
https://bugzilla.gnome.org/show_bug.cgi?id=766442
Only generate crossing events on wl_touch.down for the virtual master
device used for touch events, and only whenever this virtual device
actually moves across surfaces. This behavior resembles better what is
expected in X11, where the pointer is warped to the touch position
on XITouchBegin.
This avoids the double emission of leave events when the pointer
emulating touch is lifted, that crossing event will be instead
generated when/if the focus surface changes.
https://bugzilla.gnome.org/show_bug.cgi?id=766314
This is required for proper integration with any other library/application that
may perform wayland API calls and poll() the wayland fd from multiple threads.
Using wl_display_dispatch{_queue}() is thread-safe if not mixed with custom
poll() usage, which GSource/GMainContext does.
Essentially, the problem is that multiple threads polling and reading
the same fd is extremely racy. Use the wayland provided API for allowing
concurrent access to the wayland display fd.
See the wayland man pages for wl_display_prepare_read(),
wl_display_cancel_read() and wl_display_read_events() for more details.
https://bugzilla.gnome.org/show_bug.cgi?id=763852
WINBOOL is MinGW-specific, so change it to BOOL, which is universally
available.
Also, Visua Studio is more picky on where __stdcall (WINAPI) is placed, so
fix that to be in-sync with what is done in the other sources.
Use of g_signal_handlers_disconnect_by_func() needs to do more work than
necessary to find all the matching handlers. Instead, just hold on to the
signal identifier and remove it directly so we hit the fast path.
Not terribly ground breaking in terms of performance gains, but its done
enough to be worthwhile.
https://bugzilla.gnome.org/show_bug.cgi?id=766049
The active keyboard grab can be spared then. This way the passive
key grabs allow other key combinations (eg. alt-tab) that are not
mandatory to grab here.
The wayland specification for discrete step information for scroll and
other axes reads:
| The discrete value carries the directional information. e.g. a
| value of -2 is two steps towards the negative direction of this axis.
mutter sets a value of 1 for SCROLL_DOWN events and -1 for SCROLL_UP
events.
gdkdevice Wayland backend does the opposite, it translates a positive
discrete value as SCROLL_UP and a negative value as SCROLL_DOWN, which
ends up inverting the scrolling direction.
Fix the logic in gdkdevice Wayland to use a positive value as
SCROLL_DOWN and a negative value as SCROLL_UP so that it matches mutter
and weston logic.
https://bugzilla.gnome.org/show_bug.cgi?id=765907
If the monitor vfuncs are not implemented in a display class,
fall back to providing a single monitor object representing
the entire screen. This is not meant to be 'good enough', it
is just to provide some implementation until all backends
implement the monitor vfuncs. When that is the case, the
fallback should be removed.
NoSymbol is not a valid GDK symbol (it only has the concept of
VoidSymbol, for some reason, which is neither the same thing nor
produced by any sane keymap). Passing NoSymbol events through to GTK+
apps is unlikely to produce anything useful.
In particular, this meant VTE would scroll to the end of the buffer when
pressing Fn (required for Page Up/Down on Macs), as it was receiving a
keypress that wasn't a modifeir. This does not happen on X11, as the
KEY_FN keycode is above 255, so does not get sent to clients.
https://bugzilla.gnome.org/show_bug.cgi?id=764825
We don't care about the specific (possibly client-side) window that
requested the focus here, only the toplevel. Fixes mistakenly sent
focus events when the grab happens inside the current focus window.
https://bugzilla.gnome.org/show_bug.cgi?id=762756
Always associate a drag context with a GdkDisplay and use that when
getting a cursor for a given action.
If we don't do this, dragging on a window that doesn't use the default
display will make us use cursors from the wrong display.
https://bugzilla.gnome.org/show_bug.cgi?id=765565
Typically, there won't be any references on old frame timings except for
the most recent timing. So instead of discarding these and re-entering
gslice twice, just steal the old frame timing and reuse it.
https://bugzilla.gnome.org/show_bug.cgi?id=765592
Don't track all orphaned dialogs globally, as mixing them up with each
other would in most cases trigger errors when we try to pass bogus
values to Wayland requests.
https://bugzilla.gnome.org/show_bug.cgi?id=765474
The naming of pointers to GdkWaylandDisplay's were inconsistent.
Running the following commands in gtk+/gdk/wayland illustrate the
inconsistency:
$ grep -r '\<display_wayland\>' *.[ch] | wc -l
195
$ grep -r '\<wayland_display\>' *.[ch] | wc -l
81
This patch renames all occurrences of "wayland_display" to
"display_wayland". This is also consistent with naming in the X11
backend. A couple of whitespace changes were done as well in places
where the rename was already done, that added line breaks to long lines
that stood out.
https://bugzilla.gnome.org/show_bug.cgi?id=765474
When synthesizing keyboard repeat, we can potentially drift further from
the mark depending on the timing of the frame callback and how long it
took to deliver the event.
This patch attempts to reduce this by tracking from a stable epoch the
time of our next keyboard repeat.
https://bugzilla.gnome.org/show_bug.cgi?id=765567
This allows us to decide when the R and B color channels should be
flipped with a much better granularity.
For instance, when using GLX_EXT_texture_from_pixmap to create a GL
texture from a surface we don't need to swap the R and B channels, as
the internal representation of the texture data will already have the
appropriate colors.
We also don't need to flip color channels when blitting from a texture.
Cairo surfaces are in BGRA format, but we upload them as RGBA buffers on
GLES; this means that the R and B channels are flipped in the texture
data.
Instead of doing a costly channel flip before putting them on the GPU,
we can flip the values inside the GLSL shader we use specifically for
GLES.
We cannot use GL_BGRA and GL_UNSIGNED_INT_8_8_8_8_REV when reading back
from the frame buffer in the software fallback path, as they do not
exist on OpenGL ES.
This will make the slow path a bit slower, because of the implicit
format conversion.
When uploading a Cairo image surface to a GL texture we cannot use
GL_BGRA and GL_UNSIGNED_INT_8_8_8_8_REV on OpenGL ES, as they do not
exist in the core spec.
On some platforms we can ask the GL context machinery to create a GLES
context, instead of a GL one.
In order to ask for a GLES context at GdkGLContext realization time, we
use a bit field like we do for forward compatible, or debug contexts.
The 'use-es' bit also changes the way we select a default version,
because OpenGL and OpenGLES versions differ.
https://bugzilla.gnome.org/show_bug.cgi?id=743746
Windows save in hardware_keycode an information which is not so low
level and some application require the hardware scancode.
As Windows provides this information save it in GdkEventPrivate
and provide a function to get this information.
For no Windows system the function return the hardware_keycode instead.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=765259
This first adds a common autotools module that can be included by
the Makefile.am's to generate the file lists and the g-ir-scanner/
g-ir-compiler command lines to build the introspection files.
The autotools files for gdk/ and gtk/ are then updated to generate
the full file lists needed to build the introspection files, with
the full command lines for g-ir-scanner and g-ir-compiler as NMake
Makefile modules that can be used to build the introspection files
for Visual Studio builds.
https://bugzilla.gnome.org/show_bug.cgi?id=765195
These were showing up higher in Sysprof profiles.
The simple fix is to avoid the emit_by_name() and let the interface emit
the signals directly. No function preconditions are provided since these
are internal API.
If we get gdk_wayland_seat_flush_frame_event() with no previous event to be
flushed, we fallback into the scroll event checks. However, there's no check
performed there as to whether it really scrolled, so it'd always send a smooth
scroll event with 0/0 deltas in this case.
This should be mostly harmless, but still, we should only end up emitting scroll
events if those really happened.
The frame event is also meant to compress wl_pointer.leave events, at this
point the focus surface will be definitely NULL. In the end, wl_pointer.frame
should flush the last composed event despite the pointer focus.
https://bugzilla.gnome.org/show_bug.cgi?id=765065
We must emit the cancel event with the same semantics, and towards the GdkWindow
that is currently under the touchpoint, so make proxy_button_event() deal with
GDK_TOUCH_CANCEL.
Fixes the GDK_TOUCH_CANCEL event being emitted only on the toplevel, which is
usually non-sufficient.
Since Wayland is using libxkbcommon, it inherits X unfortunate
real/virtual modifier distinction, so we have to do the same
gymnastics we do for X to map between the two.
This should fix matching of accelerators using virtual modifiers
(modulo gnome-shell bugs regarding the handling of Super).
https://bugzilla.gnome.org/show_bug.cgi?id=764424
MoveWindow should not be used over the pre-existing move/resize
functions, which already correctly position a window with respect
to its parent, while also taking into account the size of window
decorations.
https://bugzilla.gnome.org/show_bug.cgi?id=765100
gdk_window_reparent() already changes children list for old and new parent.
Doing so twice results in a circular reference in the list, which can hang
the application later, for example in gtk_window_show().
https://bugzilla.gnome.org/show_bug.cgi?id=764845
This makes usage of _gdk_display again when creating a window.
This is needed because there is a window created when the display
is being initialized, so it becomes a chicken and egg problem.
For now we roll back this to fix the wintab crash but we might
want to fix this again in the future by improving the wintab
initialization.
https://bugzilla.gnome.org/show_bug.cgi?id=764664
The zoom/rotate change for quartz does not build on 10.7. This change
adds zoom/rotate support in quartz only for 10.8 and following. The
problems is described here:
https://bugzilla.gnome.org/show_bug.cgi?id=760276 and here
https://trac.macports.org/ticket/51052
NSEventPhaseMayBegin was only introduced in 10.8 although documentation
says it is introduced in 10.7. Tests on 10.7 indicate that the phase
property for the Magnify event is not supported at all on 10.7
On wayland, such axes are per-tool, we must update device capabilities
on the fly as new tools enter proximity, first the slave device so
it matches the current tool, and then the master device so it looks
the same than the current slave device.
Only the management of tablets and tools is added so far. No tablet events
are yet interpreted.
As it's been the tradition in GTK+, erasers are split into their own device,
whereas the rest of the tools are meant to be routed through the
GDK_SOURCE_PEN device. Both pen/eraser devices are slaves to a master
pointer device, separate to wl_pointer's. This is so each tablet can
maintain its own cursor/positioning accounting.
Signed-off-by: Stephen Chandler Paul <thatslyude@gmail.com>
This will enable multiple "pointers" to have separate data here.
Will come out useful when adding support for tablets, as they
will have a separate cursor for all purposes.
Because there are multiple different types of styluses that can be used with
tablets, we have to have some sort of identifier for them attached to the
GdkDeviceTool, especially since knowing the actual tool type for a GdkDeviceTool
is necessary for matching up a GdkDeviceTool with it's appropriate
GdkInputSource in Wayland (eg. matching up a GdkDeviceTool eraser with the
GDK_SOURCE_ERASER GdkInputSource of a wayland tablet).
Signed-off-by: Stephen Chandler Paul <thatslyude@gmail.com>
On the devices and backends that support it, this signal will be emitted
on slave/floating devices whenever the tool they are interacting with
changes. These notifications may also work as a sort of proximity events,
as the tool will be unset when the pen moves too far.
For backends, gdk_device_update_tool() has been included, all that should
be done on their side is just calling this whenever any tool might have
changed.
GdkDeviceTool is an opaque object that can be used to identify a given
tool (eg. pens on tablets) during the app/device lifetime. Tools are only
set on non-master devices, and are owned by these.
The accounting functions are made private, the only public call on
GdkDeviceTool so far is gdk_device_tool_get_serial(), useful to identify
the tool across runs.
This fixes a bug that was introduced by db1b24233e.
The reason why 0:0 coordinates were passed was that SWP_NOREPOSITION was
misinterpreted as SWP_NOMOVE. That is not the case - SWP_NOREPOSITION
prevents owner Z-order change, not the window position change.
gnome-control-center is calling gtk_window_resize() on configure-event
signals which leads to a busy loop.
Avoids such a busy loop by not re-configuring a window with the same
size, unless this is coming from and xdg-shell configure.
bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=764374
When we invalidate a window we need to also invalidate all child windows
that are native (non-native are automatically invalidated as we track
invalidation once per native window only). This was done in a pretty
inefficient way, recursing over the entire tree.
This makes the invalidation much faster by only looking at the native
children of the native window we're in, filtering out those that
are not a descendant of the client side window we're interested in.
Given that there are very few native subwindows this is much faster.
Currently only one kind of decorative window is in use - the shape
indicator that is shown when snapping windows to the edge of the screen.
When normal toplevel class is used, its window procedure expects certain
motions from GDK (passing user data to CreateWindowEx(), registering
handle in a hash map etc), and might crash if that is not done.
Dumb window doesn't require anything, it can just be.
https://bugzilla.gnome.org/show_bug.cgi?id=763013
Now halfleft/halfright/fullup snaps do hug screen edges as intended.
Documents AeroSnap behaviour when snapped windows are drag-resized
(currently this implementation handles this in a very simplistic way).
Don't believe GTK when it tells us that window shadow is 0, preserve
previous values (but do remember that GTK wants no shadow, in case
we need that).
Fixes a couple of bugs in unsnapping (check offset against the half
of the window; don't put pointer in the middle of the window vertically
if it still fits in the top half).
https://bugzilla.gnome.org/show_bug.cgi?id=763013
Implements gdk_win32_window_set_shadow_width().
Uses shadow width/height to adjust max tracking size, allowing
windows to be drag-resized to cover the whole desktop.
Also uses SM_C*VIRTUALSCREEN instead of SM_C*MAXTRACK.
https://bugzilla.gnome.org/show_bug.cgi?id=763013
Indicator is a bare layered click-through native window,
painted completely by GDK, including animation.
This commit also isolates some of the more spam-ish debug logging
under ifdef.
This commit also changes the system metric used for maximal window
height for the snapping purposes. Turns out, SM_CYMAXTRACK is way
too large, use SM_CYVIRTUALSCREEN instead.
https://bugzilla.gnome.org/show_bug.cgi?id=763013
This implements the part of AeroSnap that snaps windows when you
drag them (while moving or resizing) to the edge of the screen.
It also fixes drag behaviour for snapped and maximized windows
(if such windows are dragged, first they must be unmaximized/unsnapped).
Note that this code does not take into account the shadow width, and
because of that the under-pointer-position-preserving window moves
might not look as such for maximized windows, which lack the shadow
when maximized, but do have the shadow when unmaximized.
This commit also doesn't cover some corner-cases the same way AeroSnap does.
Also, the snapping indicator (which is supposed to be a window shape that
shows where the window will be if the drag op is stopped at its current
point) is not being drawn, all routines responsible for its creation,
moving and drawing are stubs.
https://bugzilla.gnome.org/show_bug.cgi?id=763013
This is what AeroSnap does. If a window is being unsnapped on
a new monitor, check if the work area is large enough for the
window to fit in its normal size. If the window fits, just
reposition it so that the ratio of
left-window-edge-to-screen-edge / right-window-edge-to-screen-edge
remains the same, without scaling the window.
https://bugzilla.gnome.org/show_bug.cgi?id=763013
It works exactly like AeroSnap.
Except for shift+win+left/right, which is left for AeroSnap
to handle (AeroSnap takes action before we get the message,
so there's no way for us to override it).
The only thing that doesn't work is shift+win+left/right on
a maximized window, for reasons unknown at the moment.
This only implements winkey+stuff behaviour of AeroSnap,
not the drag-to-the-edge-and-something-funny-happens one.
https://bugzilla.gnome.org/show_bug.cgi?id=763013
If a layered window was hidden and is made visible, erase its
contents before showing it. GDK will schedule a redraw, but until
then we generally don't want to show old contents.
https://bugzilla.gnome.org/show_bug.cgi?id=763783
This is achieved by sending undocumented message WM_SYSMENU
to the window.
Before doing that, the window is given WS_SYSMENU style
(to enable window menu) and some combination of
WS_MAXIMIZEBOX (for "Mazimize" item)
WS_MINIMIZEBOX (for "Minimize" item)
WS_SIZEBOX (for "Size" item)
depending on which operations are currently permissible.
WM_SYSMENU is processed by DefWindowProc(), which results
in showing the window menu. We remove extra styles
at the first opportunity (WM_INITMENU message), as they
alter the way our window is rendered.
https://bugzilla.gnome.org/show_bug.cgi?id=763851
These functions are supposed to return the numbers of consecutive
1 bits in each components mask as precision. However, due to a
copy-paste mistake when this code was moved around in
commit 70d689cddd, the precision
was always reported as zero. This affects only a few applications
that directly set window background on X11 windows, such as emacs.
https://bugzilla.gnome.org/show_bug.cgi?id=764210
Delay as long as possible before calling OpenClipboard(),
call CloseClipboard() as quickly as possible after that.
Don't call OpenClipboard() when we don't need to (for example,
we don't need to open clipboard to call GetClipboardOwner()).
Also, print out actual W32 error code in some cases where it
was not printed before.
https://bugzilla.gnome.org/show_bug.cgi?id=763907
Error codes can be easily looked up in an error code list
and/or googled up. Error messages, while descriptive, often
describe the wrong thing, and the messages themselves are not
part of the documentation of a function, unlike error codes.
It would be preferable to have the code, or both.
https://bugzilla.gnome.org/show_bug.cgi?id=763913
gtk+ currently depends on the scaling factor and the cairo device scale
of both the backend surfaces and image surfaces to be equal.
Until now we didn't apply a cairo device scale at all and depended on the
automatic scaling of CGContexts. This works when drawing with cairo but
fails in case of image surfaces, which get requested at a too small size.
To make the quartz backend behave more like the X11 one, set the cairo device
scale on the surface in gdk_quartz_ref_cairo_surface(). As this conflicts
with the default scaling done by CGContext (we would get double scaling)
undo the CGContext scaling using CGContextScaleCTM().
This patch is based on the following patches by Brion Vibber:
https://bugzilla.gnome.org/show_bug.cgi?id=740199#c4https://bugs.freedesktop.org/show_bug.cgi?id=69796#c4https://bugzilla.gnome.org/show_bug.cgi?id=763779
If the configure-event gives us the same size as we had before,
which is common for animation resizes, then try to keep the
existing buffer around. This saves us a memfd_create() syscall
on every frame.
https://bugzilla.gnome.org/show_bug.cgi?id=763350
Now that GdkWaylandDeviceData is gone, the functions prefixed
"gdk_wayland_device_" and taking a GdkWaylandSeat as first
parameter feel out of place. Renaming those makes it more obvious
that it's seat functions.
https://bugzilla.gnome.org/show_bug.cgi?id=763859
It's the same than gdk_device_get_seat() nowadays. Also, rename the
usages of GdkWaylandDeviceData to GdkWaylandSeat in the functions
affected by the removal.
https://bugzilla.gnome.org/show_bug.cgi?id=763859
We were just relying on the drag context finalize() to destroy
the window. But with garbage-collected bindings, that might
not happen as soon as we like, so explicitly hide the window
when the drag ends successfully.
https://bugzilla.gnome.org/show_bug.cgi?id=763659
Using UpdateLayeredWindow() on iconic windows brings them *back* from
their iconic (minimized) state. That is bad.
As a precaution, also don't use SetWindowPos() on iconic windows.
This means that iconic windows can't be moved. That is fixable
by using SetWindowPlacement(), but there is no pressing need to do so,
as there are very few cases when windows need to be moved while minimized.
https://bugzilla.gnome.org/show_bug.cgi?id=763835
Two errors here:
1) A typo in splashscreen rectangle calculation - sets right twice
instead of setting top
2) Centering for dialogs is off because it doesn't convert
GDK virtual desktop coordinates to Windows WM virtual desktop
coordinates by adding _gdk_offset_*
https://bugzilla.gnome.org/show_bug.cgi?id=763628
The way gdk_drag_status() may be called multiple times during the
processing of drag and drop events throughout the widget hierarchy
brings some superfluous messaging going in, esp. when it's the last
request the one we want to honor, yet we emit messaging requests on
all.
This is barely appreciable in the X11 backend, but due to the design
of the wayland protocol, quick series of changes like this it have
some self-amplificating consequences which may end up flooding the
connection.
We can delegate this to a late "commit" call, performed within GDK
event management. This way gdk_drag_status() calls may be cached
and only result in windowing messaging once per ::drag-motion or
::drag-data-received event. Emitting the final status will also
avoid spurious action changes on the compositor and the other peer.
https://bugzilla.gnome.org/show_bug.cgi?id=763298
This code:
> gdk_window_get_root_origin (window, &x, &y);
> x -= root_x;
> y -= root_y;
> pointer_window = gdk_device_get_window_at_position (device, &x, &y);
was meant to find the child gdk window at coordinates root_x and root_y.
These 4 lines had 2 bugs:
1) x = x - root_x (same for y) is wrong, it should be x = root_x - x
2) gdk_device_get_window_at_position() does not give you the window
at position x and y. It gives you the window under the device
(mouse pointer) and the returns the device coordinates in x and y.
https://bugzilla.gnome.org/show_bug.cgi?id=763533
MacOS provides the NSEventTypeMagnify which is very similar to the
Gtk ZOOM gesture and NSEventTypeRotate which is very similar to the
Gtk Rotate gesture. Those two event sequences are translated to a
sequence of GDK_TOUCHPAD_PINCH events. This sequence is then detected
in the upper gtk layers as Gtk Zoom/Rotate Gestures.
https://bugzilla.gnome.org/show_bug.cgi?id=760276
When compressing window state events, we didn't free the discarded
event after removing it from the queue, causing us to leak it. This
commit makes sure to free the discarded event after unqueuing it.
https://bugzilla.gnome.org/show_bug.cgi?id=762468
A gtk_surface.present request was added to gtk_surface which takes
timestamp from some input event, and uses that timestamp to figure out
whether the window can be presented or not. If we don't have a
timestamp, we should just give up instead of making up our own,
otherwise we might steal someones focus.
https://bugzilla.gnome.org/show_bug.cgi?id=763037
The gtk_shell protocol used some half baked unstable protocol semantics
that worked by only allowing binding the exact version of the
interface. This hack is a bit too confusing and it makes it impossible
to do any compatible changes without breaking things.
So, instead rename it to include a number in the interface names. This
way we can add requests and events without causing compatibility issues,
and we can later remove requests and events by bumping the number in
the interface names.
https://bugzilla.gnome.org/show_bug.cgi?id=763001
This request actually means nothing to the upper GDK layers,
we used to preempt a GDK_SELECTION_REQUEST event, but this is too
eager, and not like things work in X11.
Originally in wayland, this event may be used for feedback purposes.
We however don't perform any mimetype-based feedback, so we can
safely ignored.
This makes data_source_send() the only place where we actually
trigger GDK_SELECTION_REQUEST, this one is conceptually the same
than the X11 selection request event.
The virtual host assigns the name of the mouse device to
"VirtualBox USB Tablet" in VirtualBox and we'd use that device as mouse.
If not, GtkTooltip is not enabled.
https://bugzilla.gnome.org/show_bug.cgi?id=763017
Other portions of the GDK-Win32 backend make use of this function as
layered windows need to be disabled for GL windows and possibly other
parts, so make this function a private function that is available within
the backend.
https://bugzilla.gnome.org/show_bug.cgi?id=763285
Layered windows and GL do not work well together, so disable layered
windows when initiating a GdkGLContext, so that GtkGLArea programs can run
properly.
Also based on patch by LRN to address the issue.
https://bugzilla.gnome.org/show_bug.cgi?id=763080
The default value for the double-click key in the
org.gnome.settings-daemon.peripherals.mouse schema is 400.
Use the same value as the declared default for the
gtk-double-click-time GTK+ setting, to avoid pointless
differences in corner cases.
https://bugzilla.gnome.org/show_bug.cgi?id=720950
This removes the event_poll_fd global variable and the (ab)use of
get_default_display. It is also more consistent with other backends.
Also store display
Use gdk_window_get_effective_toplevel when looking for
a suitable transient parent, to skip over offscreen windows
that we might encounter in the window tree. This fixes
a crash in glade.
https://bugzilla.gnome.org/show_bug.cgi?id=763110
Fixes bug 763023: in certain circumstances, XRRGetOutputInfo will return
a null pointer. This commit adds a check to detect and handle this
return value.
Otherwise WM-dependent default cursor is used, which does not
match our theme. Worse, later GDK will realize that we have
our own left_ptr cursor and will apply it after all, making
the discrepancy even more noticeable.
https://bugzilla.gnome.org/show_bug.cgi?id=762902
* Explicitly grab the device, setting appropriate cursor on it.
* Fix gdk_device_virtual_set_window_cursor() to just set the
cursor, without trying to check that mouse is over the given
window. Also prevent it from immediately resetting cursor.
* Alse take into account things that happen in other parts of
GDK - don't look for replacement cursor, GDK already did that,
and don't create a default arrow cursor instead of NULL,
GDK-W32 already did that up the stack as well.
Warn about inappropriate cursor == NULL argument instead.
https://bugzilla.gnome.org/show_bug.cgi?id=762711
Toplevels are now true layered windows that are moved,
resized and repainted via UpdateLayeredWindow() API call.
This achieves transparency without any extra effort,
and prevents window size and window contents desychronization
(bug 761629).
This also changes the way CSD windows are detected. We now
use window decorations to detect CSDiness of a window,
and to decide whether a window should be layered (CSD windows should
be) or not.
Decorations are now stored in the window implementation,
not as a quark-based property of the window-as-gobject.
https://bugzilla.gnome.org/show_bug.cgi?id=748872
Normally works only on CSD windows, non-CSD windows continue
to use WM modal loop for drag-resizing and drag-moving. However,
if it is activated on non-CSD windows, it does work.
Has the advantage of being completely immune to AeroSnap.
AeroSnap only worked partially on CSD windows, with the only part
that worked being "don't let users drag window titlebar outside of
the desktop". Now AeroSnap doesn't work on windows moved by
this code at all, which is good, since they currently don't work
well with it due to the way shadows are drawn.
It's possible to also re-implement AeroSnap (or something similar),
but that is a story for another commit.
This code was originally intended to fix the problem of window
size and window contents desynchronization, but failed to achieve
that result in the end. Nevertheless, it serves as a foundation for
other changes to the way window resizing works.
https://bugzilla.gnome.org/show_bug.cgi?id=761629
key repeat is handled client side, which means stalls in the compositor
dispatching key release events can lead to fictious repeat events.
This commit ties key repeat to a server roundtrip to ensure the client
and server are in sync.
https://bugzilla.gnome.org/show_bug.cgi?id=757942
We don't need the key repeat rate or anything like that when
handling key up events, so do key up events first before querying
for that information.
https://bugzilla.gnome.org/show_bug.cgi?id=757942
deliver_key_event is sometimes called from a timeout handler and
sometimes called directly. We currently erroneously return TRUE
(G_SOURCE_CONTINUE) in the case where it's called directly, but to
no ill effect, since we ignore that return value. In the future,
we're going to need to call it directly in other parts of the code
where the return value would be relevant and handling TRUE, would
require adding redundant code.
Instead, this commit just changes the code to always reset the timer
manually, and never rely on glib's ability to automatically reset
the timer by returning TRUE. This makes the code smaller, too, since
there's less special casing required.
https://bugzilla.gnome.org/show_bug.cgi?id=757942
If the parent of a transient is not a native Wayland window (e.g.
offscreen window), the transient loop check will crash.
Check for the actual type in the transient loop check and do not assume
the parent is necessarily Wayland native.
bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=761156
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
If there are already a window state event for a given window queued
when the window state is changed, drop that event and queue a new event
with a changed_mask based on the state before last event that was queue
without compression.
https://bugzilla.gnome.org/show_bug.cgi?id=762468
According to xdg_shell, an xdg_surface.configure with size 0x0 should
be interpreted as that it is up to the client to set a size.
When transitioning from maximize or fullscreen state, this means the
client should configure its size back to what it was before being
maximize or fullscreen.
This problem currently only occurs on weston because weston sends a
configure with size 0x0 when transitioning back from maximize or
fullscreen.
bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=762713
gdk_display_list_devices is deprecated and all the backends
implement the same fallback by delegating to the device manager
and caching the list (caching it is needed since the method does
not transfer ownership of the container).
The compat code can be shared among all backends and we can
initialize the list lazily only in the case someone calls the
deprecated method.
https://bugzilla.gnome.org/show_bug.cgi?id=762891
The staging buffer gets allocated any time begin_paint is called
on the window. This can happen even with an empty paint region,
so we should cope with that situation. At the moment we crash
trying to post a runtime warning.
https://bugzilla.gnome.org/show_bug.cgi?id=762755
The g_print documentation explicitly says not to do this, since
g_print is meant to be redirected by applications. Instead use
g_message for logging that can be triggered via GTK_DEBUG.
The g_print documentation explicitly says not to do this, since
g_print is meant to be redirected by applications. Instead use
g_message for logging that can be triggered via GTK_DEBUG.
The g_print documentation explicitly says not to do this, since
g_print is meant to be redirected by applications. Instead use
g_message for logging that can be triggered via GTK_DEBUG.
The g_print documentation explicitly says not to do this, since
g_print is meant to be redirected by applications. Instead use
g_message for logging that can be triggered via GTK_DEBUG.
gdk_display_add_seat was prepending new seats to the list, which
was effectively making the added seat the new default. Since that
is probably not intended, append to the list.
The gdkprivate-wayland.h header file is included from the top-level gdk
directory; this means that all included files referenced in the header
must be relative to the `gdk` directory, otherwise the build will fail
when the build directory is not equal to the source directory.
This commit fixes a build failure under continuous:
In file included from ../../gdk/gdkdisplaymanager.c:60:0:
../../gdk/wayland/gdkprivate-wayland.h:40:51: fatal error:
gtk-primary-selection-client-protocol.h: No such file or directory
#include "gtk-primary-selection-client-protocol.h"
^
compilation terminated.
Makefile:1155: recipe for target 'libgdk_3_la-gdkdisplaymanager.lo' failed
make[4]: *** [libgdk_3_la-gdkdisplaymanager.lo] Error 1
Except for the init function, all the visual related code is made
of gdkscreen vfuncs, so let's move it to gdkscreen-win32. This way
we avoid keeping other static variables and instead store the info
inside the screen struct.
I am testing GTK+ master against mutter 3.19.90, so I'd
like GTK+ to survive even when the compositor does not
support the primary selection interface.
Implement it using the internal copy of the protocol. Otherwise,
we just deal with it the same than clipboard selection, just mapping
it to the PRIMARY atom instead of the CLIPBOARD one.
https://bugzilla.gnome.org/show_bug.cgi?id=762561
This protocol is an internal mirror of the primary selection drafts
being proposed for wayland-protocols. No changes besides prefix/suffix
changes.
https://bugzilla.gnome.org/show_bug.cgi?id=762561
1f74f12d9 rendered entry of keypad decimal mark unuseable for
several national keyboard layouts, this commit amends that, at
least for W32, and makes GTK+ behave more or less the same way
W32 behaves.
The patch works like this:
- When typing the first character at the keyboard or when switching
keyboard layouts, the decimal mark character will be cached in the
static variable "decimal_mark" within gdkkeys-win32.c
- in case of WIN32, gdk_keyval_to_unicode() asks gdkkeys-win32.c for the
current decimal_mark when converting GDK_KEY_KP_Decimal.
https://bugzilla.gnome.org/show_bug.cgi?id=756751
1) MSDN says that the coordinates of the maximized window
must be specified as if the window was on the primary display,
even if nearest display where it ends up is not the primary display.
So instead of using nearest display work area verbatim,
use it only to account for taskbar size, while using
primary display top-left corner (0:0) as the reference point.
2) MSDN says that max tracking size is a system property, we
should just call GetSystemMetrics() and use that.
https://bugzilla.gnome.org/show_bug.cgi?id=762629
Sigh.
Now that we've neutered the QEMU USB tablet, I'm finding that
spice is doing just the same nonsense. It has a fake "spice vdagent
tablet". Blacklist that as well.
Remember the last source device we're generating multiple clicks for,
just so we can bail out if the device changed. That will just reset
the counting.
https://bugzilla.gnome.org/show_bug.cgi?id=723659
The significant change here is a memory leak fix in init_xrandr15.
The rest of the changes makes init_xrandr13 and init_xrandr15 more
parallel, and simplifies init_multihead.
Add a gtk_shell.set_startup_id request, so the application can communicate
to the compositor the startup id that it received through the
DESKTOP_STARTUP_ID envvar, or other means.
When running with a Wayland compositor which doesn't support the
xdg_shell interface, gtk+ will segfault while trying to access the
corresponding wl proxy.
Check for xdg_shell support and do not use Wayland if not present, so
that it can fallback to X11, hoping that Xwayland is usable.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=762258
There is no point in attaching and then committing the same buffer if
there was no damage. This will also make us do less unnecessary backfill
read backs, for the cases where we paint with an empty paint region.
https://bugzilla.gnome.org/show_bug.cgi?id=762120
If a after-paint was scheduled but nothing was painted, for example when
the it was scheduled by a subsurface wanting to update its position,
we'd still try to read back from the backfill cairo surface and update
the committed cairo surface reference even though no buffer was
attached.
Fix this by adding a new state, 'pending_buffer_attached', which is only
true if a buffer was attached during frame. Only when this is true will
the backfill be read back and the committed cairo surface reference be
updated.
https://bugzilla.gnome.org/show_bug.cgi?id=762120
That way we can let ::cancel callers to override the visual
result of the operation (eg. when detaching notebook tabs on
NO_TARGET).
Also, document gdk_drag_drop_done() so it is mentioned that
this is a one-shot call.
https://bugzilla.gnome.org/show_bug.cgi?id=761954
We should conform to a minimal set of reasons for the gtk side to emit
a better GtkDragResult than GTK_DRAG_RESULT_ERROR. This fixes the notebook
tab DnD feature, where we rely on GTK_DRAG_RESULT_NO_TARGET.
In the wayland side, unfortunately we can't honor either NO_TARGET nor
USER_CANCELLED, we don't know of the latter, so we could return false
positives on the former.
https://bugzilla.gnome.org/show_bug.cgi?id=761954
The first time a window is shown we should always call SW_SHOWNORMAL.
Understand whether to call SW_SHOW or SW_SHOWNORMAL and the specific
ones for the temporary windows depending on IsWindowVisible.
This also fixes the problem when calling gtk_window_present and
the window is snapped to the left or right of the screen.
This patch is based on the patches provided by Yevgen Muntyan
and Aleksander Morgado.
https://bugzilla.gnome.org/show_bug.cgi?id=698652
If the window is iconified we want to restore the window
to get the proper size instead of showing it normal which
would change the size of the window.
https://bugzilla.gnome.org/show_bug.cgi?id=698652
Right now we use one buffer for both staged changes (freshly painted
changes waiting for the frame clock to send to the compositor) and
committed changes (changes actively being read by the compositor
process). This creates a problem in the event we need to stage updates
at the same time the compositor is processing committed updates: we
can't change what the compositor is actively processing.
The current solution for handling this contention is to allocate a
temporary buffer on the spot at the time the updates are staged, and to
copy that buffer back to the shared buffer later. The problem, though,
is that the copy to the shared buffer currently happens as soon as
the updates are finished being staged, not when the shared buffer is
done being processed by the compositor.
In order to address that problem, this commit changes the code to always
stage changes to a dedicated staging buffer. The staging buffer is
used exclusively by the client until the client is done with it, and then
once that staging buffer is committed, the client never writes to that
buffer again. If the client needs to stage new updates, it allocates a
brand new staging buffer, draws to it, and back fills the undrawn parts
of the buffer from a copy of the contents of the committed buffer.
As an optimization, the compositor has the option of releasing the
committed buffer back to the client. If it does so before the client
needs to stage new updates, then the client will reuse the buffer
for staging future updates. This optimization prevents having to allocate
a new staging buffer and the associated cost of back filling
that new buffer with a readback of the committed buffer.
https://bugzilla.gnome.org/show_bug.cgi?id=761312
Right now we handle buffer releases coming from the
compositor in a central place. We add a listener when
first creating the shared buffers.
This is problematic because a buffer can only have
one listener on it at once so users of the buffer
can't get notified when it's released.
This commit moves the buffer listener code from the
centrally managed display code to the cursor and window
code.
https://bugzilla.gnome.org/show_bug.cgi?id=761312
The client and compositor share access to the window
pixel buffers. After the client hands off (commits)
the buffer to the compositor it's not supposed to write
to it again until it's released by the compositor.
The code tries to deal with this contention by allocating
a temporary buffer and using that in the mean time. This
temporary buffer is allocated by a higher layer of the code
when begin_paint returns TRUE. Unfortunately, that layer of
the code has no idea when the buffer is released, so it ends
up blitting the temporary buffer back to the shared buffer
prematurely.
This commit changes begin_paint to always return FALSE.
A future commit will address the contention problem in
a different way.
https://bugzilla.gnome.org/show_bug.cgi?id=761312
There are a few places where we destroy a cairo surface and
then nullify it. This commit changes those to use
g_clear_pointer instead.
It also drops a cairo_surface_finish call that is unnecessary
https://bugzilla.gnome.org/show_bug.cgi?id=761312
The name surface is really overloaded when dealing
with wayland windows.
To alleviate ambiguity, this commit changes the name
of the "surface" and "subsurface" members to have
a wl_ prefix.
https://bugzilla.gnome.org/show_bug.cgi?id=761312
The fallback behaviour of get_work_area () divides the
screen width and height by the window scaling factor, but
those values are already scaled down.
https://bugzilla.gnome.org/show_bug.cgi?id=761474
Set _GTK_THEME_VARIANT to empty string when default theme variant
is used. This will allow to understand whether _GTK_THEME_VARIANT
is not supported or default variant is requested.
https://bugzilla.gnome.org/show_bug.cgi?id=761476
Temp windows without parent are used frequently in our testsuite;
using g_warning on them causes the tests to fail, which is not
useful. Reduce the warning to a g_message.
Presently, Gtk will only send a startup notification completion message
for the first window that is shown. This is not good for the case of
GtkApplication, where we are expected to participate in
startup-notification for all windows.
We have avoided this problem by manually emitting the startup complete
message from after_emit in GtkApplication.
Unfortunately, this causes problems for windows that are shown with a
delay. It is also a dirty hack.
The reason for the original behaviour is simple: there is a static
boolean in gtkwindow.c which controls it. We remove this.
Instead, clear the startup notification ID stored in GDK when sending
the completion message. GtkApplication will re-set this the next time
an event comes in which needs startup-notification handling. In the
non-GtkApplication case, newly shown windows will still not send the
message, since the cookie will have been cleared.
Finally, we remove the hack from GtkApplication's after_emit.
This will probably cause some regressions in terms of lingering startup
notification messages. The correct solution here is to always use
gtk_window_present(), including when merely opening a new document (with
a new tab, for example).
https://bugzilla.gnome.org/show_bug.cgi?id=690791
This was a thinko - what we sometimes do for signal names is to
use I_() to intern them (to avoid a strdup), but I_() is not
currently available in gdk, so lets just skip this
microoptimization for now.
It looks like the gnome-continuous headers haven't quite
caught up yet, so try __NR_memfd_create instead.
If that doesn't work, i'll likely just add in a fallback
code path.
The tmpdir is used for a wide assortment of things, and
can easily fill up. If it fills then desktop will start
crashing with SIGBUS errors.
This commit changes the shm pool allocation code, to use
memfd_create, instead, so the shared memory files will
be anonymous and not associated with /tmp
https://bugzilla.gnome.org/show_bug.cgi?id=761095
create_shm_pool doesn't need the width or height, it just needs
the total size. By passing it in, we're requiring it to redo
stride calculation unnecessarily.
This commit drops the width and height parameters and makes the
function just take the total size directly.
https://bugzilla.gnome.org/show_bug.cgi?id=760897
Right now, we assume the stride for the image surface needs to
be 4 byte aligned. This is, in fact, true, but it's better to
ask cairo for the alignment requirement directly rather than
assume we know the alignment rules.
This commit changes the code to use cairo_format_stride_for_width
to calculate a suitable rowstride for pixman.
https://bugzilla.gnome.org/show_bug.cgi?id=760897
create_shm_pool unlinks the temporary file a little,
too late. It should be unlinked before ftruncate()
is called for two reasons:
1) if ftruncate fails, the file is currently not
getting cleaned up at all
2) in theory, if the file is public some other process
could muck with it
This commit just moves the unlink call a little higher
up.
https://bugzilla.gnome.org/show_bug.cgi?id=760897
This function does not ignore empty rectangles. Since this
is a fairly subtle point about the behavior, it is worth
spelling this out in the documentation. We've had a bug
open about this for a long time:
https://bugzilla.gnome.org/show_bug.cgi?id=464528
These functions will be automatically called by the windowing backend.
The usual hooks to run this from in gtk/ shouldn't even happen, but
it is worth to document which calls are expected and which aren't.
If the grab window is destroyed the grab will be implicitly removed,
although we won't get GdkSeat:ungrab called in order to clear our
internal window<->seat relation entirely. Setting a weak ref will
nullify the pointer we keep on the seat to the window, avoiding the
expected crashes.
Due to implicit grabs, we basically can guarantee that the pointer
won't have any buttons pressed at the time of wl_pointer.enter.
Seems like a good place to unset any button modifiers that might
have been left stale by compositor grabs.
This includes managing input events and source-side DND events,
as well as setting the appropriate cursor and emitting the signals
that are expected in this mode of operation.
This function (most similar to gtk_drag_get_cursor() helps figure out
the right cursor that applies to a given action. To be used by the
various backends.
We've traditionally left GTK+ to handle the input side of things,
letting GDK only manage the windowing-specific messaging. This
way of splitting responsibilities is not compatible however with
some backends, we must fold then input management at the DnD stage
into GDK (and backends) domain.
The gdk_drag_context_manage_dnd() call is meant to be the entry
point for this mode of operation, if the drag and drop operation
becomes managed, the caller (i.e. gtkdnd.c) doesn't need to perform
grabs, nor manage input events itself.
As a consequence of this, different aspects now belong to the
backend GdkDragContext implementation:
- Because the caller doesn't see keyboard events anymore,
keyboard navigation must be managed in GDK, so is the decision
of the current action based on modifiers/button pressed.
- Because the caller won't see input events in general, the lifetime
of the drag and drop operation is now communicated through the
::drop-performed, ::dnd-finished and ::cancel events
- Because the caller doesn't participate anymore on the action
being chosen, the pointer cursor must be set by the backend.
The caller is rather notified of the final action through the
::action signal.
The caller is still responsible of dealing with the corresponding
GdkSelection, ensuring its ownership and communicating the supported
mimetypes.
And use it to handle kinetic scrolling in the GtkScrolledWindow.
However, dropping the delta check causes the X11-based kinetic
scroll to break since we don't have the stop event here. Correct handling of
xf86-input-libinput-based scroll events is still being discussed.
https://bugzilla.gnome.org/show_bug.cgi?id=756729
This adds support for the new wl_pointer events available in v5.
The wl_pointer.axis_source events can be ignored for the purposes here, the
main reason they exist is so that the combination of axis_source=finger and
axis_stop triggers kinetic scrolling. We don't need to care about the source,
axis_stop is enough for us to tell us when we're scrolling.
The wl_pointer.frame events group events together and is intended as a
mechanism to coalesce events together. This for example allows us to now
send a single GTK scroll event for a diagonal scroll. Previously, the two
wl_pointer.axis events had to be handled separately.
The wl_pointer.axis_discrete event sends mouse wheel clicks where
appropriate, and is translated into up/down/left/right scroll events.
https://bugzilla.gnome.org/show_bug.cgi?id=756729
This prevents WM from drawing shadows around tooltip windows,
which, in Adwaita, should have no shadow and are CSD-ish (which means
that tooltip window is larger than it looks, and WM draws the shadow
only on the outside, leaving a gap between the visible tooltip edge and
the shadow).
https://bugzilla.gnome.org/show_bug.cgi?id=759898
