We normally wait for the surface ::size-changed signal,
but then we only queue a resize, which is not sufficient
on map - we need to have an allocation by the time start
moving focus around in show. So, call check_resize()
right away.
Rename gtk_window_move_resize to gtk_window_do_resize
(no moving involved anymore), rename configure_notify_received
to need_resize and replace gtk_window_guess_default_size
by gtk_window_compute_default_size.
We should not emit configure events before we
are realized - size changes at this point are
not relevant.
This gets rid of a mysterious emission of
GdkSurface::size-changed (52, 52), that is happening
when GtkWindow sets the shadow_width before the window
is mapped.
Surpisingly, when a monitored file gets atomically replaced
with g_file_set_contents(), the file monitor reports a
DELETED event for the temp file, which is not the file
I'm monitoring.
Just ignore DELETED events.
Fixes: #3036
G_DEFINE_DYNAMIC_TYPE declares these functions as static, and
-Werror=redundant-decls won't let us redeclare them. This is the
equivalent of 72c72d0b, but for a different backend.
Signed-off-by: Simon McVittie <smcv@debian.org>
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.
The colors demo was leaking a reference to its model.
This was showing up as crash when you manage to close
both the demo window and the main window while the
sorting is ongoing.
Drop the homegrown highlighting code, and just use highlight
to produce Pango markup.
When using an external highlighter, we can also highlight css,
xml, headers, at least.
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 might break the loop early, e.g. if we're unmapped before the round
trip finishes, and to avoid the callback to write to invalid stack
memory, destroy the callback so it won't be invoked.
Fixes: #3026
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 testsvg test uses a method in librsvg that was introduced in
2.46.0. The test is now skipped if the librsvg version is too old.
(It was previously already skipped if librsvg wasn't found.)
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.
The win toolchain has problems linking meson subprojects to libgtk.
To work around that build glib/pango from git and install them first
as long as the installed version is too old at least.
Fixes#3002
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.
gdk_gl_context_has_framebuffer_blit() and gdk_gl_context_has_frame_terminator()
were only used by by GDK/Win32, and they do not provide performance advantages
in GTK master, so clean up the code a bit by dropping them.
Check whether we really have x11 and wayland enabled before we try to setup the
tests to use these respective GDK backends, and only attempt to setup tests
running with the Broadway backend if it has been enabled.
Also, add a setup for running tests with the GDK-Win32 backend on Windows, for
builds that target Windows.
Use gdk_surface_get_geometry() to get the correct x and y coordinates of the
window that we are resizing, so that the window does not reposition itself
automatically at the top-left corner at resizing as we to used hard-code the x
and y coordinates to 0.
By doing so, we ensure that resizes of windows will work on Vulkan renderer, by
first calling gdk_win32_surface_handle_queued_move_resize() before we proceed
as usual
Use the shared function that was added in the previous commit, to simplify
things.
Also make gdk_win32_surface_get_queued_window_rect() and
gdk_win32_surface_apply_queued_move_resize() back into static functions, since
they are now used only by the code in gdksurface-win32.c
Since we need to deal with queued moves and resizes in the Cairo, GL and Vulkan
draw contexts, and the logic involved in all three of these are largely
similar, add a function gdk_win32_surface_handle_queued_move_resize() that will
handle this, which will be shared between these three types of draw contexts.
Move gdk_win32_surface_get_queued_window_rect() and
gdk_win32_surface_apply_queued_move_resize() to gdksurface-win32.c, since these
functions are not only used for Cairo draw contexts, but is also used for GL
draw contexts, and will be used for Vulkan draw contexts.
Don't get the default display when we compute the Aerosnap region, but instead
get it from the underlying GdkSurface that we are using for the computation.
Also, don't unref the monitors that we obtain from the display in the wrong
place, which was why we had crashes whenever we triggered AeroSnap code (and we
are actually not supposed to do that as they are owned by the GdkDisplay that
is owned by the GdkSurface we are using), and this will eliminate lots of
criticals that are spewed as a result.
gtk-doc assumes Docbook4, with <ulink> and so on.
Without this, all the links in markdown are converted
to <link xlink:href=...> and then lost in the docbook->html
conversion.
We can't use the ::destroy signal anymore; use
a weak ref instead, and make ensure the entry
stays around long enough for us to finish the
cleanup.
Fixes: #3004
No need for an intermediate box widget here;
we can just use a box layout. As a side-effect,
this fixes the theme to apply to the selection.
Fixes: #3005
ss00 doesn't exist, and we use xxxx as placeholder
for 'default' choices in alternatives. Add a warning
in case we run across invalid OpenType feature tags
in fonts.
Fixes: #2962
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.
This check used to read if (grab || device_type != GDK_DEVICE_TYPE_PHYSICAL),
the grab check was only reserved to physical devices, which the current
pointer device definitely doesn't act like. So the condition was "fixed" the
wrong way around, and the latter check is now moot, so the condition should
really go away. We always want to check the new toplevel under the pointer
here.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/2970
This allows us to use DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2 for the
DPI awareness mode, which will help us to better support use cases with
multiple monitors. This is actualy a more advaned version of the
current PROCESS_PER_MONITOR_DPI_AWARE via using SetProcessDpiAwareness().
Note that this is not enabled by default, but also enabled via using
GDK_WIN32_PER_MONITOR_HIDPI, as in the PROCESS_PER_MONITOR_DPI_AWARE
case.
Note also, that appliation compatibility settings and DPI-awareness
manifests takes precedence over this API call, as before.
Since we have now made the Win32 GL contexts share the global context as
the other backends have, we are more ready to use the GL renderer by
default on Windows as well.
Note that currently we can only enable this when not running on
OpenGL/ES as the OpenGL/ES shaders are not ready at this point, and the
OpenGL/ES support that we have from libANGLE does not support full
desktop OpenGL operations.
Like the other backends, we ought to create our WGL/EGL GL contexts like
the following:
"Create a global GL context that connects all GL contexts on a display
and lets us share textures between them."
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.
If GLES support is enabled on Windows, force GLES mode if we are running
on a ARM64 version of Windows (i.e. Windows 10 for ARM).
This is required as ARM64 versions of Windows only provide a software
implementation of OpenGL 1.1/1.2, which is not enough for our purposes.
Thus, we could make instead use the GLES support provided via Google's
libANGLE (which emulates OpenGL/ES 3 with Direct3D 9/11), so that we
can run GtkGLArea programs under OpenGL/ES in ARM64 versions of Windows.
Note that eventually we could update the libepoxy build files for Windows
to not check nor enable WGL when building for ARM64 Windows, as the WGL
items do not work, although they do build.
We need to use GL_BGRA instead of GL_RGBA when doing glReadPixels() on
EGL on Windows (ANGLE) so that the red and blue bits won't be displayed
inverted.
Also fix the logic where we determine whether to bit blit or redraw
everything.
Some implementations of the ES 1.00 shader (such as Google's ANGLE) do
not like the 'f' suffix for floats, so just drop it, as it should be
harmless to drop.
This is for adding a EGL-based renderer which is done via the ANGLE
project, which translate EGL calls to Direct3D 9/11. This is done as a
possible solution to issue #105, especially for cases where the needed
full GL extensions to map OpenGL to Direct3D is unavailable or
unreliable, or when the OpenGL implementation from the graphics drivers
are problematic.
To enable this, do the following:
-Build ANGLE and ensure the ANGLE libEGL.dll and libGLESv2.dll are
available. A sufficiently-recent ANGLE is needed for things to
work correctly--note that the copy of ANGLE that is included in
qtbase-5.10.1 is sufficient. ANGLE is licensed under a BSD 3-clause
license.
-Build libepoxy on Windows with EGL support enabled.
-Currently, prior to running GTK+ programs, the GDK_DEBUG envvar needs
to be set with gl-gles as at least one of the flags.
Known issues:
-Only OpenGL ES 3 is supported, ANGLE's ES 2 does not support the needed
extensions, notably GL_OES_vertex_array_object, but its ES 3 support is
sufficient.
-There is no autodetection or fallback mechanism to enable using
EGL/Angle automatically yet. There are no plans to do this in this
commit.
...EGL support needs to be explicitly enabled during the build of
libepoxy on Windows as it is not enabled by default on Windows.
With this, we can add an EGL renderer for Windows that make use of
Google's libANGLE, which is a library that translates OpenGL/ES calls
to Direct3D 9/11, which will provide better hardware compatibility
on Windows and would act as one of the foundations to resolve issue #105.
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().
pandoc insists on using the xlink namespace for hrefs,
and the namespace setup doesn't carry over xi:includes.
My first fix was to tell pandoc to generate standalone
docbook documents, which makes it insert the xlink
namespace. But it also makes it wrap all sections and
chapters in articles, and that messes up our toc structure.
So, patch things up differently by stripping the xlink:
from hrefs via regex.
Yay for XML!
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.
Besides the implicit x/y assumptions, devices don't have axes. Those
are actually provided by the GdkDeviceTool driving the device, and
different tools may have different axes.
It does not make sense to offer this API that can change beneath
someone's feet, we now have gdk_device_tool_get_axes() which is static
to the tool.
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.
Sysprof has moved to a new ABI which removes GLib from the capture library
so that GLib itself can link against sysprof-capture.
This bumps the library ABI so we can keep things coordinated between all
the new tracing layers in the stack.
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.
Looking at the xf86-input-wacom driver code, this is not even a thing
anymore. Drop this device type, in modern days there's
GDK_DEVICE_TOOL_TYPE_MOUSE for this.
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.
Track what we really need to send for inset shadows, which are used
as a border replacement in many cases.
Fishbowl says I can draw around 200-300 more switches per frame like
this too.
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.
When converting DisplayLink frame presentation times, we need to take into
account the arch-specific types. This tracks changes in GNOME/GLib!1566 so
that precision is not lost.
Accessible values storing references and reference lists can be unset by
using NULL to mean "undefined"; since we cannot return the NULL value,
we need to intercept it when collecting a value, and replace it with an
undefined GtkAccessibleValue, which is also the value used as the
default for GtkAccessibleRelation values that store a reference or a
reference list.
Fixes: #2955
Make both gtk_grid_view_new and gtk_grid_view_new_with_factory
take a model as first argument, and make all arguments
allow-none and transfer full.
Update all callers.
Make both gtk_list_view_new and gtk_list_view_new_with_factory
take a model as first argument, and make all arguments
allow-none and transfer full.
Update all callers.
A dropdown without a model is useless, so accept a model
and expression in the constructor. Allow them to be NULL,
but consume them if given. This makes chained constructors
convenient without breaking language bindings.
Drop gtk_drop_down_set_from_strings() and instead add
gtk_drop_down_new_from_strings().
Update all users.
We don't pay attention to item-type anymore, so
drop the item-type property and the _for_item_type()
constructor, and allow passing NULL to the regular
constructor.
We don't make this constructor transfer-full, since
the selection filter model is not a wrapping model
like the others. It is more like fork than a wrap.
This is for consistency with other wrapping list constructors.
We want them all to be transfer full, allow-none.
Also make the constructor return GtkMultiSelection *.
Update all callers.
Make gtk_tree_list_model_new() take the root model
as first argument, and make it transfer full, for
consistency with other wrapping list constructors.
Update all callers.
Still missing here: Make the model property writable,
and allow passing NULL in the constructor.
We don't need as many functions to print out the property, relation, and
state of an accessible. Additionally, we should allow comparing the
accessible attributes with an expected value, and print out the real
accessible value if they do not match.
Some widgets have different roles after they are constructed, so we need
to allow changing the role defined by the class. We should still avoid
setting a role after the GtkATContext has been created.
This is a bit unfortunate, since the aria modelling
doesn't quite agree with ours, so we have to listen
for the togglebutton property change, and we inherit
the pressed state from the togglebutton accessible.
Only GtkWidget should use GTK_ACCESSIBLE_ROLE_WIDGET as its default
accessible role; the default for GtkAccessible and GtkATContext should
be GTK_ACCESSIBLE_ROLE_NONE, meaning "an element whose implicit native
role semantics will not be mapped to the accessibility API", according
to the WAI-ARIA specification.
We want to test the accessibility API, as well as the implementation
inside each widget. For that, we should expose an API that lets us
verify that a GtkAccessible has a given role, as well as a given
property.
The API follows the pattern of other GTest API:
- a macro to assert that a condition is respected
- a function that prints out the error message in case of failure
While we have split the various attributes for convenience, there's no
reason why we should have specialised data types for the attributes
container object.
Reduce the amount of subclassing, by handling collection of fundamental
types directly from the generic code paths. We now handle boolean,
tristate, integer, number, string, and relation values in the generic
code path; if an attribute supports the "undefined" value, we return the
undefined value singleton.
Drop roles and properties that were deprecated in WAI-ARIA 1.1, and add
new roles and properties defined in WAI-ARIA 1.2 and later.
We also split the relationship properties into their own enumeration, so
we can keep the GtkAccessibleProperty type more compact.
It's pointless, we can use an explicit value of `-1` everywhere.
Additionally, it complicates all code that uses the state enumeration as
an array index, since now we need to guard against a negative offset.
Some widgets have different accessible roles depending on some
parameter, so we cannot set the role at class init time. For those
widgets, we add an "accessible-role" property to GtkAccessible, and we
allow setting it (only) at construction time.
Each widget type has an accessible role associated to its class, as
roles cannot change during the life time of a widget instance.
Each widget is also responsible for creating an ATContext, to proxy
state changes to the underlying accessibility infrastructure.
An Accessible implementation must create an ATContext object. UI
elements are supposed to interact with the GtkAccessible API, but we
expose GtkATContext to allow patterns like delegation.
The ATContext type is meant to be used as the base class for
implementations of the assistive technology API—the actual mechanism
needed to communicate to components like the screen reader, or any other
AT.
Every time the widget state changes, the ATContext is meant to broadcast
the state change; and every time the AT queries the state of a UI
element, the ATContext is meant to provide that information.
We also have a "test" ATContext implementation, which is meant to be
used to write tests to verify that changes are propagated without
requiring a whole desktop session.
All accessible properties and states may have one of the following
types:
- true/false
- true/false/undefined
- true/false/mixed/undefined
- reference (to another UI element)
- reference list
- integer
- number (real numerical value)
- string
- token (one of a limited set of allowed values)
- token list
See: https://www.w3.org/WAI/PF/aria/states_and_properties#propcharacteristic_value
The GtkAccessibleValue is a simple reference counted type that can be
"subclassed" to implement each value type.
This initial commit adds GtkAccessibleValue and the basic subclasses for
plain boolean, tristate (true/false/undefined), and token types,
including statically allocated values that can be shared instead of
allocated.
GtkAccessible is an interface for accessible UI elements.
Currently, it doesn't do much except exist as a type; in the future, it
will be the entry point for all accessible state in GTK.
The list of roles is taken from the WAI-ARIA 1.2 specification:
https://w3c.github.io/aria/
Some of these roles do not make entirely sense from a GTK application
perspective, but we can remove them before finalizing the API.
To build a better world sometimes means having to tear the old one down.
-- Alexander Pierce, "Captain America: The Winter Soldier"
ATK served us well for nearly 20 years, but the world has changed, and
GTK has changed with it. Now ATK is mostly a hindrance towards improving
the accessibility stack:
- it maps to a very specific implementation, AT-SPI, which is Linux and
Unix specific
- it requires implementing the same functionality in three different
layers of the stack: AT-SPI, ATK, and GTK
- only GTK uses it; every other Linux and Unix toolkit and application
talks to AT-SPI directly, including assistive technologies
Sadly, we cannot incrementally port GTK to a new accessibility stack;
since ATK insulates us entirely from the underlying implementation, we
cannot replace it piecemeal. Instead, we're going to remove everything
and then incrementally build on a clean slate:
- add an "accessible" interface, implemented by GTK objects directly,
which describe the accessible role and state changes for every UI
element
- add an "assistive technology context" to proxy a native accessibility
API, and assign it to every widget
- implement the AT context depending on the platform
For more information, see: https://gitlab.gnome.org/GNOME/gtk/-/issues/2833
We are using floats for rgb, and we don't need more precision
for hsl colors either. We use hsl for computing color expressions
like shade(), lighter() and darker(), which are not precisely
specified anyway.
This commit updates the one test where the output changes a
tiny bit due to this.
Setting a width request is not quite enough, since
gtk_widget_set_size_request() only queues a resize
when the widget is visible. Explicitly force one
here. Without this, the popup sometimes shows up
too small.
This is truly a russian doll of documentation formats:
a string containing <> inside an xml fragment in an |[ ]|
gtk-doc example in markdown in a doc comment.
Sadly, something gets escaping wrong, so the <> end up
literally in the docbook and mess up the last step of
our document formatting, even after turning them into
entities.
Work around this with an extra level of entities that
really shouldn't be necessary.
This flag causes pandoc to emit a proper doctype
declaration and, crucially, namespace declarations
for the xlink namespace that it insists on using
for href attributes. Without this, putting external
links in md documents doesn't survive the journey
through xml.
Commit 0145809a94 replace the response-requested
signal with an action, but didn't actually remove the emission
of that no-longer-existing signal.
Fixes: #2942
Add a table mapping event signals to their event controller
replacements, and a table mapping former GtkContainer
subclasses to their gtk_container_add replacement.
SSave the missing keys as a bitset and iterate over that bitset in the
step function.
Solves the problem with a large UI block at the beginning of a sort
operation when all the keys were generated, in particular when key
generation was slow.
Benchmarks for maximum time taken by a single main loop callback:
initial sort with complex GFileInfo keys
old new
32,000 items 137ms 3ms
128,000 items 520ms 31ms
initial sort with string keys
old new
32,000 items 187ms 1ms
128,000 items 804ms 3ms
When updating a (partially) sorted model, take the known runs for the
existing sort and apply them to the new sort. That way, we don't have to
check the whole model again.
Benchmarks:
appending half the items to a model of strings
old new
512,000 items 437ms 389ms
1,024,000 items 1006ms 914ms
appending 10% of the items to a model of strings
old new
512,000 items 206ms 132ms
1,024,000 items 438ms 301ms
appending 1 item to a model of strings
old new
64,000 items 1.8ms 0.00ms
512,000 items --- 0.01ms
Previously, the sort was not stable when items were added/removed while
sorting or the sort algorithm was changed.
Now the sort looks at the item position (via the key's location in the
keys array) to make sure each comparison stays stable with respect to
this position.
This massively speeds up sorting with expensive sort functions that it's
the most worthwhile optimization of this whole branch.
It's slower for simple sort functions though.
It's also quite a lot slower when the model doesn't support sort keys
(like GtkCustomSorter), but all the other sorters do support keys.
Of course, this depends on the number of items in the model - the number
of comparisons scales O(N * log N) while the overhead for key handling
scales O(N).
So as the log N part grows, generating keys gets more and more
beneficial.
Benchmarks:
initial sort of a GFileInfo model with display-name keys
items keys
8,000 items 715ms 50ms
64,000 items --- 554ms
initial sort of a GFileInfo model with complex keys
items keys
64,000 items 340ms 295ms
128,000 items 641ms 605ms
removing half a GFileInfo model with display-name keys
(no comparisons, just key freeing overhead of a complex sorter)
items keys
512,000 items 14ms 21ms
2,048,000 items 40ms 62ms
removing half a GFileInfo model with complex keys
(no comparisons, just key freeing overhead of a complex sorter)
items keys
512,000 items 90ms 237ms
2,048,000 items 247ms 601ms
GtkSortKeys is an immutable struct that can be used to manage "sort
keys" for items.
Sort keys are memory that is created specifically for sorting. Because
sorting involves lots of comparisons, it's a good idea to prepare the
data relevant for sorting in advance and sort on that data.
In measurements with a PropertyExpression on a string sorter, it's about
??? faster
Instead of one item keeping the item + its position and sorting that
list, keep the items in 1 array and put the positions into a 2nd array.
This is generally slower while sorting, but allows multiple improvements:
1. We can replace items with keys
This allows avoiding multiple slow lookups when using complex
comparisons
2. We can keep multiple position arrays
This allows doing a sorting in the background without actually
emitting items-changed() until the array is completely sorted.
3. The main list tracks the items in the original model
So only a single memmove() is necessary there, while the old version
had to upgrade the position in every item.
Benchmarks:
sorting a model of simple strings
old new
256,000 items 256ms 268ms
512,000 items 569ms 638ms
sorting a model of file trees, directories first, by size
old new
64,000 items 350ms 364ms
128,000 items 667ms 691ms
removing half the model
old new
512,000 items 24ms 15ms
1,024,000 items 49ms 25ms
1. Run step() for a while to avoid very short steps
This way, we batch items-changed() emissions.
2. Track the change region accurately
This way, we can avoid invalidating the whole list if our step just
touched a small part of a huge list.
As this is a merge sort, this is a common occurence when we're buys
merging chunks: The rest of the model outside those chunks isn't
changed.
Note that the tracking is accurate: It determines the minimum change
region in the model.
This will be important, because the testsuite is going to test this.
... and use it in the SortListModel
Setting runs allows declaring already sorted regions so the sort does
not attempt to sort them again.
This massively speeds up partial inserts where we can reuse the sorted
model as a run and only resort the newly inserted parts.
Benchmarks:
appending half the model
qsort timsort
128,000 items 94ms 69ms
256,000 items 202ms 143ms
512,000 items 488ms 328ms
appending 1 item
qsort timsort
8,000 items 1.5ms 0.0ms
16,000 items 3.1ms 0.0ms
...
512,000 items --- 1.8ms
Simply replace the old qsort() call with a timsort() call.
This is ultimately relevant because timsort is a LOT faster in merging
to already sorted lists (think items-chaged adding some items) or
reversing an existing list (think columnview sort order changes).
Benchmarks:
initially sorting the model
qsort timsort
128,000 items 124ms 111ms
256,000 items 264ms 250ms
The model now tracks the original positions on top of just the items so that
it can remove items in an items-changed emission.
It now takes twice as much memory but removes items much faster.
Benchmarks:
Removing 50% of a model:
before after
250,000 items 135ms 10ms
500,000 items 300ms 25ms
Removing 1 item:
4,000 items 2.2ms 0ms
8,000 items 4.6ms 0ms
500,000 items --- 0.01ms
This is the dumbest possible sortmodel using an array:
Just grab all the items, put them in the array, qsort() the array.
Some benchmarks (setting a new model):
125,000 items - old: 549ms
new: 115ms
250,000 items - new: 250ms
This performance can not be kept for simple additions and removals
though.
This is fairly substantial rewrite of the GDK backend for quartz and
renamed to macOS to allow for a greenfield implementation.
Many things have come across from the quartz implementation fairly
intact such as the eventloop integration design and discovery of
event windows from the NSEvent.
However much has been changed to fit in with the new GDK design and
how removal of child GdkWindow have been completely eliminated.
Furthermore, the new GdkPopup allows for regular NSWindow to be used
to provide popovers unlike the previous implementation.
The object design more closely follows the ideal for a GDK backend.
Views have been broken out into subclasses so that we can support
multiple GSK renderer paths such as GL and Cairo (and Metal in the
future). However mixed mode GL and Cairo will not be supported. Currently
only the Cairo renderer has been implemented.
A new frame clock implementation using CVDisplayLink provides more
accurate information about when to draw drawing the next frame. Some
testing will need to be done here to understand the power implications
of this.
This implementation has also gained edge snapping for CSD windows. Some
work was also done to ensure that CSD windows have opaque regions
registered with the display server.
** This is still very much a work-in-progress **
Some outstanding work that needs to be done:
- Finish a GL context for macOS and alternate NSView for GL rendering
(possibly using speciailized CALayer for OpenGL).
- Input rework to ensure that we don't loose remapping of keys that was
dropped from GDK during GTK 4 development.
- Make sure input methods continue to work.
- Drag-n-Drop is still very much a work in progress
- High resolution input scrolling needs various work in GDK to land
first before we can plumb that to NSEvent.
- gtk/ has a number of things based on GDK_WINDOWING_QUARTZ that need
to be updated to use the macOS backend.
But this is good enough to start playing with and breaking things which
is what I'd like to see.
This was preventing any sort of building on macOS, even though the quartz
backend is currently non-functional. Fixing this is a pre-requisite to
getting a new macOS backend compiling.
Run the gdkkeysyms-update.pl script to pick up several
new keysyms:
GDK_dead_lowline
GDK_dead_aboveverticalline
GDK_dead_belowverticalline
GDK_dead_longsolidusoverlay
GDK_Keyboard
GDK_WWAN
GDK_RFKill
GDK_AudioPreset
Changing the selection in the object tree is
not a useful action if we are already in the
object details. Most likely, a user who picks
an object wants to inspect its details, so
just always show them.
Fixes: #1876
Bring back the actions tab; we don't receive
changes anymore, since GtkActionMuxer lost
the GActionGroup signals for this, and the
action observer machinery has no way to listen
for all changes.
Instead of implementing the GActionGroup interface
and using its signals for propagating changes up
and down the muxer hierarchy, use the GtkActionObserver
mechanism. This cuts down on the signal emission
overhead.
We should not rely on GtkWindow to have global
"activate-default" key bindings that happen to
fall back to activating the focus widget. This is
unreliable, since the bubbling up from the button
to the toplevel may run across other widgets that
may want to use Enter for their own purpose, and
then the button loses out. By adding our own
key bindings, the button gets to handle it before
its ancestors.
This fixes check buttons in the inspector property
list not reacting to Enter despite having focus.
If we don't, an ancestor (such a GtkListItemWidget)
may interpret the click as "I should grab focus!",
and still our focus away. This was causing hard-to-focus
entries in the property list in the inspector.
We were hiding the inspector when the window
is closed, but that has the side-effect of
keeping references to application windows,
so we would keep them artificially alive,
which can have side-effects.
So, make the inspector go away when closed.
This fixes the widget factory rendering too much.
In the widget-factory, we generally have a pretty small update area (two
spinners and a progressbar). We take the extents of that as a update
area and inital clip.
However, the first clip node we see is from the toplevel window, which
essentially increases the clip again to almost the entire window.
Fix that by ignoring such cases.
Porting code from GTK 3 without the ability to subclass GtkTreeView
directly can cause an extreme amount of pain on application developers.
It can also complicate performance when it comes to dealing with
encapsulation as the outer widget would also encapsulate the GtkScrollable
implementation from GtkTreeView, typically through GtkViewport.
Fixes#2936
That way, demo windows can be maximized and multiple demos can run at
once.
It's especially useful when using --run because the main window is
invisible then.
* GDK_ARRAY_BY_VALUE
#define this to get GArray-like behavior
* gdk_array_splice (v, 0, 0, NULL, 25)
Adding items but passing NULL as the items will zero() them.
* gdk_array_set_size()
A nicer way to call gdk_array_splice()
* constify getters
This is a scary idea where you #define a bunch of preprocessor values
and then #include "gdkarrayimpl.c" and end up with a dynamic array for
that data type.
See https://en.wikipedia.org/wiki/X_Macro for what's going on.
What are the advantages over using GArray or GPtrArray?
* It's typesafe
Because it works like C++ templates, we can use the actual type of
the object instead of having to use gpointer.
* It's one less indirection
instead of 2 indirections via self->array->data, this array is
embedded, so self->array is the actual data, and just one indirection
away. This is pretty irrelevant in general, but can be very noticable
in tight loops.
* It's all inline
Because the whole API is defined as static inline functions, the
compiler has full access to everything and can (and does) optimize
out unnecessary calls, thereby speeding up some operations quite
significantly, when full optimizations are enabled.
* It has more features
In particular preallocation allows for avoiding malloc() calls, which
can again speed up tight loops a lot.
But there's also splice(), which is very useful when used with
listmodels.
This feature was previously only supported on DBus compositors, such as
Mutter, this adds support for other compositors such as all of those
based on wlroots.
This implementation prefers the idle-inhibit Wayland protocol to the
DBus version if it is available, since the inhibitor is per-surface
instead of global it allows a finer control over which displays get
dimmed for instance. For every case not supported by this protocol, a
fallback to the DBus version is used.
It can’t do anything if the GtkWindow isn’t passed, which might warrant
some documentation change to encourage users to not use NULL for this
argument.
This has been tested on Sway.
Fixes#2202.
This uses the idle-inhibit protocol from wayland-protocols, to attach an
inhibitor to the GdkSurface. The inhibit function can be called as many
times as the user wants, but the uninhibit function MUST be called as
many times to unset the idle inhibition.
This has been tested on Sway.
When this code was ported from gtk_container_get_children
to the dom api, we inadvertendly inverted the order of the
list in one place. With the dom api, we can just avoid
reversing lists altogether, so do that.
Fixes: #2928
Not all compositors support _NET_WM_FRAME_DRAWN. In cases
where the compositor doesn't support _NET_WM_FRAME_DRAWN we don't
need to do all the fancy damage tracking and fence watching.
Furthermore, if the compositor doesn't support _NET_WM_FRAME_DRAWN,
it's possible that one frame will start before the previous frame has
made it through the pipeline, leading to a blown assertion.
This commit side-steps the unnecessary code and associated assertion
when _NET_WM_FRAME_DRAWN isn't supported.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/2927
The press gesture does not need to set claimed state just for n-press
tracking, it will however reset all other click gestures on each press
if the event gets propagated all the way up.
Fixes tracking of multi-press in gestures in widgets that are children
of the window handle. E.g. the headerbar listview in the "File browser"
gtk4-demo demo.
When the search entry disappears on Escape,
reset the search string to "", so we don't
end up with a filtered list and no obvious
way to remove the filtering.
Instead of an array of arrays, let's use an array of dictionaries; it's
easier to add optional keys without requiring to remember where to put
empty arrays.
The leak sanitizer causes on average 3-4 tests
to segfault during a testsuite run. Disable it
for now to see if we can get a successful
testsuite run with asan alone.
Run our testsuite under asan. We do this in a
separate build, since we need to turn off
introspection to make the build succeed.
As Michael Catanzaro pointed out, this requires a
privileged runner in order to use kernel apis.
When running the testsuite with the address sanitizer,
many of our dependencies cause it to report cause it
to report memory leaks, causing tests to fail.
Therefore, point the leak sanitizer at a list of
suppressions. The list is kept in the lsan.supp
file in git.
Add libasan and libubsan to fedora-base:v20,
and build fedora:20 on top of it.
This is so we can build and run the tests with
the address and undefined behavior sanitizers.
The gtk_gesture_group() call is not a commutative operation, it
takes two gestures, maybe detaches the first one from its current
group, and adds it to the same group than the second gesture.
With the flipped argument order here, GtkRange was actually detaching
the same gesture in order to group it with a second one two times, so
the desired effect to group all 3 gestures was not achieved.
Fixes autoscroll as the drag gesture is now actually grouped with the
click one, so drag offsets can be accessed from the autoscroll
timeout.
If we create an implicit grab on a surface, leave the surface, and
release the button, we would get 2 XI_Leave events, one with mode
XINotifyNormal when the pointer leaves the surface, and another with
mode XINotifyUngrab when the button is released.
Meanwhile, the upper layers rely on crossing events being paired,
and particularly in no crossing event being sent until the implicit
grab is dismissed (either by releasing it, or via more pervasive
grabs).
Ignoring the set of XINotifyNormal events while an implicit grab
is active adapts the X11 backend to this behavior. If the grab were
released or taken away by another grab, a crossing event with one
of the other XINotify*Grab/XINotify*Ungrab will be generated.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/2879
Check correctly that the captured motion events are emitted towards the
content or one of the scrollbars, in order to have it set the expected
"over" state depending on whether the drag begins from the scrolledwindow
content or one of the scrollbars.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/2879
This signal does not work on native file choosers,
and it exposes internals of the widget that should
not be public. And it is just not very interesting.
This signal does not work on native file choosers,
and it exposes internals of the widget that should
not be public. And it is just not very interesting.
This signal does not work on native file choosers,
and it exposes internals of the widget that should
not be public. And it is just not very interesting.
Add a GtkDirectoryList:monitored property, and
keep a file monitor if it is set to TRUE. To ensure
that the list reflects reality, we reload the directory
when monitoring is turned on after the fact. This means
that turning monitoring is expensive, while turning it
off is cheap, so we default to monitoring being on.
The stack wasn't updating its visible-child when
the stack pages visible property changes. This
showed up in the inspector, when showing the details
for a list model item.
Make mime-type rules hold multiple types. Store the
content types, so we don't have to do mime-type -> content-type
conversion in the match function. Store content types for the
pixbuf-formats rule as well, so we can avoid memory allocation
in the match function altogether.
char ** arrays are null-terminated everywhere, so make sure they are in
splice(), too.
Also fix the argument to be a const char * const * like in the
constructor.
Simplify all view model APIs and always return G_TYPE_OBJECT as the
item-type for every model.
It turns out nobody uses item-type anyway.
So instead of adding lots of APIs, forcing people to think about it and
trying to figure out how to handle filter or map models that modify item
types, just having an easy life is a better approach.
All the models need to be able to deal with any type of object going
through anyway.
Verify that the selection filter changes mirror
the selection changes of the underlying model,
as expected. These tests verify the fixes in
the previous commit.
When the position is 0, we can't check for unchanged
elements below with gtk_bitset_size_in_range. And
we don't need to, either.
And be careful when translating [start,length]
intervals to [first,last] ones. Off-by-one errors
lurk everywhere.
GtkTextLayout is private now and therefore we can drop all of
the indirection through the class vtable. Instead, just call the
implementations directly and remove the unused vtable entries
for default signal handlers.
Rename the DataList object to TreeData, in preparation
for adding a ListData object for list models. While
we are touching it, modernize it a bit (drop the Private
struct, use a layout manager, etc).
Since commit 972134abe4 a frame getting
drawn has three states (with the vendor nvidia driver at least):
1. drawn by gtk waiting on the GPU
2. drawn by GPU waiting on the compositor
3. drawn by compositor
Those three states are encoded in two flags: frame_pending and
frame_still_painting.
frame_pending means step 1 is done, but step 2 and 3 are still
in progress. frame_still_painting means step 2 is still in progress.
After step 1 is finished the surface is frozen until step 3 is finished.
When the compositor notifies gtk it's done with step 3, with a
_NET_WM_FRAME_DRAWN client message, the toolkit thaws the surface to
allow the next frame to proceed.
The compositor sometimes sends gtk a _NET_WM_FRAME_DRAWN client message
between steps 1 and 2. This message should be ignored because it's not
a reply to the current frame.
Unfortunately, gtk currently assumes if it gets a _NET_WM_FRAME_DRAWN
client message while waiting for step 2 that it's actually at step 3,
and proceeds to draw a new frame while the existing frame is still
pending, leading to a blown assertion.
This commit addresses the problem by ignoring _NET_WM_FRAME_DRAWN
client messages from the compositor unless actually expecting one.
Fixes: #2902
Since commit 972134abe4 we now call
glClientWaitSync for the vendor nvidia driver, to know when a frame
is ready for the compositor to process.
If a surface is hidden while a frame is still being rendered by the GPU,
the surface will never produce the damage event the code relies on to
trigger the call to glClientWaitSync. This leaves the fence dangling,
and the next time the surface is shown, it will start a fresh frame
and blow an assertion since the fence from the last frame is still
hanging around.
This commit ensures a frame gets fully wrapped up before hiding a
surface.
This makes the inspector lock up when used with any production
size list model, and blocks access to properties of the model
itself. Instead, we'll make the model available as an object
and add a data tab for list model contents, like we already
do for tree models.
The pkg-config variables have been added in GLib 2.62.0. Let's fallback
to default names for these tools in such case (`pkg-config` still
returns a 0 return value, but with empty output for absent variables).
Some distributions are renaming Glib/GIO utilities for multi-arch
reasons so pkg-config variables have been added to find the correct name
of a tool. GTK+ should use these variables instead of searching in PATH.
See glib#1796.
Always keep the order:
- [value]
- [marks.top]
- [marks.bottom]
- trough
Which makes sense given the rendering order. Slider should be drawn
after the marks.
Makes it possible to simply remove the custom snapshot implementations
in scale and range. And Adwaita does not depend on the node order
anyway.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
