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.
words=g_strsplit("lorem ipsum dolor sit amet consectetur adipisci elit sed eiusmod tempor incidunt labore et dolore magna aliqua ut enim ad minim veniam quis nostrud exercitation ullamco laboris nisi ut aliquid ex ea commodi consequat","",-1);
<pathd="m 51 18 h 26 c 4.417969 0 8 3.582031 8 8 v 26 c 0 4.417969 -3.582031 8 -8 8 h -26 c -4.417969 0 -8 -3.582031 -8 -8 v -26 c 0 -4.417969 3.582031 -8 8 -8 z m 0 0"fill="url(#a)"/>
<pathd="m 51 12 h 26 c 4.417969 0 8 3.582031 8 8 v 26 c 0 4.417969 -3.582031 8 -8 8 h -26 c -4.417969 0 -8 -3.582031 -8 -8 v -26 c 0 -4.417969 3.582031 -8 8 -8 z m 0 0"fill="#57e389"/>
<pathd="m 76.976562 55.453125 c 1.480469 -0.855469 3.371094 -0.347656 4.226563 1.132813 l 6.742187 11.679687 c 0.855469 1.480469 0.347657 3.371094 -1.132812 4.226563 c -1.480469 0.851562 -3.371094 0.347656 -4.226562 -1.132813 l -6.742188 -11.679687 c -0.855469 -1.480469 -0.347656 -3.371094 1.132812 -4.226563 z m 0 0"fill="url(#c)"/>
<pathd="m 52.8125 55.453125 c -1.480469 -0.855469 -3.371094 -0.347656 -4.226562 1.132813 l -6.742188 11.679687 c -0.855469 1.480469 -0.347656 3.371094 1.132812 4.226563 c 1.480469 0.851562 3.371094 0.347656 4.226563 -1.132813 l 6.742187 -11.679687 c 0.855469 -1.480469 0.347657 -3.371094 -1.132812 -4.226563 z m 0 0"fill="url(#d)"/>
<pathd="m 22 74 h 26 c 4.417969 0 8 3.582031 8 8 v 26 c 0 4.417969 -3.582031 8 -8 8 h -26 c -4.417969 0 -8 -3.582031 -8 -8 v -26 c 0 -4.417969 3.582031 -8 8 -8 z m 0 0"fill="url(#e)"/>
<pathd="m 22 68 h 26 c 4.417969 0 8 3.582031 8 8 v 26 c 0 4.417969 -3.582031 8 -8 8 h -26 c -4.417969 0 -8 -3.582031 -8 -8 v -26 c 0 -4.417969 3.582031 -8 8 -8 z m 0 0"fill="#dc8add"/>
<pathd="m 80 74 h 26 c 4.417969 0 8 3.582031 8 8 v 26 c 0 4.417969 -3.582031 8 -8 8 h -26 c -4.417969 0 -8 -3.582031 -8 -8 v -26 c 0 -4.417969 3.582031 -8 8 -8 z m 0 0"fill="url(#f)"/>
<pathd="m 80 68 h 26 c 4.417969 0 8 3.582031 8 8 v 26 c 0 4.417969 -3.582031 8 -8 8 h -26 c -4.417969 0 -8 -3.582031 -8 -8 v -26 c 0 -4.417969 3.582031 -8 8 -8 z m 0 0"fill="#ffa348"/>
<pathd="m 51 18 h 26 c 4.417969 0 8 3.582031 8 8 v 26 c 0 4.417969 -3.582031 8 -8 8 h -26 c -4.417969 0 -8 -3.582031 -8 -8 v -26 c 0 -4.417969 3.582031 -8 8 -8 z m 0 0"fill="url(#a)"/>
<pathd="m 51 12 h 26 c 4.417969 0 8 3.582031 8 8 v 26 c 0 4.417969 -3.582031 8 -8 8 h -26 c -4.417969 0 -8 -3.582031 -8 -8 v -26 c 0 -4.417969 3.582031 -8 8 -8 z m 0 0"fill="#57e389"/>
<pathd="m 76.976562 55.453125 c 1.480469 -0.855469 3.371094 -0.347656 4.226563 1.132813 l 6.742187 11.679687 c 0.855469 1.480469 0.347657 3.371094 -1.132812 4.226563 c -1.480469 0.851562 -3.371094 0.347656 -4.226562 -1.132813 l -6.742188 -11.679687 c -0.855469 -1.480469 -0.347656 -3.371094 1.132812 -4.226563 z m 0 0"fill="url(#c)"/>
<pathd="m 52.8125 55.453125 c -1.480469 -0.855469 -3.371094 -0.347656 -4.226562 1.132813 l -6.742188 11.679687 c -0.855469 1.480469 -0.347656 3.371094 1.132812 4.226563 c 1.480469 0.851562 3.371094 0.347656 4.226563 -1.132813 l 6.742187 -11.679687 c 0.855469 -1.480469 0.347657 -3.371094 -1.132812 -4.226563 z m 0 0"fill="url(#d)"/>
<pathd="m 22 74 h 26 c 4.417969 0 8 3.582031 8 8 v 26 c 0 4.417969 -3.582031 8 -8 8 h -26 c -4.417969 0 -8 -3.582031 -8 -8 v -26 c 0 -4.417969 3.582031 -8 8 -8 z m 0 0"fill="url(#e)"/>
<pathd="m 22 68 h 26 c 4.417969 0 8 3.582031 8 8 v 26 c 0 4.417969 -3.582031 8 -8 8 h -26 c -4.417969 0 -8 -3.582031 -8 -8 v -26 c 0 -4.417969 3.582031 -8 8 -8 z m 0 0"fill="#dc8add"/>
<pathd="m 80 74 h 26 c 4.417969 0 8 3.582031 8 8 v 26 c 0 4.417969 -3.582031 8 -8 8 h -26 c -4.417969 0 -8 -3.582031 -8 -8 v -26 c 0 -4.417969 3.582031 -8 8 -8 z m 0 0"fill="url(#f)"/>
<pathd="m 80 68 h 26 c 4.417969 0 8 3.582031 8 8 v 26 c 0 4.417969 -3.582031 8 -8 8 h -26 c -4.417969 0 -8 -3.582031 -8 -8 v -26 c 0 -4.417969 3.582031 -8 8 -8 z m 0 0"fill="#ffa348"/>
<gclip-path="url(#n)"mask="url(#j)">
<gclip-path="url(#m)"mask="url(#k)">
<pathd="m 128 80.640625 v 47.359375 h -128 v -47.359375 z m 0 0"fill="url(#l)"/>
<pathd="m 13.308594 80.640625 l 47.355468 47.359375 h 21.214844 l -47.359375 -47.359375 z m 42.421875 0 l 47.363281 47.359375 h 21.214844 l -47.363282 -47.359375 z m 42.429687 0 l 29.839844 29.839844 v -21.210938 l -8.628906 -8.628906 z m -98.160156 7.90625 v 21.214844 l 18.238281 18.238281 h 21.214844 z m 0 0"/>
<pathd="m 51 18 h 26 c 4.417969 0 8 3.582031 8 8 v 26 c 0 4.417969 -3.582031 8 -8 8 h -26 c -4.417969 0 -8 -3.582031 -8 -8 v -26 c 0 -4.417969 3.582031 -8 8 -8 z m 0 0"fill="url(#a)"/>
<pathd="m 51 12 h 26 c 4.417969 0 8 3.582031 8 8 v 26 c 0 4.417969 -3.582031 8 -8 8 h -26 c -4.417969 0 -8 -3.582031 -8 -8 v -26 c 0 -4.417969 3.582031 -8 8 -8 z m 0 0"fill="#57e389"/>
<pathd="m 76.976562 55.453125 c 1.480469 -0.855469 3.371094 -0.347656 4.226563 1.132813 l 6.742187 11.679687 c 0.855469 1.480469 0.347657 3.371094 -1.132812 4.226563 c -1.480469 0.851562 -3.371094 0.347656 -4.226562 -1.132813 l -6.742188 -11.679687 c -0.855469 -1.480469 -0.347656 -3.371094 1.132812 -4.226563 z m 0 0"fill="url(#c)"/>
<pathd="m 52.8125 55.453125 c -1.480469 -0.855469 -3.371094 -0.347656 -4.226562 1.132813 l -6.742188 11.679687 c -0.855469 1.480469 -0.347656 3.371094 1.132812 4.226563 c 1.480469 0.851562 3.371094 0.347656 4.226563 -1.132813 l 6.742187 -11.679687 c 0.855469 -1.480469 0.347657 -3.371094 -1.132812 -4.226563 z m 0 0"fill="url(#d)"/>
<pathd="m 22 74 h 26 c 4.417969 0 8 3.582031 8 8 v 26 c 0 4.417969 -3.582031 8 -8 8 h -26 c -4.417969 0 -8 -3.582031 -8 -8 v -26 c 0 -4.417969 3.582031 -8 8 -8 z m 0 0"fill="url(#e)"/>
<pathd="m 22 68 h 26 c 4.417969 0 8 3.582031 8 8 v 26 c 0 4.417969 -3.582031 8 -8 8 h -26 c -4.417969 0 -8 -3.582031 -8 -8 v -26 c 0 -4.417969 3.582031 -8 8 -8 z m 0 0"fill="#dc8add"/>
<pathd="m 80 74 h 26 c 4.417969 0 8 3.582031 8 8 v 26 c 0 4.417969 -3.582031 8 -8 8 h -26 c -4.417969 0 -8 -3.582031 -8 -8 v -26 c 0 -4.417969 3.582031 -8 8 -8 z m 0 0"fill="url(#f)"/>
<pathd="m 80 68 h 26 c 4.417969 0 8 3.582031 8 8 v 26 c 0 4.417969 -3.582031 8 -8 8 h -26 c -4.417969 0 -8 -3.582031 -8 -8 v -26 c 0 -4.417969 3.582031 -8 8 -8 z m 0 0"fill="#ffa348"/>
<pathd="m 5.75 1 c -0.414062 0 -0.75 0.335938 -0.75 0.75 v 4.5 c 0 0.414062 0.335938 0.75 0.75 0.75 h 0.191406 l -1 2 h -3.191406 c -0.414062 0 -0.75 0.335938 -0.75 0.75 v 4.5 c 0 0.414062 0.335938 0.75 0.75 0.75 h 4.5 c 0.414062 0 0.75 -0.335938 0.75 -0.75 v -4.5 c 0 -0.414062 -0.335938 -0.75 -0.75 -0.75 h -0.191406 l 1 -2 h 1.882812 l 1 2 h -0.191406 c -0.414062 0 -0.75 0.335938 -0.75 0.75 v 4.5 c 0 0.414062 0.335938 0.75 0.75 0.75 h 4.5 c 0.414062 0 0.75 -0.335938 0.75 -0.75 v -4.5 c 0 -0.414062 -0.335938 -0.75 -0.75 -0.75 h -3.191406 l -1 -2 h 0.191406 c 0.414062 0 0.75 -0.335938 0.75 -0.75 v -4.5 c 0 -0.414062 -0.335938 -0.75 -0.75 -0.75 z m 0 0"/>
<pathd="m 29 112 c -4.433594 0 -8 -3.566406 -8 -8 v -2 c 0 4.433594 3.566406 8 8 8 h 88 c 4.433594 0 8 -3.566406 8 -8 v 2 c 0 4.433594 -3.566406 8 -8 8 z m 0 0"fill="#f6f5f4"/>
</g>
<clipPathid="t">
<rectheight="128"width="128"/>
</clipPath>
<clipPathid="u">
<rectheight="128"width="128"/>
</clipPath>
<maskid="v">
<gclip-path="url(#u)"filter="url(#g)">
<gclip-path="url(#t)">
<pathd="m 21 16 c -4.433594 0 -8 3.566406 -8 8 v 84 c 0 4.433594 3.566406 8 8 8 h 4 v -4 h 80 v 4 h 4 c 4.433594 0 8 -3.566406 8 -8 v -84 c 0 -4.433594 -3.566406 -8 -8 -8 z m 0 0"fill="url(#a)"/>
<pathd="m 21 12 h 88 c 4.417969 0 8 3.582031 8 8 v 68 c 0 4.417969 -3.582031 8 -8 8 h -88 c -4.417969 0 -8 -3.582031 -8 -8 v -68 c 0 -4.417969 3.582031 -8 8 -8 z m 0 0"fill="#deddda"/>
<pathd="m 27 28 h 74 v 10 h -74 z m 0 0"fill="url(#b)"/>
<pathd="m 27 38 h 74 v 46 h -74 z m 0 0"fill="url(#c)"/>
<pathd="m 24 33 c 0 1.65625 -1.34375 3 -3 3 s -3 -1.34375 -3 -3 s 1.34375 -3 3 -3 s 3 1.34375 3 3 z m 0 0"fill="#bf5f00"fill-opacity="0.964567"/>
<pathd="m 18 40 h 6 v 12 h -6 z m 0 0"fill="#acacac"fill-opacity="0.984252"/>
<pathd="m 18 40 h 6 v 10 h -6 z m 0 0"fill="#d1d1d1"fill-opacity="0.984252"/>
<pathd="m 37 36 h 56 v 44 h -56 z m 0 0"fill="#deddda"fill-opacity="0.984252"/>
<pathd="m 37 34 h 56 c 1.105469 0 2 0.894531 2 2 s -0.894531 2 -2 2 h -56 c -1.105469 0 -2 -0.894531 -2 -2 s 0.894531 -2 2 -2 z m 0 0"fill-opacity="0.940945"/>
<pathd="m 37 36.859375 h 56 v 36.925781 l -14.125 14.214844 h -41.875 z m 0 0"fill="#9a9996"fill-opacity="0.984252"/>
<pathd="m 37 36 h 56 v 36.925781 l -14.125 14.214844 h -41.875 z m 0 0"fill="#f6f5f4"fill-opacity="0.984252"/>
<gclip-path="url(#o)">
<gclip-path="url(#p)">
<pathd="m 79 77.386719 v 9.351562 c 0 2.464844 2 4.464844 4.464844 4.464844 h 9.351562 c 2.464844 0 4.464844 -2 4.464844 -4.464844 v -9.351562 c 0 -2.464844 -2 -4.464844 -4.464844 -4.464844 h -9.351562 c -2.464844 0 -4.464844 2 -4.464844 4.464844 z m 0 0"fill="url(#f)"/>
</g>
</g>
<pathd="m 27 100 h 76 c 1.109375 0 2 0.890625 2 2 v 10 h -80 v -10 c 0 -1.109375 0.890625 -2 2 -2 z m 0 0"fill="#5e5c64"fill-opacity="0.940945"/>
<pathd="m 27 102 h 76 c 1.109375 0 2 0.890625 2 2 v 10 h -80 v -10 c 0 -1.109375 0.890625 -2 2 -2 z m 0 0"fill="#9a9996"/>
<pathd="m 13 106 v 2 c 0 4.433594 3.566406 8 8 8 h 4 v -2 h -4 c -4.433594 0 -8 -3.566406 -8 -8 z m 104 0 c 0 4.433594 -3.566406 8 -8 8 h -4 v 2 h 4 c 4.433594 0 8 -3.566406 8 -8 z m -92 6 v 2 h 80 v -2 z m 0 0"fill="#9e9c99"fill-opacity="0.366142"/>
<pathd="m 27 38 v 46 l 6 -46 z m 0 0"fill="#7e7c77"fill-opacity="0.11811"/>
<pathd="m 24 32 c 0 1.65625 -1.34375 3 -3 3 s -3 -1.34375 -3 -3 s 1.34375 -3 3 -3 s 3 1.34375 3 3 z m 0 0"fill="#ffa348"fill-opacity="0.964567"/>
<pathd="m 89.503906 31.144531 l 10.066406 10.066407 l -41.71875 41.71875 l -10.066406 -10.066407 z m 0 0"fill="#ffa348"/>
<pathd="m 88.246094 29.886719 l 7.550781 7.550781 l -41.71875 41.71875 l -7.550781 -7.550781 z m 0 0"fill="#ff7800"/>
<pathd="m 86.789062 28.429688 l 2.515626 2.515624 l -41.71875 41.71875 l -2.515626 -2.515624 z m 0 0"fill="#ffbe6f"/>
<pathd="m 121.898438 -0.101562 c -4.855469 0.921874 -11.730469 5.152343 -18.140626 11.558593 l -16.96875 16.972657 l 12.78125 12.78125 l 16.972657 -16.972657 c 6.40625 -6.40625 10.636719 -13.28125 11.558593 -18.136719 z m 0 0"fill="url(#j)"/>
<pathd="m 110.011719 13.882812 c -2.1875 -0.398437 -5.421875 0.988282 -8.167969 3.730469 l -11.871094 11.875 l -6.6875 6.6875 c -4.800781 4.800781 -9.234375 12.007813 -9.648437 13.042969 c -0.484375 1.207031 -0.449219 2.730469 0.953125 4.136719 c 1.40625 1.40625 2.917968 1.441406 4.136718 0.953125 c 1.035157 -0.414063 8.292969 -4.984375 13.042969 -9.648438 l 2.402344 -2.398437 l 16.160156 -16.160157 c 2.742188 -2.746093 4.128907 -5.976562 3.730469 -8.167968 c -0.742188 1.390625 -1.859375 2.902344 -3.308594 4.347656 l -13.996094 13.996094 l -5.089843 -5.089844 l 13.996093 -13.996094 c 1.445313 -1.445312 2.960938 -2.566406 4.347657 -3.308594 z m 0 0"fill="url(#k)"/>
<pathd="m 95.273438 36.914062 l -2.960938 2.960938 l -2.398438 2.402344 c -4.90625 5.101562 -11.855468 10.828125 -11.855468 10.828125 c 1.011718 -0.433594 8.167968 -5.101563 12.914062 -9.769531 l 2.402344 -2.402344 l 2.960938 -2.957032 z m 0 0"fill="#62a0ea"/>
<pathd="m 87.320312 26.835938 l 13.789063 13.789062 c 0.292969 0.292969 0.292969 0.769531 0 1.0625 s -0.769531 0.292969 -1.0625 0 l -13.789063 -13.789062 c -0.292968 -0.292969 -0.292968 -0.769532 0 -1.0625 c 0.292969 -0.289063 0.769532 -0.289063 1.0625 0 z m 0 0"fill="#3584e4"/>
<pathd="m 42.421875 89.765625 c -3 3 -6.382813 4.484375 -7.554687 3.3125 c -1.171876 -1.171875 0.3125 -4.554687 3.3125 -7.554687 c 3.003906 -3.003907 6.386718 -4.488282 7.558593 -3.316407 s -0.3125 4.554688 -3.316406 7.558594 z m 0 0"fill="url(#l)"/>
<pathd="m 45.269531 70.347656 l -7.851562 12.511719 l 7.835937 7.925781 l 12.597656 -7.855468 z m -6.039062 13.171875 l 5.449219 5.449219 c 0.347656 0.347656 0.449218 0.933594 0.097656 1.160156 c -0.886719 0.570313 -2.9375 1.539063 -2.9375 1.539063 c -0.25 0.128906 -0.539063 0.164062 -0.773438 -0.066407 l -4.546875 -4.550781 c -0.234375 -0.230469 -0.207031 -0.527343 -0.066406 -0.773437 l 1.617187 -2.859375 c 0.207032 -0.363281 0.8125 -0.25 1.160157 0.101562 z m 0 0"fill="url(#m)"/>
<pathd="m 43.332031 74.777344 l 9.867188 9.867187 c 0.394531 0.390625 0.476562 0.871094 0.128906 1.066407 l -7.710937 5.253906 c -0.308594 0.210937 -0.785157 0.160156 -1.171876 -0.226563 l -6.984374 -6.988281 c -0.386719 -0.386719 -0.4375 -0.859375 -0.230469 -1.167969 l 5.234375 -7.8125 c 0.125 -0.285156 0.558594 -0.304687 0.867187 0.007813 z m 0 0"fill="url(#n)"/>
<pathd="m 21 16 c -4.433594 0 -8 3.566406 -8 8 v 84 c 0 4.433594 3.566406 8 8 8 h 4 v -4 h 80 v 4 h 4 c 4.433594 0 8 -3.566406 8 -8 v -84 c 0 -4.433594 -3.566406 -8 -8 -8 z m 0 0"fill="url(#a)"/>
<pathd="m 21 12 h 88 c 4.417969 0 8 3.582031 8 8 v 68 c 0 4.417969 -3.582031 8 -8 8 h -88 c -4.417969 0 -8 -3.582031 -8 -8 v -68 c 0 -4.417969 3.582031 -8 8 -8 z m 0 0"fill="#deddda"/>
<pathd="m 27 28 h 74 v 10 h -74 z m 0 0"fill="url(#b)"/>
<pathd="m 27 38 h 74 v 46 h -74 z m 0 0"fill="url(#c)"/>
<pathd="m 24 33 c 0 1.65625 -1.34375 3 -3 3 s -3 -1.34375 -3 -3 s 1.34375 -3 3 -3 s 3 1.34375 3 3 z m 0 0"fill="#bf5f00"fill-opacity="0.964567"/>
<gfill-opacity="0.984252">
<pathd="m 18 40 h 6 v 12 h -6 z m 0 0"fill="#acacac"/>
<pathd="m 18 40 h 6 v 10 h -6 z m 0 0"fill="#d1d1d1"/>
<pathd="m 37 36 h 56 v 44 h -56 z m 0 0"fill="#deddda"/>
</g>
<pathd="m 37 34 h 56 c 1.105469 0 2 0.894531 2 2 s -0.894531 2 -2 2 h -56 c -1.105469 0 -2 -0.894531 -2 -2 s 0.894531 -2 2 -2 z m 0 0"fill-opacity="0.940945"/>
<pathd="m 37 36.859375 h 56 v 36.925781 l -14.125 14.214844 h -41.875 z m 0 0"fill="#9a9996"fill-opacity="0.984252"/>
<pathd="m 37 36 h 56 v 36.925781 l -14.125 14.214844 h -41.875 z m 0 0"fill="#f6f5f4"fill-opacity="0.984252"/>
<gclip-path="url(#d)">
<gclip-path="url(#e)">
<pathd="m 79 77.386719 v 9.351562 c 0 2.464844 2 4.464844 4.464844 4.464844 h 9.351562 c 2.464844 0 4.464844 -2 4.464844 -4.464844 v -9.351562 c 0 -2.464844 -2 -4.464844 -4.464844 -4.464844 h -9.351562 c -2.464844 0 -4.464844 2 -4.464844 4.464844 z m 0 0"fill="url(#f)"/>
</g>
</g>
<pathd="m 27 100 h 76 c 1.109375 0 2 0.890625 2 2 v 10 h -80 v -10 c 0 -1.109375 0.890625 -2 2 -2 z m 0 0"fill="#5e5c64"fill-opacity="0.940945"/>
<pathd="m 27 102 h 76 c 1.109375 0 2 0.890625 2 2 v 10 h -80 v -10 c 0 -1.109375 0.890625 -2 2 -2 z m 0 0"fill="#9a9996"/>
<pathd="m 13 106 v 2 c 0 4.433594 3.566406 8 8 8 h 4 v -2 h -4 c -4.433594 0 -8 -3.566406 -8 -8 z m 104 0 c 0 4.433594 -3.566406 8 -8 8 h -4 v 2 h 4 c 4.433594 0 8 -3.566406 8 -8 z m -92 6 v 2 h 80 v -2 z m 0 0"fill="#9e9c99"fill-opacity="0.366142"/>
<pathd="m 27 38 v 46 l 6 -46 z m 0 0"fill="#7e7c77"fill-opacity="0.11811"/>
<pathd="m 24 32 c 0 1.65625 -1.34375 3 -3 3 s -3 -1.34375 -3 -3 s 1.34375 -3 3 -3 s 3 1.34375 3 3 z m 0 0"fill="#ffa348"fill-opacity="0.964567"/>
<pathd="m 89.503906 31.144531 l 10.066406 10.066407 l -41.71875 41.71875 l -10.066406 -10.066407 z m 0 0"fill="#ffa348"/>
<pathd="m 88.246094 29.886719 l 7.550781 7.550781 l -41.71875 41.71875 l -7.550781 -7.550781 z m 0 0"fill="#ff7800"/>
<pathd="m 86.789062 28.429688 l 2.515626 2.515624 l -41.71875 41.71875 l -2.515626 -2.515624 z m 0 0"fill="#ffbe6f"/>
<pathd="m 121.898438 -0.101562 c -4.855469 0.921874 -11.730469 5.152343 -18.140626 11.558593 l -16.96875 16.972657 l 12.78125 12.78125 l 16.972657 -16.972657 c 6.40625 -6.40625 10.636719 -13.28125 11.558593 -18.136719 z m 0 0"fill="url(#j)"/>
<pathd="m 110.011719 13.882812 c -2.1875 -0.398437 -5.421875 0.988282 -8.167969 3.730469 l -11.871094 11.875 l -6.6875 6.6875 c -4.800781 4.800781 -9.234375 12.007813 -9.648437 13.042969 c -0.484375 1.207031 -0.449219 2.730469 0.953125 4.136719 c 1.40625 1.40625 2.917968 1.441406 4.136718 0.953125 c 1.035157 -0.414063 8.292969 -4.984375 13.042969 -9.648438 l 2.402344 -2.398437 l 16.160156 -16.160157 c 2.742188 -2.746093 4.128907 -5.976562 3.730469 -8.167968 c -0.742188 1.390625 -1.859375 2.902344 -3.308594 4.347656 l -13.996094 13.996094 l -5.089843 -5.089844 l 13.996093 -13.996094 c 1.445313 -1.445312 2.960938 -2.566406 4.347657 -3.308594 z m 0 0"fill="url(#k)"/>
<pathd="m 95.273438 36.914062 l -2.960938 2.960938 l -2.398438 2.402344 c -4.90625 5.101562 -11.855468 10.828125 -11.855468 10.828125 c 1.011718 -0.433594 8.167968 -5.101563 12.914062 -9.769531 l 2.402344 -2.402344 l 2.960938 -2.957032 z m 0 0"fill="#62a0ea"/>
<pathd="m 87.320312 26.835938 l 13.789063 13.789062 c 0.292969 0.292969 0.292969 0.769531 0 1.0625 s -0.769531 0.292969 -1.0625 0 l -13.789063 -13.789062 c -0.292968 -0.292969 -0.292968 -0.769532 0 -1.0625 c 0.292969 -0.289063 0.769532 -0.289063 1.0625 0 z m 0 0"fill="#3584e4"/>
<pathd="m 42.421875 89.765625 c -3 3 -6.382813 4.484375 -7.554687 3.3125 c -1.171876 -1.171875 0.3125 -4.554687 3.3125 -7.554687 c 3.003906 -3.003907 6.386718 -4.488282 7.558593 -3.316407 s -0.3125 4.554688 -3.316406 7.558594 z m 0 0"fill="url(#l)"/>
<pathd="m 45.269531 70.347656 l -7.851562 12.511719 l 7.835937 7.925781 l 12.597656 -7.855468 z m -6.039062 13.171875 l 5.449219 5.449219 c 0.347656 0.347656 0.449218 0.933594 0.097656 1.160156 c -0.886719 0.570313 -2.9375 1.539063 -2.9375 1.539063 c -0.25 0.128906 -0.539063 0.164062 -0.773438 -0.066407 l -4.546875 -4.550781 c -0.234375 -0.230469 -0.207031 -0.527343 -0.066406 -0.773437 l 1.617187 -2.859375 c 0.207032 -0.363281 0.8125 -0.25 1.160157 0.101562 z m 0 0"fill="url(#m)"/>
<pathd="m 43.332031 74.777344 l 9.867188 9.867187 c 0.394531 0.390625 0.476562 0.871094 0.128906 1.066407 l -7.710937 5.253906 c -0.308594 0.210937 -0.785157 0.160156 -1.171876 -0.226563 l -6.984374 -6.988281 c -0.386719 -0.386719 -0.4375 -0.859375 -0.230469 -1.167969 l 5.234375 -7.8125 c 0.125 -0.285156 0.558594 -0.304687 0.867187 0.007813 z m 0 0"fill="url(#n)"/>
<gclip-path="url(#z)"mask="url(#v)">
<gclip-path="url(#y)"mask="url(#w)">
<pathd="m 128 80.640625 v 47.359375 h -128 v -47.359375 z m 0 0"fill="url(#x)"/>
<pathd="m 13.308594 80.640625 l 47.355468 47.359375 h 21.214844 l -47.359375 -47.359375 z m 42.421875 0 l 47.363281 47.359375 h 21.214844 l -47.363282 -47.359375 z m 42.429687 0 l 29.839844 29.839844 v -21.210938 l -8.628906 -8.628906 z m -98.160156 7.90625 v 21.214844 l 18.238281 18.238281 h 21.214844 z m 0 0"/>
<pathd="m 21 16 c -4.433594 0 -8 3.566406 -8 8 v 84 c 0 4.433594 3.566406 8 8 8 h 4 v -4 h 80 v 4 h 4 c 4.433594 0 8 -3.566406 8 -8 v -84 c 0 -4.433594 -3.566406 -8 -8 -8 z m 0 0"fill="url(#a)"/>
<pathd="m 21 12 h 88 c 4.417969 0 8 3.582031 8 8 v 68 c 0 4.417969 -3.582031 8 -8 8 h -88 c -4.417969 0 -8 -3.582031 -8 -8 v -68 c 0 -4.417969 3.582031 -8 8 -8 z m 0 0"fill="#deddda"/>
<pathd="m 27 28 h 74 v 10 h -74 z m 0 0"fill="url(#b)"/>
<pathd="m 27 38 h 74 v 46 h -74 z m 0 0"fill="url(#c)"/>
<pathd="m 24 33 c 0 1.65625 -1.34375 3 -3 3 s -3 -1.34375 -3 -3 s 1.34375 -3 3 -3 s 3 1.34375 3 3 z m 0 0"fill="#bf5f00"fill-opacity="0.964567"/>
<gfill-opacity="0.984252">
<pathd="m 18 40 h 6 v 12 h -6 z m 0 0"fill="#acacac"/>
<pathd="m 18 40 h 6 v 10 h -6 z m 0 0"fill="#d1d1d1"/>
<pathd="m 37 36 h 56 v 44 h -56 z m 0 0"fill="#deddda"/>
</g>
<pathd="m 37 34 h 56 c 1.105469 0 2 0.894531 2 2 s -0.894531 2 -2 2 h -56 c -1.105469 0 -2 -0.894531 -2 -2 s 0.894531 -2 2 -2 z m 0 0"fill-opacity="0.940945"/>
<pathd="m 37 36.859375 h 56 v 36.925781 l -14.125 14.214844 h -41.875 z m 0 0"fill="#9a9996"fill-opacity="0.984252"/>
<pathd="m 37 36 h 56 v 36.925781 l -14.125 14.214844 h -41.875 z m 0 0"fill="#f6f5f4"fill-opacity="0.984252"/>
<gclip-path="url(#d)">
<gclip-path="url(#e)">
<pathd="m 79 77.386719 v 9.351562 c 0 2.464844 2 4.464844 4.464844 4.464844 h 9.351562 c 2.464844 0 4.464844 -2 4.464844 -4.464844 v -9.351562 c 0 -2.464844 -2 -4.464844 -4.464844 -4.464844 h -9.351562 c -2.464844 0 -4.464844 2 -4.464844 4.464844 z m 0 0"fill="url(#f)"/>
</g>
</g>
<pathd="m 27 100 h 76 c 1.109375 0 2 0.890625 2 2 v 10 h -80 v -10 c 0 -1.109375 0.890625 -2 2 -2 z m 0 0"fill="#5e5c64"fill-opacity="0.940945"/>
<pathd="m 27 102 h 76 c 1.109375 0 2 0.890625 2 2 v 10 h -80 v -10 c 0 -1.109375 0.890625 -2 2 -2 z m 0 0"fill="#9a9996"/>
<pathd="m 13 106 v 2 c 0 4.433594 3.566406 8 8 8 h 4 v -2 h -4 c -4.433594 0 -8 -3.566406 -8 -8 z m 104 0 c 0 4.433594 -3.566406 8 -8 8 h -4 v 2 h 4 c 4.433594 0 8 -3.566406 8 -8 z m -92 6 v 2 h 80 v -2 z m 0 0"fill="#9e9c99"fill-opacity="0.366142"/>
<pathd="m 27 38 v 46 l 6 -46 z m 0 0"fill="#7e7c77"fill-opacity="0.11811"/>
<pathd="m 24 32 c 0 1.65625 -1.34375 3 -3 3 s -3 -1.34375 -3 -3 s 1.34375 -3 3 -3 s 3 1.34375 3 3 z m 0 0"fill="#ffa348"fill-opacity="0.964567"/>
<pathd="m 29 112 c -4.433594 0 -8 -3.566406 -8 -8 v -2 c 0 4.433594 3.566406 8 8 8 h 88 c 4.433594 0 8 -3.566406 8 -8 v 2 c 0 4.433594 -3.566406 8 -8 8 z m 0 0"fill="#f6f5f4"/>
</g>
<pathd="m 89.503906 31.144531 l 10.066406 10.066407 l -41.71875 41.71875 l -10.066406 -10.066407 z m 0 0"fill="#ffa348"/>
<pathd="m 88.246094 29.886719 l 7.550781 7.550781 l -41.71875 41.71875 l -7.550781 -7.550781 z m 0 0"fill="#ff7800"/>
<pathd="m 86.789062 28.429688 l 2.515626 2.515624 l -41.71875 41.71875 l -2.515626 -2.515624 z m 0 0"fill="#ffbe6f"/>
<pathd="m 121.898438 -0.101562 c -4.855469 0.921874 -11.730469 5.152343 -18.140626 11.558593 l -16.96875 16.972657 l 12.78125 12.78125 l 16.972657 -16.972657 c 6.40625 -6.40625 10.636719 -13.28125 11.558593 -18.136719 z m 0 0"fill="url(#k)"/>
<pathd="m 110.011719 13.882812 c -2.1875 -0.398437 -5.421875 0.988282 -8.167969 3.730469 l -11.871094 11.875 l -6.6875 6.6875 c -4.800781 4.800781 -9.234375 12.007813 -9.648437 13.042969 c -0.484375 1.207031 -0.449219 2.730469 0.953125 4.136719 c 1.40625 1.40625 2.917968 1.441406 4.136718 0.953125 c 1.035157 -0.414063 8.292969 -4.984375 13.042969 -9.648438 l 2.402344 -2.398437 l 16.160156 -16.160157 c 2.742188 -2.746093 4.128907 -5.976562 3.730469 -8.167968 c -0.742188 1.390625 -1.859375 2.902344 -3.308594 4.347656 l -13.996094 13.996094 l -5.089843 -5.089844 l 13.996093 -13.996094 c 1.445313 -1.445312 2.960938 -2.566406 4.347657 -3.308594 z m 0 0"fill="url(#l)"/>
<pathd="m 95.273438 36.914062 l -2.960938 2.960938 l -2.398438 2.402344 c -4.90625 5.101562 -11.855468 10.828125 -11.855468 10.828125 c 1.011718 -0.433594 8.167968 -5.101563 12.914062 -9.769531 l 2.402344 -2.402344 l 2.960938 -2.957032 z m 0 0"fill="#62a0ea"/>
<pathd="m 87.320312 26.835938 l 13.789063 13.789062 c 0.292969 0.292969 0.292969 0.769531 0 1.0625 s -0.769531 0.292969 -1.0625 0 l -13.789063 -13.789062 c -0.292968 -0.292969 -0.292968 -0.769532 0 -1.0625 c 0.292969 -0.289063 0.769532 -0.289063 1.0625 0 z m 0 0"fill="#3584e4"/>
<pathd="m 42.421875 89.765625 c -3 3 -6.382813 4.484375 -7.554687 3.3125 c -1.171876 -1.171875 0.3125 -4.554687 3.3125 -7.554687 c 3.003906 -3.003907 6.386718 -4.488282 7.558593 -3.316407 s -0.3125 4.554688 -3.316406 7.558594 z m 0 0"fill="url(#m)"/>
<pathd="m 45.269531 70.347656 l -7.851562 12.511719 l 7.835937 7.925781 l 12.597656 -7.855468 z m -6.039062 13.171875 l 5.449219 5.449219 c 0.347656 0.347656 0.449218 0.933594 0.097656 1.160156 c -0.886719 0.570313 -2.9375 1.539063 -2.9375 1.539063 c -0.25 0.128906 -0.539063 0.164062 -0.773438 -0.066407 l -4.546875 -4.550781 c -0.234375 -0.230469 -0.207031 -0.527343 -0.066406 -0.773437 l 1.617187 -2.859375 c 0.207032 -0.363281 0.8125 -0.25 1.160157 0.101562 z m 0 0"fill="url(#n)"/>
<pathd="m 43.332031 74.777344 l 9.867188 9.867187 c 0.394531 0.390625 0.476562 0.871094 0.128906 1.066407 l -7.710937 5.253906 c -0.308594 0.210937 -0.785157 0.160156 -1.171876 -0.226563 l -6.984374 -6.988281 c -0.386719 -0.386719 -0.4375 -0.859375 -0.230469 -1.167969 l 5.234375 -7.8125 c 0.125 -0.285156 0.558594 -0.304687 0.867187 0.007813 z m 0 0"fill="url(#o)"/>
<pathd="m 29 112 c -4.433594 0 -8 -3.566406 -8 -8 v -2 c 0 4.433594 3.566406 8 8 8 h 88 c 4.433594 0 8 -3.566406 8 -8 v 2 c 0 4.433594 -3.566406 8 -8 8 z m 0 0"fill="#f6f5f4"/>
</g>
<gfill="#2e3436">
<pathd="m 4 2 v 2 h 5.585938 l 2 -2 z m -2 3 c -0.5 0 -1 0.5 -1 1 v 4 c 0 0.5 0.5 1 1 1 h 1 v -2 h 2 c 0 -0.265625 0.105469 -0.519531 0.292969 -0.707031 l 3.292969 -3.292969 z m 11.414062 0 l -4 4 h 3.585938 v 2 h 1 c 0.5 0 1 -0.5 1 -1 v -4 c 0 -0.5 -0.5 -1 -1 -1 z m -9.414062 5 v 5 h 8 v -5 h -3.585938 l -0.707031 0.707031 c -0.1875 0.1875 -0.441406 0.292969 -0.707031 0.292969 h -1 c -0.550781 0 -1 -0.449219 -1 -1 z m 0 0"/>
<pathd="m 6 10 h 1 l 9 -9 l -1 -1 l -9 9 z m 0 0"/>
<developer_name>Matthias Clasen and others</developer_name>
<releases>
<releaseversion="3.99.0"date="2020">
<releaseversion="3.99.0"date="2020-07-30">
<description>
<p>A new developers snapshot towards GTK 4.0.</p>
</description>
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.
