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.
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.
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.
GtkCellArea uses event coordinates (thus in treeview relative
coordinates), but calculations used to happen in bin window coords.
We can just offset the cell area by the bin window, fixes cell
renderer activation and edition.
The operations rely there on bin window relative coordinates, but we
are receiving GtkTreeView relative coordinates there. Fixes clicking
on treeview expanders, which was offset by visible headers.
Since gtk+ draws more than the widget and allocates more size to it than
it knows about, this flag doesn't work anymore. Removing it (or setting
it to TRUE for widgets that used to set it to FALSE) fixes drawing
invalidation when these widgets get allocated a new size.
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.
Checking the given GtkAllocation against the current allocation insize
::size-allocate doesn't really work anymore. They are only different if
the content allocation (the one passed) and the widget allocation (the
current one) are different, so e.g. when the widget has padding >0
applied.
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.
Insert the css node before setting a parent widget on the column button,
so the gtk_widget_set_parent won't attempt to add the css node as child
of the parent widget css node.
gtk_snapshot_pop() => removed
gtk_snapshot_pop_and_append() => gtk_snapshot_pop()
So now there is no way to get a rendernode out of the snapshotting API
until you gtk_snapshot_finish().
This ensures that the drawing does not extend the actually drawn area.
It also ensures that our math is sane, because the math assumes the clip
area cannot extend the window. After all, before GTK4 it always was like
that.
Fixes a bunch of drawing bugs when the clip area does indeed extend too
far.
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.
And with it, gtk_widget_get_visual() and gtk_widget_set_visual() are
gone.
We now always use the RGBA visual (if available) and otherwise fall back
to the system visual.
The fix for bug 767468 had some unintended side-effects. This is
an attempt at doing the same fix (don't grab focus when we are
grab-shadowed), while avoiding the breakage, by using GTK+'s
internal tracking for grab-shadowed-ness.
https://bugzilla.gnome.org/show_bug.cgi?id=770508
The cellrenderer signals might be taking the grab somewhere else, at which
point it's dubious we should attempt to take the keyboard focus into the
treeview.
This concretely breaks popovers triggered from cellrenderer signals on
button press, because the treeview will attempt to grab focus
inconditionally then.
https://bugzilla.gnome.org/show_bug.cgi?id=767468
gtk_tree_view_get_path_at_pos() mistakenly identifies the first
pixel of all but the first column in a tree view as belonging to
the previous column.
https://bugzilla.gnome.org/show_bug.cgi?id=708148
When starting a rubberband selection from an empty area, we could run
into crashes if the selection moves over the rows and then back out
to unpopulated area. Handle this case without crashing.
https://bugzilla.gnome.org/show_bug.cgi?id=766336
If there was a piece of text in the cell, then when the edit
entry is shown for that cell, it should have a piece of text
in it roughly at the same location.
Therefore, when child widget is enlarged (child preferred
size exceeds cell size), extra width should be added by
extending either left or right edge depending on text direction.
If after that the child sticks outside of the treeivew visible region,
try to push it back inside (breaking its alignment with the
cell), again, giving preference (i.e. adjusting it last)
to either left or right edge depending on text direction.
https://bugzilla.gnome.org/show_bug.cgi?id=765471
It might have changed (eg. after a row being expanded, and the child
rows revalidated), so just update it here based on the last pointer
position.
Based on a patch by Maxim Reznik <reznikmm@gmail.com>
https://bugzilla.gnome.org/show_bug.cgi?id=760891
The pointer position is queried to properly trigger the prelight
updates on the new row below it. We store the last coordinates
though, and track crossing events to unset these, so it's safe
to just update_prelight() here on these.
The search window of a tree view was implemented by showing without
making it visible by by positioning it outside the screen edge. This is
not possible on Wayland, so implement another method for being able to
enter text into a non-visible entry.
The new method is implemented by, before showing the window, pass the
key event directly to the IM context backing the entry. If the key
event triggered the context to commit new text or change the preedit
content, the search window is shown, and from that point the key events
are forwarded directly to the entry widget.
https://bugzilla.gnome.org/show_bug.cgi?id=756780
These days exposure happens only on the native windows (generally the
toplevel window) and is propagated down recursively. The expose event
is only useful for backwards compat, and in fact, for double buffered
widgets we totally ignore the event (and non-double buffering breaks
on wayland).
So, by not setting the mask we avoid emitting these events and then
later ignoring them.
We still keep it on eventbox, fixed and layout as these are used
in weird ways that want backwards compat.
Code exists in the wild that calls this function after the widget has
been destroyed (and the pixel cache released). Simply check that the
pixel cache exists to preserve the existing state.
I believe that first_column can only ever be NULL here if
last_column is NULL too, in which case we'd exited already.
But coverity doesn't see that, so add an explicit exit.
GtkTreeView has a particularly expensive drawing path. This can cause
issues when part of animated widget sequences. Caching the content while
a model is attached helps reduce the number of full redraws during
exposure greatly.
https://bugzilla.gnome.org/show_bug.cgi?id=751082
Just use the last coordinates given on XdndPosition/drag_motion() in
order to trigger scrolling.
When running on Xwayland, the pointer position is unknown at this
stage on the X11 side, so the coordinates given here are bogus.
This change avoids both roundtrips and this situation.
https://bugzilla.gnome.org/show_bug.cgi?id=749679
When a treeview is destroyed while rubberbanding is going
on, we crash because the rb tree is nuked before we want
to access it to stop the rubberbanding. To avoid this crash
end the rubberbanding early in destroy().
See
https://bugzilla.redhat.com/show_bug.cgi?id=1173904
GPUs generally have problems when you create a 35000px wide surface.
Luckily X catches this and sends a BadAlloc. Which GTK immediately
abort()s on.
Testcase included.
https://bugzilla.redhat.com/show_bug.cgi?id=1163579
This is so signal handlers have an opportunity to undo its effect by
returning GDK_EVENT_STOP on ::button-press-event, just like they used
to do pre-gestures.
https://bugzilla.gnome.org/show_bug.cgi?id=735965
Use the left border color for tree lines. This is similar to
our use of top border color for grid lines. As a side-effect,
tree lines now get recolored when they are in a selected row.
https://bugzilla.gnome.org/show_bug.cgi?id=415415
The pre-gestures code used to compare the current button press with the
previous one on !activate_on_single_click, and unset the previous event
data so ::row-activated would be emitted every 2 clicks.
So do the same with the multipress gesture and reset it after every 2nd
click to have ::row-activated emitted multiple times while manic clicking.
https://bugzilla.gnome.org/show_bug.cgi?id=735353
That gesture is meant to handle clicks on multiple buttons, so unset
the GDK_BUTTON_PRIMARY default. Also, remove unnecessary boilerplate
with the new GtkGestureSingle/GtkEventController defaults.
https://bugzilla.gnome.org/show_bug.cgi?id=734285
This check used to be present in the pre-gestures code, but was unintentionally
removed when splitting code into drag/multiclick gestures. The policy used to
be that if clicking happened on an already selected node, DnD would happen
instead of rubberband selection, so this behavior is resuscitated.
https://bugzilla.gnome.org/show_bug.cgi?id=734143
The rules-hint property has always been a fairly bad application API, as
it set some wrong expectations for the developers; deferring to the
theme makes it impossible to design application reliably, and if this is
a usability setting we should either impose this setting on every theme,
or simply drop it.
Our own default theme does not honour the zebra striping, which makes
this function even more questionable.
In practice, usability studies on zebra striping have demonstrated that
alternating colors on a list it improves readability just as much as
clear ruling between rows, or by visually differentiating the selected
row. Zebra striping improves readability (or, at least, it does not
hinder it) on static displays, like a table on paper or a document; on a
dynamic display, like an application's UI, there are different
strategies that yield similar, if not better, results.
https://bugzilla.gnome.org/show_bug.cgi?id=733312
The animated scrolling interferes with incremental validation.
As short-term solution, disable scrolling animation during
incremental validation. This is not a proper solution, but
it avoids broken behavior like scrollbars that are not reacting
to clicks. The problem was visible, e.g. in the list view
example in gtk3-demo.
The animated scrolling interferes with incremental validation.
As short-term solution, disable scrolling animation during
incremental validation. This is not a proper solution, but
it avoids broken behavior like scrollbars that are not reacting
to clicks. The problem was visible, e.g. in the list view
example in gtk3-demo.
The reparenting happening on the column header so it gets a movable
window breaks the implicit grab, so this is one situation were we
want a pointer grab, if just to replace it.
https://bugzilla.gnome.org/show_bug.cgi?id=732933
Code was expecting view coordinates, not widget ones, as we're
only dealing with horizontal displacements, just adding the
horizontal adjustment value suffices.
https://bugzilla.gnome.org/show_bug.cgi?id=732933
Regions are done in a very non-css way. They don't fit the DOM in that
they don't integrate into the CSS tree and they have very weird matching
behavior in selectors.
So I'm deprecating them now. GtkNotebook and GtkTreeview will continue
to use them and as long as they do, we can't remove the code for it.
But once those are ported it might be safe to remove the code as it will
clean up lots of places in the code by quite a bit.
The rubberband rendering code was assuming that we just have
a 1-pixel border and the rest of the rubberband is uniform.
That is not a safe assumption to make with css-styled
rubberbands, so remove it.
The code is actually prepared for that, the gesture was initially limited
to only handling GDK_BUTTON_PRIMARY because it only used to handle row
activation.
This gesture acts only on events from the bin window, and checks that
either the pressed row is draggable, or the conditions for rubberband
selection apply.
A multipress gesture takes care of autosizing on double click, and
a drag gesture is used for both column dragging/resizing (only one
can happen at a time).
Otherwise the event is possibly handled, but still propagated further anyway.
Ensure the event is consumed by claiming the current sequence on the
GtkGestureMultiPress::pressed handler.
::row-activated only used to be triggered by GDK_BUTTON_PRIMARY, so make
the multipress gesture handling this now to be only triggered by that same
button.
https://bugzilla.gnome.org/show_bug.cgi?id=731020
