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.
In particular, it will NULL-ified the current global context if this is
the finalized one, avoiding dangling invalid pointers.
Would have been a cherry-pick from branch gtk-3-24 of commit
b592ded80a, but files moved.
Add a Help item to the gear menu that opens the
node-format.md file in a new window. This could
be improved if we could parse markdown and apply
tags, similar to how we can load pango markup.
One of the widget-factory focus tests is flaky in ci,
perhaps due to font changes causing size computations
to go slightly differently.
Drop this for now.
Include docstrings and format the list of supported
values better.
Also, add the same warning we have for GTK_DEBUG when
the environment variable is ignored.
Even if `gtk_expression_watch()` will do the same, we're calling public
API, so we should perform a check at the point of use, to ensure that
warnings are easily debuggable.
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.
Use GTK_DEBUG=builder-objects to make GtkBuilder warn
if a named object from a ui files doesn't get claimed
by gtk_builder_get_object(). This is useful for finding
dead wood in .ui files.
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.
Take ordering of cursor_position and selection_bound
into account when copying text to the clipboard, and
ensure that both orders work the same.
Fixes: #2898
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 entry to
be selected, unexpected things happen, since the action
applies to the current selection.
Fixes: #2869
This reverts commit 67c2665028.
The splicing we do here has the important side-effect
of shifting the preedit attributes to the right position.
Without it, we end up always underlining the first chars
in the entry, regardless where the preedit happens.
This makes sure that we do actual key input right
in the middle between all the capture and bubble
event controllers, and are not dependent on the
ordering of those controllers.
The bug that triggered this change was that the
shortcut for activation (Enter) was getting triggered
before the key input, causing Ctrl-Shift-u hex
to stop working, since it never received the enter
to commit the sequence.
The gesture should claim the sequence after triggering uncancellable
actions, like pasting, showing a menu or selecting words/lines. A
single first button press initiating a drag does not trigger
anything yet, so it should avoid claiming the sequence.
The gesture should be accepted whenever it triggers uncancellable
actions in the widget. This means it should be accepted if the
click does result in toggling the switch.
This leaves the pan gesture room to handle dragging the handle.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/2895
... and do the right things:
nothing: selection = rubberband
ctrl: selection = selection OR rubberband
shift: selection = selection AND (NOT rubberband)
ctrl+shift: selection = selection XOR rubberband
(not sure this one makes sense, but toggling is fun)
Instead of storing the active items as we go, compute the affected items
whenever the rubberband changes and in particular when the rubberband
ends.
That way, the rubberband is guaranteed to select a rectangle even
after scrolling very far.
This is achieved by having a get_items_in_rect() vfunc that selects all
the items in the rubberbanded rectangle and returns them as a bitset.
The rubberband is now handled on the list coordinate system.
When starting the rubberband, we track the item under the pointer and
follow it when it is moving.
This may lead to the rubberband start position changing position and
while this may be confusing, it alerts users to the fact that something
crazy is going on.
In particular, track which items remain in ::items-changed
signal emissions.
But the main use case is sorting, which causes items-changed(0, n, n)
to be emitted.
We only want to send grab-notify to widgets that might have been
interacting with devices via events. Instead of going through all
widgets in all toplevels, we have the window/pointer focus information,
so we can just traverse the widget stacks for every involved foci.
Move away from grab_notify, and use the set_child_focus() vfunc to track
child widgets being set the keyboard focus. This is not 1:1, but seems
good enough at the moment.
Fix various issues that prevented inline completion
and inline selection from working reliably. We were
passing byte counts to gtk_editable_select_region in
one place, but that function expects char counts.
We were listening for GtkEditable::insert-text on
the GtkText widget, but that does not emit those signals,
so listen for GtkEntryBuffer::inserted-text instead.
Finally, we were not clearing the stored completion_prefix
enough, leading to situations where the stored prefix
does not match the text in the entry anymore.
In 99.9% of all cases, these are just NULL, NULL.
So just do away with these arguments, people can
use the setters for the rare cases where they want
the scrolled window to use a different adjustment.
While it's worth thinking about bringing the "windows can be dragged
with open popovers" behavior back, this does not kick in anymore, nor
should be the way to handle this given all the autoclose surface
semantic changes.
This kind of transient state sets the expectative that events update
devices, while it's more accurate to say that devices generate events.
It does not make to expose this function anymore.
This got stuck in ancient times when widgets were windowed, so the devices
in a window to know the devices in that widget would pan out. We do only
want here the devices that are inside the widget, not spread over the
surface, so rewrite this helper function to poke the toplevel foci, and
look they are contained inside the widget.
Crossing events are now detached from widget state, all tricky consequences
from getting multiple crossing events are now somewhat moot. Resort to sending
all generated crossing events, and drop this barely (ever?) used API.
When a gesture (group) claims a sequence, all other gesture groups
in the same widget should get cancelled. Not just previously claimed
ones, that shouldn't happen actually.
This is a list model holding strings, initialized
from a char **. String lists are buildable as well,
and that replaces the buildable support in GktDropDowns.
These sources are using GtkListStore apis,
but were replying on indirect includes to
get the header. Make this explicit, to prepare
for GtkEntryCompletion losing its tree view
dependencies.
Commit a0f6ff101e made sure that a
context was bound before calling glClientWaitSync, but it doesn't
check that the context shares objects with the context that created
the fence.
This commit does a little more validation before deciding the current
context is good enough.
Since commit 972134abe4 we now call
glClientWaitSync for the vendor nvidia driver, to know when a frame
is ready for the compositor to process.
glClientWaitSync can be called regardless of which context is currently
bound, but if no context is bound at all, it returns 0 without
doing anything.
This commit checks for that edge case, and ensures a context gets
made current in the event no context is already current, before calling
glClientWaitSync.
This api has not really been kept up with current
user experiences in popups, and we're better off
just dropping it and letting people do their own
popups if they need custom UI.
Use gtk_widget_prepend_controller to supersede entry keynav
while the popup is open. This fixes selecting completions
with the keyboard - the Enter keypress was ending up
triggering GtkText::activate instead of inserting the
selected completion into the entry.
Add a variant of gtk_widget_add_controller that
inserts the controller at the beginning, instead
of the end. This will be used in entry completion
to make sure the entry completion key event handling
supersedes the entry one while the popup is open.
Keep this private for now, until we determine if
it needs to be public api.
We were adding event controllers at the end, but
announcing a change at the beginning, in
gtk_widget_add_controller. Fix that by emitting
::items-changed for the position where we actually
inserted the controller.
When given a 0 timeout, glClientWaitSync is only supposed to return one
of three possible values:
- GL_ALREADY_SIGNALED - fence fired
- GL_WAIT_FAILED - there was an error
- GL_TIMEOUT_EXPIRED - fence hasn't fired yet
In addition, it can also return GL_CONDITION_SATISFIED if a non-zero
timeout is passed, and the fence fires while waiting on the timeout.
Since commit 972134abe4 we now call
glClientWaitSync (with a 0 timeout), but one user is reporting it's
returning some value that's not one of the above four.
This commit changes the g_assert to a g_error so we can see what
value is getting returned.
May help with https://gitlab.gnome.org/GNOME/gtk/-/issues/2858
According to [1], '_timezone' is already used for a global variable in the
time.h system header that is supplied by Microsoft, so using that for our
variable name when we are including time.h either directly or indirectly
will cause trouble.
This renames such variables to '_tz' to avoid that
[1]: https://docs.microsoft.com/en-us/cpp/c-runtime-library/daylight-dstbias-timezone-and-tzname
Due to an oversight, when multi filters were split into
any and every, any ended up with the listmodel and buildable
implementations, and every didn't get any.
Move the implementations up.
2020-06-21 13:10:18 -04:00
1334 changed files with 86893 additions and 56716 deletions
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);
259|GTK+ and friends|GTKtoolkit|#java bindings version 4.0.16 released: http://article.gmane.org/gmane.comp.gnome.bindings.java/1796 #gtk|1276885917|0||0|0
260|GTK+ and friends|GTKtoolkit|RT @cwiiis: MxIconTheme and MxIcon respect system's icon theme (and changes) now in #mx master :) Made possible by @thosw's XSettings work|1276883019|0||0|0
261|GTK+ and friends|GTKtoolkit|#javascript mailing list just created. Discuss its usage in GObject libraries: GTK+, Glib ... http://ur1.ca/08lwz by @jwendell #gtk|1276842639|0||0|0
262|GTK+ and friends|GTKtoolkit|Note fot Win32 users: XP theming is back in 2.90.3 . Please test. #gtk|1276829697|0||0|0
262|GTK+ and friends|GTKtoolkit|Note for Win32 users: XP theming is back in 2.90.3 . Please test. #gtk|1276829697|0||0|0
263|GTK+ and friends|GTKtoolkit|GTK+ 2.90.3 (unstable) released: http://mail.gnome.org/archives/gtk-devel-list/2010-June/msg00137.html #gtk|1276829633|0||0|0
264|GTK+ and friends|GTKtoolkit|GLib 2.25.9 (unstable) released: http://ur1.ca/08hrl WARNING: API changes in GDBus, GSettings and GApplication #gtk|1276829581|0||0|0
265|scaroo|scaroo|RT @scaroo: #SeedKit does RGBA window with css shadows and stuff : http://dl.dropbox.com/u/5746554/seedkit-does-rgba.png|1276734086|0|GTKtoolkit|0|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"/>
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.
