Currently there is no way to alter the offset of the popup when positioning
with GdkPopupLayout. This makes using the popup difficult for scenarios
like completion windows where you may need to offset the window by a given
amount for aligning text.
gtk_popover_set_offset() allows setting these values and are analagous to
the function of the same name for GdkPopupLayout.
When we invalidate a y_range using the common pattern of y==0 and
old_height==new_height, we are generally invalidating the entire buffer.
This short-circuits that case to just invalidate the buffer in a faster
and more complete form. The problem here appears to be that we can't
always calculate the ranges properly to invalidate because validation
has not run far enough.
When asking for a password, the message string is split on primary
and secondary if it contains a newline character. However, the newline
character is currently part of both strings, which creates weird
spacing between the GtkLabels. I suppose this is bug, which was not
visible as in most cases (if not all) the message string hasn't
contained the new line characters so far. But we are going to change
that now, see GNOME/gvfs!82. Let's drop the new line character similarly
as it is done when asking for a question, or showing processes in order
to fix the weird spacing.
We were not removing the pending_update idle
in dispose, which is at least suspicious, if
not deadly. Move the idle cleanup code into
unset_widget(), which we are already calling
in dispose().
As things currently stand, we get events for focus changes
before the widget is allocated, and try to scroll in response.
Therefore, leaving n_columns at 0 until size-allocate leads
to plenty of division-by-zero. Just set it to 1 initially
to avoid that. This is a workaround for #3025.
The regular paths just emit ::end, which isn't the whole thing.
This gives an opportunity to gestures that are stolen the sequence
to clean themselves up.
GtkAspectFrame code assumes that its child will be in
self->child, but that is only the case if we arrange
for <child> in ui files to end up calling
gtk_aspect_frame_set_child(). Therefore, implement
GtkBuildable.
Fixes: #3020
We were playing fast-and-loose with private GIO data
when showing settings bindings in the property editor,
and this was causing crashes.
We can show this information again if GIO ever gets
api to introspect it.
Fixes: #3015
GTK will not up front know how to correctly calculate a size, since it
will not be able to reliably predict the constraints that may exist
where it will be mapped.
Thus, to handle this, calculate the size of the toplevel by having GDK
emitting a signal called 'compute-size' that will contain information
needed for computing a toplevel window size.
This signal may be emitted at any time, e.g. during
gdk_toplevel_present(), or spontaneously if constraints change.
This also drops the max size from the toplevel layout, while moving the
min size from the toplevel layout struct to the struct passed via the
signal,
This needs changes to a test case where we make sure we process
GDK_CONFIGURE etc, which means we also needs to show the window and
process all pending events in the test-focus-chain test case.
If we have a y==-1 then we are generally invalidating the whole textview.
For this case, we can just discard the entire GtkTextLineDisplay cache.
Fixes#2975
We don't want the completions to pop up after we call
gtk_file_chooser_set_current_name(). This used to be
handled by gtk_entry_set_text() blocking the completion
signal handler. We don't have that anymore, so block
popup completion around the call to gtk_editable_set_text()
instead.
Fixes: #2995
We can only insert tags in the buffer if they come
from the same GtkTextTagTable as the buffer uses.
If that is not the case, paste the text without tags.
Fixes: #2991
While we guarantee that the widget that a controller
is attached to stays around while it is handling an event,
the same is not true for the root that the widget belongs
to. In corner cases (such as clicking "Close" in the
fallback window menu), it may already be gone.
Avoid a critical in that case.
Fixes: #2998
We don't want to select on focus-in when the focus
comes from a child. The case where this does harm
is when you activate copy or paste actions from the
context menu. We close the menu before triggering the
action, and if that causes the text in the label to
be selected, unexpected things happen, since the action
applies to the current selection.
This is the equivalent of cd9f5733b3 for GtkLabel.
The code used to do
if (parent_class->clicked)
parent_class->clicked (...)
That is pointless because the parent_class never changes,
so there' no need for that if and commit 415946eb0f
took it out. Unfortunately, p arent_class->clicked is NULL
though, so the whole call needs to go.
Use the new GTK_CROSSING_ACTIVE crossing events to update
the im context focus when the window becomes active or
inactive. IBus requires this, since it has only a single,
global focus location.
Fixes: #2390
Emit crossing events when the active window changes.
We don't want to emit GTK_CROSSING_FOCUS events, since
every window has its own focus location (focus does not
jump from window to window), so we use the new
GTK_CROSSING_ACTIVE type of crossing event for this.
Document the different crossing event kinds that we use,
and add GTK_CROSSING_ACTIVE. We are going to use it in
the future when the active window changes.
Set the accessible role for GtkLinkButton to button.
We don't use the 'link' role since ARIA says "if it
behaves like a button, use 'button'".
Update docs and add a test.
This changes should not be neccessary, since
GtkLinkButton derives from GtkButton, see #2965.
It's not a portable API, so remove it. The corresponding backend
specific functions are still available, if they were implemented, e.g.
gdk_macos_monitor_get_workarea() and gdk_x11_monitor_get_workarea().
Make GdkEvents hold a single GdkDevice. This device is closer to
the logical device conceptually, although it must be sufficient for
device checks (i.e. GdkInputSource), which makes it similar to the
physical devices.
Make the logical devices have a more accurate GdkInputSource where
needed, and conflate the event devices altogether.
Use the label accessible role for GtkLabel. ARIA has some
ominous wording about it going way, but while we have it,
GtkLabel is the obvious candidate for carrying it.
Update the documentation and add a test.
In some cases we explicitly want to unset an accessible attribute; for
instance, an accessible property is gated on a widget property, and if
the widget property gets unset, the accessible property should be reset.
We're currently overloading NULL to mean both "this value is undefined,
and should be reset to its default" and "the value collection failed".
Let's do error reporting right, by using GError to mean "the collection
failed, for this specific reason"; then, we can use a NULL return value
to signal that the accessible attribute should be reset to its default
value.
This is only relevant for pointer-sized attribute values: strings,
references, and reference lists; numeric, boolean, tristate, and token
values either cannot be undefined, or have a specific "undefined" value.
Show a tab for accessibility information.
This shows the role and the accessible attributes
(states, properties, relations).
For now, changing the values is not possible, and
we only show the explicitly set values. In the future,
we want to show the attributes that are relevant for
the role, regardless of whether they are set or not,
and allow changing some of the attributes (the ones
that are not fully managed by GTK itself).
We're stopping activity mode when finalizing, which will change
accessible state; this will create a GtkATContext, and since GtkWidget
drops its GtkATContext on dispose(), we're going to end up leaking it on
the floor:
```
2,007 (64 direct, 1,943 indirect) bytes in 1 blocks are definitely lost in loss record 36,242 of 36,944
at 0x483977F: malloc (vg_replace_malloc.c:307)
by 0x5222105: g_malloc (gmem.c:106)
by 0x523E222: g_slice_alloc (gslice.c:1025)
by 0x523E261: g_slice_alloc0 (gslice.c:1051)
by 0x534B398: g_type_create_instance (gtype.c:1849)
by 0x53302EE: g_object_new_internal (gobject.c:1937)
by 0x53312AF: g_object_new_valist (gobject.c:2262)
by 0x532FEE8: g_object_new (gobject.c:1780)
by 0x4B3F942: gtk_test_at_context_new (gtktestatcontext.c:107)
by 0x491CC50: gtk_at_context_create (gtkatcontext.c:380)
by 0x4BFEDA0: gtk_widget_accessible_get_at_context (gtkwidget.c:8127)
by 0x4906079: gtk_accessible_get_at_context (gtkaccessible.c:83)
by 0x490618F: gtk_accessible_update_state (gtkaccessible.c:137)
by 0x4ACBA6D: gtk_progress_bar_act_mode_leave (gtkprogressbar.c:690)
by 0x4ACB4F8: gtk_progress_bar_finalize (gtkprogressbar.c:564)
```
We're also unparenting widgets and changing styles, which is another
potential source of leaks and side effects.
We must initialize the properties in init, since they
are expected to be there ab initio, and we can't call
gtk_accessible_update_property from finalize - it causes
us to recreate an at context and badness follows.
