The condition we check for to catch X servers going away
may not be accurate anymore, and the warning shows up in
logs, causing customers to be concerned. So, be quiet by
default, unless the user explicitly asked for a message.
At times (most often when closing subsurfaces that are scheduling
relayouts) the PHASE_PAINT handling gets broken with the following
sequence:
1. Surface receives wl_callback.done for the previous frame.
Surface is thawed.
2. A new update on the surface is scheduled. PHASE_PAINT is
requested directly on the frame clock. priv->pending_phase is
left unset in the surface.
3. Surface gets frozen
4. Frame clock processes the update scheduled at 2. The surface
is frozen, so paint is prevented. PHASE_PAINT is considered
handled.
5. Compositor emits wl_callback.done again. Surface is thawed.
6. At this point the machinery is off
- The surface didn't paint but has pending update regions
- priv->draw_needed is set in the toplevel and other portions
of the widget tree
- So queueing redraws is ineffective at eventually calling
gdk_surface_schedule_update() again on the toplevel surface.
- We don't paint anymore, so this broken state is not flushed
until other subsurface changes manage to schedule the missing
update.
To fix this, always set PHASE_PAINT in priv->pending_phase when
doing gdk_surface_schedule_update(). If the frame clock turns
around before the surface is thawed, it will still be waiting to
be processed the next iteration.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/3750
When we don't get stettings from the portal, the current
fallback is 'awful fonts'. There is no need for that. Instead,
set the fallback values to grayscale antialiasing with slight
hinting.
... until all globals have been received.
The dependency tracking introduced in 4e9be39518 only allows to
specify required globals and processes the closures as soon as
the requirements have been met. There are, however, also optional
dependencies - most notably the primary_selection protocol.
Currently we rely on the fact that compositors like Mutter announce
it before `wl_seat`, even though the order is not specified in
the spec.
Process globals closures only after all globals have been announced,
so optional dependencies can be accommodated.
Closes https://gitlab.gnome.org/GNOME/gtk/-/issues/3791
After iterating all the providers, all of them returning unsupported
error, gdk_content_provider_union_get_value() returns FALSE without
filing the given GError. Then gdk_clipboard_read_value_internal()
assumes there's a GError when FALSE is returned and
g_task_return_error() fails. We can just chain up to parent
implementation to ensure the GError is filled with unsupported error.
The DnD code for X11 adds the composite overlay window (aka COW) to the
cache.
Yet the X11 requests to get and release the COW may trigger XErrors that
we ought to ignore otherwise the client will abort.
Fixes: #3715
This lets the NGL backend be selected instead of the Cairo backend on
devices which expose both GL and GLES, but have better support of GLES.
Tested on a PinePhone.
Apparently, by comparing with the other backends, we should not call
_gdk_win32_append_event() after calling gdk_scroll_event_new() but we should
call it after calling gdk_scroll_event_new_discrete(), which was why we didn't
restore the cursor after we scroll using the mouse wheel and didn't manage to
remove the shade that appears after we scrolled to the very top or very bottom.
Also, as suggested by the reporter, use IDC_SIZEALL for the system cursor that
we fall back to if no cursor theme is installed, as with other Windows
programs.
This should really fix issue #3581.
If cairo is a subproject, it's not necessarily installed when gtk
is built. In the source tree, cairo's headers are not stored in
a directory called 'cairo'.
GTK traditionally lets you activate keyboard shortcuts
even if they are for a non-active layout. But it is meant
to only activate with a keysym from a non-active layout
when that symbol is not present in the current layout.
That last condition was lost when key event handling
was redone for GTK4. Bring it back.
This makes sure that we don't have cursors disappearing on Windows upon
scrolling because we can't find a cursor that exists on the system during
a scroll, and unlike GTK-3.x, we do not default to the arrow pointer on GTK4.
Just mimic what we have on X11 and Wayland: the trusty standard arrow pointer.
Fixes issue #3581.
We were calling _gdk_surface_update_size() every frame, even if the
window size didn't change. This would cause us to discard all cached
buffers and redraw the whole screen.
This was BAD.
We ought to get the coordinates of where the window menu should be
displayed using gdk_win32_surface_get_root_coords(), instead of rounding
the position that we obtained with gdk_event_get_position().
Also rename items a bit in the same function, and call
gdk_event_get_event_type() for consistency with the other backends.
Fixes issue #3704.
We were leaking buffers. This wasn't caught by valgrind and friends
because it was shared memory (with the compositor), but top(1) would
instantly see memory consumption of the app and the shell go through the
roof.
We were calling _gdk_surface_update_size() every frame, even if the
window size didn't change. This would cause us to discard all cached
buffers and redraw the whole screen.
This was BAD.
guint32 is used as part of the protocol in broadway backend.
Memory size declared with it was mistakenly replaced with size_t type
which does not guarantee being 32bit on all platforms, leading to a crash.
These events don't make sense on physical devices (for starters, they
are relative to the logical pointer position). Use this device for
those events, also happens to be what the upper parts expect of them.
Commit 97b5fad131 was a forward port from a gtk3 patch, but the hunk
was applied on the wrong bits of code.
Ensure the initialization paths also do mark settings read from the
portal as valid, so the checks for optional/newer settings actually have
the expected result. It is also desirable to mark settings as valid
after configuration changes (as that patch did effectively do), but not
enough to fix all situations.
If our opaque region is the entire surface, then we can make the OpenGL
context opaque like we do for decorated windows. This improves performance
as the compositor does not need to blend the surface with the contents
behind the window.
Use the infrastructure already available to look up keys, instead.
This does the right thing and looks up the setting across all
sources.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/3680
The debug spew for printing out supported buffer
formats was missing a bunch, among them the fp16
formats that are interesting for HDR support.
Add them.
Note that we still only support ARGB8888. But
at least we can print out what don't support.
We do not need to translate this on the CPU when we can instead push it
to the GPU in the same format and allow it to swizzle.
This fixes a huge number of memory allocations found while uploading the
GTK animation in widget-factory.
Just compiling these out means you have to write code slightly differently
so that you don't end up with "if ();" afterwards.
This adds a "do {} while (0)" so that we're still semantically a statement
but will also compile out.
My reading of the code is that gdk_drop_new() is not
consuming the content formats it is given, so the caller
must not pass a new reference.
Needs testing on Windows.
Whenever we communicate targets, we need to the union, otherwise
we don't tell the other side about our serialization. This makes
drops of images from gtk4-icon-browser to gimp and libreoffice
succeed in transferring data.
Fixes: #3654
When creating the output stream for a drop, we must
pass the mimetypes we support, otherwise the picking
of the right handler does not work.
Fixes: #3652
This attempts to fix the counter-intuitive resizing of surfaces in GTK4 where
the surface grows or shrinks at the right and/or bottom edge when the window
resized from the top and/or left edge(s).
This is not yet perfect as the window stutters upon resizing from the top
and/or left edges, but at least makes resizing more intuitive.
Remove the 'resized' member from the GdkWin32Surface structure, as we already
have a structure with a member that keeps track of whether a surface is being
resized, so we can just use that and avoid some confusion in the process
Sometimes the size will exceed the minimum bounds. For example crazy
applications like the widget factory that contains the world, or when a
user interactively resizes a window to be larger than the monitor the
window is on is.
The former is questionable, but the latter is not, and from here we
can't really see the difference, so just stop complaining.
Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/3035
This adds a "release" destructor for the gtk_surface1 interface which
signals to the server that a surface has been destroyed on the client
side, which the current "destroy" does not do.
Ideally the protocol would have specified a destroy request marked as
destructor to handle this automatically, however this is no longer
possible due to the destroy method being implicitly generated in the
absence of an explicit request in the protocol. Adding a destroy request
marked as destructor now would generate a new destroy method that
unconditionally would send the request to the server, which would break
clients running on servers not supporting that request.
In GTK4, we are now defaulting to the OpenGL renderer with the Cairo renderer
only used as a fallback, so there is no point keeping the code paths that use
layered windows as layered windows do not work well with OpenGL nor Vulkan.
Commit e6209de962 added some checks on TranslationEntry.valid in
order to figure out whether using the new font settings or the
old g-s-d ones. However that's only set in the non-sandboxed case.
This makes sandboxed applications fallback to the old (and also
non-existing with modern g-s-d) settings, possibly resulting in
ugly defaults being picked.
Fix this by also marking TranslationEntry elements as valid when
using the settings portal, precisely those entries that we are able
to read and match with our own table.
Have an implementation of ->request_layout() and ->compute_size() for the Win32
surface backend so that we can properly display and move and resize the
windows, as we request from the Win32 APIs.
Hxndling Aerosnap properly is mostly done except for snap_up(), which needs to
to be looked at later.
In line with what is done with the Wayland backend, enable the mapped state
independently as needed from the toplevel surface presentation, and also enable
the mapped state if necessary when presenting the popup surface.
The fact that we are using gdk-pixbuf for loading files currrently does not mean we will use it going forward.
Also, "anything gdk-pixbuf can load" does not mean anything, because what gdk-pixbuf can load is a compile-time option.
As new_from_resource() will assert() if it cannot load a resource, we must be very sure that people do not use anything but PNG and JPEG for resources and the docs were not clear on that.
When destroying a wl_surface (e.g. when a window or menu is closed), the
surface may continue to exist in the compositor slightly longer than on
the client side. In that case, the surface can still receive input
events, which need to be ignored gracefully.
In particular, this prevents segfaulting on wl_surface_get_user_data()
in that situation.
Reported in
https://gitlab.gnome.org/GNOME/gtk/-/issues/3296
The same issue for pointers/keyboards was reported in
https://bugzilla.gnome.org/show_bug.cgi?id=693338
and fixed with in
bfd7137ffb3625f17857a8fc099a72
In pointer_surface_update_scale(), only rescale the cursor surface when
the scale has actually changed and the cursor is on at least one output.
fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/3350
Right now, this issue is not completely understood, so it might also
involve some questionable handling of cursor surface by sway/wlroots.
However, irrespective of that issue, this patch avoids unnecessary calls to the
compositor, and there should be no drawback: Whenever the pointer enters
a new output, pointer_surface_update_scale() will be called again, such
that correct scaling of the cursor is still ensured.
There is a slight difference: When the cursor leaves the last output,
previously the image was reset to scale factor 1. Now, it keeps whatever
was last. That might be more sensible than the previous behaviour,
assuming that it's likely that when the cursor enter an output again, it
has the same scaling. Alternatively, if one cares about resource usage
at this level, it might make more sense to destroy the surface than
rescaling to 1.
To support Sierra, we need to have access to pasteboard types as a
NSString. Constants are provided in later versions of macOS, but we
can emulate that with an array which is initialized on first access.
On older systems, the availability of some methods seem to be incorrect
based on Apple documentation. This works around the issue by using
the rect conversion on older systems.
On x11 toplevel layout is not created before toplevel
is presented, but GTK tries to update it on idle
which leads to a crash due to accessing property
of undefined object. Treat soon to be created layout
as a layout with default values upon creation (resizable).
These functions were not implemented when the sizing changes
landed before GTK 4 was released. This fixes an issue with non-
resizeable windows not reacting to layout changes.
Fixes#3532
According to OpenGL spec, a shader object will only be flagged
for deletion unless it has been detached; when a program object
is deleted, those shader objects attached to it will be detached
but not deleted unless they have already been flagged for deletion.
So we shall detach a shader object before it is deleted, and delete
it before the program object is deleted best.
Some GTK based applications such as Qemu UI create and manage
EGLSurfaces associated with the relevant GdkSurfaces. In order to create
an EGLSurface, there needs to be a way to pass the native window
object to eglCreateWindowSurface(). While running in an X environment,
the native window object can be obtained by calling
gdk_x11_surface_get_xid(). Likewise, the native window object can be
obtained by calling gdk_wayland_surface_get_wl_egl_window() while
running in a Wayland environment. Therefore, this API needs to be
exposed to apps.
Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
If set to TRUE, does not call the free func for the removed items.
This can be used to move items between arrays without having to do the
refcounting dance.
../gdk/gdktoplevellayout.c:217: Warning: Gdk: gdk_toplevel_layout_get_maximized:
unknown parameter 'maximized' in documentation comment, should be 'maximize'
100% symbol docs coverage.
833 symbols documented.
0 symbols incomplete.
0 not documented.
What's left are just type system macros and windowing system opaque
structures.
Depending on the input driver, we will get XI_Motion based scroll
events for regular mouse wheels. These are intended to be handled
as discrete scroll, so detect smooth scroll events that move by
exactly 1.0 in either direction.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/3459
When being fullscreen, and wanting to unfullscreen but not caring about
whether to go unmaximized or maximized (as this information is lost), if
the GdkToplevelLayout represents the full intended state, we won't be
able to do the right thing.
To avoid this issue, make the GdkToplevelLayout API intend based, where
if one e.g. doesn't call gdk_toplevel_set_maximized() with anything, the
backend will not attempt to change the maximized state.
This means we can also remove the old 'initially_maximized' and
'initially_fullscreen' fields from the private GtkWindow struct, as we
only deal with intents now.
This is a more reliable calling point than ::resume-events, and a
good one to schedule things so they happen on a frame clock in no
special phase (Thus still fixing the original issue at 80d4a08e30)
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/3461
Those requests are received while dealing with the ::layout frame
clock phase, this has the unintended side effect of making the
frame clock "rewind" to handle ::flush-events again during this
frame, which delays everything and practically halves the frame
rate.
We do intend to make the motion events dispatches on the next frame,
so do this in an idle at a slightly lower priority than layout/draw,
so the ::flush-events phase is actually requested for the next frame.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/3264
We don't need to go through the NSOpenGLContext for these.
We can just use the C API directly. It's also clearer what is using
CGLEnable() vs CGLSetParameter().
It was used by all surfaces to track 'is-mapped', but still part of the
GdkToplevelState, and is now replaced with a separate boolean in the
GdkSurface structure.
It also caused issues when a widget was unmapped, and due to that
unmapped a popover which hid its corresponding surface. When this
surface was hidden, it emitted a state change event, which would then go
back into GTK and queue a resize on popover widget, which would travel
back down to the widget that was originally unmapped, causing confusino
when doing future allocations.
To summarize, one should not hide widgets during allocation, and to
avoid this, make this new is-mapped boolean asynchronous when hiding a
surface, meaning the notification event for the changed mapped state
will be emitted in an idle callback. This avoids the above described
reentry issue.
We only called xdg_toplevel.(un)set_maximize() if the toplevel layout
changed, but this misses the case when the compositor had changed the
maximized state. Change it to call the xdg_toplevel request if either
the local layout changed, or if the layout differs from the current
state.
This fixes an issue where one couldn't unmaximize a window by double
clicking the titlebar that, had previously been maximized e.g. using a
keyboard binding.
Do the same for fullscreen.
This will sometimes mean a frame is skipped if a resize was requested
during the update phase of the frame dispatch. Not doing so can cause
trying to allocate a window smaller than the minimum size of the widget.
If compute_size() returns TRUE, the layout will not be propagated to
GTK. This will be used by the X11 backend to queue asynchronous resizes
that shouldn't yet allocate in GTK.
