The fix is twofold. First, when checking that a corner is resizable, we must
check the constraints on both edges. Second, when checking either edge we
must include both perpendicular sides in order to allow those to be
resizable when the constraint does not allow resizing the edge being
checked.
When looking for the cursor to apply, start from the innermost
widget and go up. This is the right behavior for cases like
entry icons. The top-down order we were using so far is the
right behavior for cases like global wait cursors. Since we
have entry icons in gtk, but not global wait cursors, lets
pick the other order for now.
application/x-rootwindow-drop is not useful anywhere else,
so put it under #ifdef GDK_WINDOWING_X11
On W32 this prevents toplevels from automatically becoming valid
drop targets with a useless drop type.
(This commit is cherry-picked from the gtk-3-22 branch)
https://bugzilla.gnome.org/show_bug.cgi?id=786509
Instead of allowing people to pass a uint user-data, insist on them
comparing mime types.
The user data was a uint instead of a pointer anyway, so uniqueness
could not be guaranteed and it caused more issues than it was worth.
And that's ignoring the fact that it basically wasn't used.
Change constructors to reflect that.
While doing so, also add a fallback argument to the cursor constructors,
so it is now possible to create cursors with fallback.
The check used to achieve discarding events not meant for the window
widget itself (because they are handled in the regular paths). Using
the target widget is the equivalent now.
Use g_value_set/get_boxed() in gtk_window_get/set_property(), case PROP_ICON.
icon_from_list() shall always add a reference to the returned icon.
gtk_window_set_icon() must accept icon != NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=789870
We disconnect from the GDK window, so the renderer can't keep any useful
state.
Plus, we might be using an entirely different window next time we
realize (after a call to gtk_window_set_display() for example) that should
use a completely different renderer anyway.
And have a priv->display instead of a priv->screen.
Includes turning gtk_menu_set_screen() into gtk_menu_set_display(),
because that function just forwards to its window.
If the compositor prefers server-side decorations and the client doesn't
customize the title bar, we disable client-side decorations and let the
compositor know. Otherwise, we continue to use client-side decorations.
Signed-off-by: Drew DeVault <sir@cmpwn.com>
https://bugzilla.gnome.org/show_bug.cgi?id=781909
As Timm Baedert pointed out, the previous fix made the
menubar go on top of popovers, which is just wrong. Instead,
make gtk_window_snapshot handle all direct children of the
window, taking care to stack popovers correctly.
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.
Clarify that ::destroy, not ::hide*, removes a window from its app, by
replacing the mention of open windows with the blurb on destruction from
:application, completing commit 7db4bee4b6
Also link to the equivalent gtk_application_(add|remove)_window() calls,
since Application.add_window() already links back to Window:application.
* unless you use gtkmm…
https://bugzilla.gnome.org/show_bug.cgi?id=639931
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
The last touch on this patch series is making GtkWindow able to
selectively adjust various UI details based on the different
tiled edges. The main driver here is that we don't want to show
shadows on edges that are constrained.
This patch adds the necessary code to do that, while still
maintaining compatibility with the old ways.
https://bugzilla.gnome.org/show_bug.cgi?id=783669
GTK windows don't have their tiling states really
hooked into the client-side decoration code, and
the only effect it has is disabling the resizing
edges.
With the introduction of per-edge tiling information,
we are backed by much more precise data on how the
window manager wants the app to behave.
This patch, then, fixes GtkWindow to take into account
per-edge tiling information. For compatibility purposes,
the previous tiled field was kept, and thing will just
continue working if no edge information is supplied.
https://bugzilla.gnome.org/show_bug.cgi?id=783669
Do not connect to get_settings_for_screen() if we have no screen…
Use g_signal_connect(), not connect_object(), to match how set_screen()
makes this same connection, and how finalize() already disconnects it.
https://bugzilla.gnome.org/show_bug.cgi?id=705640
Since setting a clip is mandatory for almost all widgets, we can as well
change the size-allocate signature to include a out_clip parameter, just
like GtkCssGadget did. And since we now always propagate baselines, we
might as well pass that one on to size-allocate.
This way we can also make sure to transform the clip returned from
size-allocate to parent-coordinates, i.e. the same coordinate space
priv->allocation is in.
That means the whole hierarchy is getting destroyed, leaving those
behind incurs not only in a leak, but also on weak refs (and unintended
repick) to happen in the wrong moment.
As we now refrain from sending the crossing events if there's an
implicit grab, those events must be sent on button release when
the implicit grab is broken.
Check the grab widget (both explicit and implicit) and check for a cursor
from the target widget up to this grab widget. If the target widget is
outside the grab widget, only the grab wigdet's cursor will be checked.
This also means that we have to ensure the cursor is updated on button
releases, as an implicit grab being deactivated must trigger a cursor
lookup from the target widget.
We don't draw or size-allocate the titlebar when the window is
fullscreen or undecorated, so reflect this by setting it to
!child_visible. This can happen when changing the value of the decorated
property while the window is shown.
We can just replace window comparisons with coordinate matching, the
cursor corresponding to edges is now set in a capture-phase motion
handler, as cursors aren't set on GdkWindows anymore.
There should be no circumstances where an implicit grab is requested but
no focus exists, there's however circumstances (like windowing grabs taking
input to a different window) where we might get implicit grabs being undone
when then new window didn't create a focus for the pointer itself.
Only if they fall outside the grab widget, in that case the widget holding
the implicit grab won't be receiving events anymore, so we can just undo
it.
We now rely on toplevels receiving and forwarding all the events
the windowing should be able to handle. Event masks are no longer a
way to determine whether an event is deliverable ot a widget.
Events will always be delivered in the three captured/target/bubbled
phases, widgets can now just attach GtkEventControllers and let those
handle the events.
Unlike GTK+ grabs which are global to all/one device, the implicit grab
is per focus, which means each may have implicit grabs on different or
the same widget.
Each toplevel will keep its own tracking of the current ongoing foci,
add the plumbing that will allow to create/update/remove those as they
come and go.
The user data passed when exporting a Wayland window was supposed to be
freed using the destroy_func, as is commonly done. This was previously
broken, as the user data was just NULL:ed when exported, and only
actually destroyed when unexporting before having exported.
While e016d9a5db fixed this, it introduced
a regression, as GtkWindow was nice enough to free the memory anyway
after having received the exported handle, causing it now to double
free.
https://bugzilla.gnome.org/show_bug.cgi?id=782109
This was only every implemented under X11, and with CSD,
this is clearly in the application realm. We should not
pretend that we can support it on the toolkit level.
https://bugzilla.gnome.org/show_bug.cgi?id=775061
and remove gsk_renderer_get_for_display().
This new function returns a realized renderer. Because of that, GSK can
catch failures to realize, destroy the renderer and try another one.
Or in short: I can finally use GTK on Weston with the nvidia binary
drivers again.
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
Instead of having a gsk_renderer_set_window() call, pass the window to
realize(). This way, the realization can fail with the wrong window.
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
We need to unrealize the children manually for that to happen, but so it
goes.
The order is necessary because we want the renderer to still be alive
while children are unrealizing.
We want to unrealize the renderer only after all widgets have been
unrealized. Otherwise, the widgets cannot release rendering resources
like textures.
and gtk_snapshot_render_frame() to be direct replacements for the
old gtk_render_*() functions.
Use them to replace Cairo usage completely in gtk_window_snapshot().
We now try to emulate cairo_t:
We keep a stack of nodes via push/pop and a transform matrix.
So whenever a new node is added to the snapshot, we transform it
by the current transform matrix and append it to the current node.
Switch code to use gdk_display_is_composited() instead.
The new code also doesn't use a vfunc to query the property but rather
requires the backend to call set_composited()/set_rgba() to change the
value.
Includes the ability to turn on updates in the inspector. Animations are
now run via a tick function which allows us to neatly overlay a
semi-transparent red rectangle and fade it out over time.
It also probably enables way more, but somebody with more UI neatness
than me needs to figure out what it eanbles first...
Before, we would immediately invalidate the GdkWindow of the widget, now
we call the parent's GtkWidgetClass.queue_draw_child() function.
This allows the parent to track redraw queueing of children.
By default GtkWidgetClass.queue_draw_child() will again chain up to its
parent while respecting the GdkWindow hierarchy for clipping.
GtkWindow is then the only widget actually invalidating the GdkWindow.
This essentially moves redraw queueing from GDK to GTK.
These complicate a lot of GdkWindow internals to implement features
that not a lot of apps use, and will be better achieved using gsk.
So, we just drop it all.
Add a new ::measure vfunc similar to GtkCssGadget's that widget
implementations have to override instead of the old get_preferred_width,
get_preferred_height, get_preferred_width_for_height,
get_preferred_height_for_width and
get_preferred_height_and_baseline_for_width.
The details of the modelview and projection matrices are only useful for
the GL renderer; there's really no point in having those details
available in the generic API — especially as the Cairo fallback renderer
cannot really set up a complex modelview or a projection matrix.
Since we use an FBO to render the contents of the render node tree, the
coordinate space is going to be flipped in GL. We can undo the flip by
using an appropriate projection matrix, instead of changing the sampling
coordinates in the shaders and updating all our coordinates at render
time.
Render nodes need access to rendering information like scaling factors.
If we keep render nodes separate from renderers until we submit a nodes
tree for rendering we're going to have to duplicate all that information
in a way that makes the API more complicated and fuzzier on its
semantics.
By having GskRenderer create GskRenderNode instances we can tie nodes
and renderers together; since higher layers will also have access to
the renderer instance, this does not add any burden to callers.
Additionally, if memory measurements indicate that we are spending too
much time in the allocation of new render nodes, we can now easily
implement a free-list or a renderer-specific allocator without breaking
the API.
We need a virtual function to retrieve the GskRenderNode for each
widget, which is supposed to attach its own children's GskRenderNodes.
Additionally, we want to maintain the existing GtkWidget::draw mechanism
for widgets that do not implement get_render_node() — as well as widgets
that have handlers connected to the ::draw signal.
