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.
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.
We already know that a widget will have literally 1 node, not more.
Avoid doing the GtkSnapshot state stack dance and just append a new
transform node instead.
Seems to give me around 400 more icons in the fishbowl
It feels slightly wrong to have GtkOrientable operate on widgets, but at
least what happens when an orientable widget changes orientation should
be part of GtkWidget.
This will allow to add more state changes without accessing widget state
from the outside of gtkwidget.c.
We expect widgets to use their own derived GtkWidgetAccessible type,
these days, and given that we hard code the default accessible type of a
GtkWidget to GtkWidgetAccessible, and that we enforce the dependency of
the type passed to gtk_widget_class_set_accessible_type(), the registry
code path is clearly unused.
The tooltip handling in GtkWidget is "special":
- the string is stored inside the qdata instead of the private
instance data
- the accessors call g_object_set() and g_object_get(), and the
logic is all inside the property implementation, instead of
being the other way around
- the getters return a copy of the string
- the setters don't really notify all the involved properties
The GtkWidgetAccessible uses the (escaped) tooltip text as a source for
the accessible object description, which means it has to store the
tooltip inside the object qdata, and update its copy at construction and
property notification time.
We can simplify this whole circus by making the tooltip properties (text
and markup) more idiomatic:
- notify all side-effect properties
- return a constant string from the getter
- if tooltip-text is set:
- store the text as is
- escape the markup and store it separately for the markup getter
- if tooltip-markup is set:
- store the markup as is
- parse the markup and store it separately for the text getter
The part of the testtooltips interactive test that checks that the
getters are doing the right thing is now part of the gtk testsuite, so
we ensure we don't regress in behaviour.
If you add a widget to a parent, this will invalidate the css nodes
for parent/siblings. Afterwards, if the parent is mapped, we will
realize the new child. This calls gtk_widget_update_alpha() which
needs the css opacity, so it revalidates the css.
Thus, for each widget_add (while visible) will trigger a full
revalidation of each sibling. If you add N children to a parent that
leads to O(N^2) revalidations.
To demo this I changed gtk-demo to always double the count
(independent of the fps) and print the time it took. Here is the
results (after a bit):
Setting fishbowl count=256 took 3,4 msec
Setting fishbowl count=512 took 10,1 msec
Setting fishbowl count=1024 took 34,1 msec
Setting fishbowl count=2048 took 126,3 msec
Setting fishbowl count=4096 took 480,3 msec
Setting fishbowl count=8192 took 1892,7 msec
Setting fishbowl count=16384 took 7751,0 msec
Setting fishbowl count=32768 took 38097,7 msec
Setting fishbowl count=65536 took 191987,7 msec
To fix this we drop gtk_widget_update_alpha() and just
calculate it when needed (which is only in a single place).
It was really only necessary because we previously set
the alpha on the surface.
With this fix the above becomes:
Setting fishbowl count=256 took 1,0 msec
Setting fishbowl count=512 took 1,9 msec
Setting fishbowl count=1024 took 3,7 msec
Setting fishbowl count=2048 took 7,4 msec
Setting fishbowl count=4096 took 18,1 msec
Setting fishbowl count=8192 took 31,0 msec
Setting fishbowl count=16384 took 66,3 msec
Setting fishbowl count=32768 took 126,7 msec
Setting fishbowl count=65536 took 244,6 msec
Setting fishbowl count=131072 took 492,2 msec
Setting fishbowl count=262144 took 984,3 msec
We require a C compiler supporting C99 now. The main purpose of
these fallbacks was for MSVC. From what I can see this is now all supported
by MSVC 2015+ anyway.
The only other change this includes is to replace isnanf() with the
(type infering) C99 isnan() macro, because MSVC doesn't provide isnanf().
It's private, no APIs, we don't talk about it. But we will start using
it very soon, so we can do size request caching in columns and avoid
sizegroups...
If you run weston with the headless backend, you get a Wayland
display with no seat, which is just fine by the protocol.
gdk_display_get_default_seat() returns NULL in this case. Various
widgets assume that we always have a seat with a keyboard and a
pointer, since that is what X guarantees. Make things survive
without that, so we can run the testsuite under a headless
Wayland compositor.
Add back a property that determines whether an individual
widget will accept focus or not. :can-focus prevents the
focus from ever entering the entire widget hierarchy
below a widget, and :focusable just determines if grabbing
the focus to the widget itself will succeed.
See #2686
This signal is mainly used for bad things, and we
don't want to emit signals during layout if we can
avoid it.
If you are subclassing, you should either use a
layout manager or override the size_allocate vfunc.
If you are using a GtkDrawingArea or GtkGLArea,
use their ::resize signals to learn about size
changes.
Fixes: #2705
The a11y machinery is using signal subscription to get notified of size
changes and notify listeners in turn. This is suboptimal for a couple of
reasons:
- if something connects to the GtkWidget::size-allocate signal we need
to emit it; currently, we have an optimization in place that will
skip the signal emission if there are no handlers, and it would be
nice to go through the fast path
- the accessibility implementation is part of GTK, and should not go
through additional hoops like any out-of-tree API consumer
This is either no chagne because we know for a fact that the returned
value is a GtkNative - after all thats's the type we pass to
gtk_widget_get_ancestor().
Or it is a bug fix since casting NULL to a GtkNative using GTK_NATIVE()
is not going to work, but the API contract of gtk_widget_get_native()
explicitly allows a NULL return value.
We were having a problem where property actions were
not getting state updates because prop_actions_connect
was triggered from some instance_init function while
the widget class is not in place yet.
Delay that call until the widget is fully constructed,
so we can guarantee that we are dealing with the
correct class private struct, and see all class actions.
We already dropped this invariant in gtk_widget_verify_invariants()
because it was not true in all cases. Also, it is not really useful
these days as we extended what it means to be a "child" to also
include widgets in different toplevels.
For example, a popup in a popup button need not be realized just
because the button is in a realized window. The main invariants
we want are:
* Parent is realized before child
* Widget is realized before it is mapped
This sounds like its not a huge deal, but in fact it is a massive win
for things like menus, because when we go between menus in a menubar
each switch between two open menus involves a lot of intermingled
crossing events to different surfaces and for each of these the
tooltip window of the toplevel gets assigned to the new surface. This
shouldn't be a huge deal, as the tooltip window is not even visible,
but due to the realized invariant it get re-realized each time it gets
re-assigned.
This gives us a hook to walk the widget tree whenever a global
setting changes and do per-widget invalidations. This will
replace gtk_style_context_reset_widgets().
This was only living in gtkcontainer.c for historic
reasons. Move it closer to where it belongs, and
rename it from 'idle' to 'layout', since it is
really about the layout phase of the frame clock,
nowadays.
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
Make widgets can-focus by default, and change the semantics
of can-focus to be recursive . If it is set to FALSE, focus
can not enter the widget or its descendents at all anymore.
This commit temporarily breaks focus behavior of widgets
that did not expect to receive focus.
The only place where this should be set is when making
a widget the focus-widget of a window. We still keep
the property around in readonly form, since there are
a few places where we rely on property notification
for it.
This property doesn't carry any new information compared
to GtkWindow:focus-widget. We still keep the gtk_widget_is_focus
getter, as a convenient shortcut.
People should use shortcut controllers instead (global, capture).
A side effect of this is that GtkAccelLabel now lost its method to
magically look up accelerators to display. Somebody needs to add that
back later.
When creating shortcuts, there almost always are a trigger and an action
available for use. So make gtk_shortcut_new() take those as arguments.
Also add gtk_shortcut_new_with_arguments() so people can easily pass
those in, too.
Similar to GtkShortcutTrigger, GtkShortCutAction provides all the
different ways to activate a shortcut.
So far, these different ways are supported:
- do nothing
- Call a user-provided callback
- Call gtk_widget_activate()
- Call gtk_widget_mnemonic_activate()
- Emit an action signal
- Activate an action from the widget's action muxer
It's an outdated technology now that everybody is using GActionGroups.
If somebody wanted to support changeable shortcuts, they'd need to
reintroduce it in another way.
This adds an interface for taking care of shortcut controllers with
managed scope.
Only GtkWindow currently implements this interface, so we need to ensure
that we check if any top-level widget we reach is a shortcuts manager
before we call into it.
Allow setting the scope for a controller. The scope determines at what
point in event propagation the shortcuts will be activated.
Local scope is the usual activation, global scope means that the root
widget activates the shortcuts - ie they are activated at the very
start of event propagation (for global capture events) or the very end
(for global bubble events).
Managed scope so far is unimplemented.
This is supposed to be used to replace accelerators and mnemonics.
This is a very barebones controller that currently does nothing but
activate the binding signals. Yay.
And because we have bindings on every widget (Yes, a GtkGrid has a
keybinding - 2 in fact), we need that controller everywhere.
We need to cleanup state here immediately so that we do not potentially
access the g_class private data after it been finalized. This ensures that
the borrowed reference is dropped by the muxer.
Before this commit, adding GtkWidgetAction to class private data would
require copying the actions to each subclass as they were built or
modified. This was convenient in that it is a sort of "copy on write"
semantic.
However, due to the way that GTypeInstance works with base _init()
functions, the "g_class" pointer in GTypeInstance is updated as each
_init() function is called. That means you cannot access the subclasses
class private data, but only the parent class private data.
If instead we use a singly linked list of GtkWidgetAction, each subclass
has their own "head" yet all subclasses share the tail of the
GtkWidgetAction chain.
This creates one bit of complexity though. You need a stable way to know
which "bit" is the "enabled" bit of the action so we can track enabled
GAction state. That is easily solved by calculating the distance to the
end of the chain for a given action so that base classes sort ahead of
subclasses. Since the parent class always knows its parent's actions, the
position is stable.
A new dynamic bitarray helper also helps us avoid allocations in all the
current cases (up to 64 actions per widget) and dynamically switches to
malloc if that is to ever be exceeded.
We want access to the private data from the action muxer so we can just
move the structures to the gtkwidgetprivate.h header. Alternatively we
could create accessors, but given that we'll probably need to use this
in other areas, seems reasonable to just put it there.
People should use shortcut controllers instead (global, capture).
A side effect of this is that GtkAccelLabel now lost its method to
magically look up accelerators to display. Somebody needs to add that
back later.
Reduce the amount of special casing by using a list model
for global and managed shortcuts, too.
This way, the ListModel API will work for the ShortcutController in the
GtkShortcutManager and GtkRoot.
The only special case remaining is shortcut activation, which needs to
pass the right widget to the controller in the global/managed case.
When creating shortcuts, there almost always are a trigger and an action
available for use. So make gtk_shortcut_new() take those as arguments.
Also add gtk_shortcut_new_with_arguments() so people can easily pass
those in, too.
Similar to GtkShortcutTrigger, GtkShortCutAction provides all the
different ways to activate a shortcut.
So far, these different ways are supported:
- do nothing
- Call a user-provided callback
- Call gtk_widget_activate()
- Call gtk_widget_mnemonic_activate()
- Emit an action signal
- Activate an action from the widget's action muxer
- Activate a GAction
It's an outdated technology now that everybody is using GActionGroups.
If somebody wanted to support changeable shortcuts, they'd need to
reintroduce it in another way.
This adds an interface for taking care of shortcut controllers with
managed scope.
Only GtkWindow currently implements this interface, so we need to ensure
that we check if any top-level widget we reach is a shortcuts manager
before we call into it.
Allow setting the scope for a controller. The scope determines at what
point in event propagation the shortcuts will be activated.
Local scope is the usual activation, global scope means that the root
widget activates the shortcuts - ie they are activated at the very
start of event propagation (for global capture events) or the very end
(for global bubble events).
Managed scope so far is unimplemented.
This is supposed to be used to replace accelerators and mnemonics.
This is a very barebones controller that currently does nothing but
activate the binding signals. Yay.
And because we have bindings on every widget (Yes, a GtkGrid has a
keybinding - 2 in fact), we need that controller everywhere.
The `rename-to` annotation is used to "shadow" a symbol with another
one, which means both symbols need to exist. It can't be used to rename
a symbol to something else.
This is a huge reorganization of GtkDropTarget. I did not know how to
split this up, so it's unfortunately all one commit.
Highlights:
- Split GtkDropTarget into GtkDropTarget and GtkDropTargetAsync
GtkDropTarget is the simple one that only works with GTypes and offers
a synchronous interface.
GtkDropTargetAsync retains the full old functionality and allows
handling mime types.
- Drop events are handled differently
Instead of picking a single drop target and sending all DND events to
it, every event is sent to every drop target. The first one to handle
the event gets to call gdk_drop_status(), further handlers do not
interact with the GdkDrop.
Of course, for the ultimate GDK_DROP_STARTING event, only the first
one to accept the drop gets to handle it.
This allows stacking DND event controllers that aren't necessarily
interested in handling the event or that might decide later to drop
it.
- Port all widgets to either of those
Both have a somewhat changed API due to the new event handling.
For the ones who should use the sync version, lots of cleanup was
involved to operate on a sync API.
And in particular, only do it if the widget doesn't use ALIGN_FILL.
This avoids lots of measuring in the common case and speeds up
size_allocate() by about 25%.
And because size_allocate() is the bottleneck in the fishbowl, this also
gets ~25% more fishies.
It's the native's job to request a 1px x 1px size, not the job of
gtk_widget_size_allocate()
Also saves 10% of size_allocate() time because checking for an interface
is really expensive.
Restructure the getters for event fields to
be more targeted at particular event types.
Update all callers, and replace all direct
event struct access with getters.
As a side-effect, this drops some unused getters.
Instead of relying on gdk's antiquated crossing events,
create a new GtkCrossingData struct that contains the
actual widgets, and a new event controller vfunc that
expects this struct. This also saves us from making sense
of X's crossing modes and details, and makes for a
generally simpler api.
The ::focus-in and ::focus-out signals of GtkEventControllerKey
have been replaced by a single ::focus-change signal that
takes GtkCrossingData as an argument. All callers have
been updated.
We want to make events readonly, so stop translating
their coordinates and instead pass the translated
coordinates separately, when propagating events.
In Vala and JS at least, gtk_widget_get_css_name() and
gtk_widget_class_get_css_name() are resolved to
GtkWidget.get_css_name().
To avoid this problem, we rename the class version.
These don't take a duration, instead they call g_get_monotonic_time() to
and subtract the start time for it.
Almost all our calls are like this, and this makes the callsites clearer
and avoids inlining the clock call into the call site.
When we use if (GDK_PROFILER_IS_RUNNING) this means we get an
inlined if (FALSE) when the compiler support is not compiled in, which
gets rid of all the related code completely.
We also expand to G_UNLIKELY(gdk_profiler_is_running ()) in the supported
case which might cause somewhat better code generation.
usec is the scale of the monotonic timer which is where we get almost
all the times from. The only actual source of nsec is the opengl
GPU time (but who knows what the actual resulution of that is).
Changing this to usec allows us to get rid of " * 1000" in a *lot* of
places all over the codebase, which are ugly and confusing.
Hide the expensive GTK_IS_ROOT() checks behind the cheaper realized,
mapped, etc. checks. This way we only check for the widget being a root
if the invariant does not hold.
This gets pop_verify_invariants() from 16% to 6% when running the
scrolling benchmark in the widget-factory.
1. Rename the thing
2. Turn it from a signal to a vfunc
3. Pass the GtkCssStyleChange to it
We don't export any public API about the GtkCssStyleChange yet, it's
just a boring opaque struct.
Replace uses of gtk_css_style_get_value with direct access,
throughout the tree. We don't replace all uses, just those
where we are dealing with a fixed property. Be careful to
handle the currentColor special case for color properties.
Add GtkWidget API for adding and removing style classes, as well as
checking whether a widget has a style class applied.
Everyone has to go through GtkStyleContext for this these days but with
GtkStyleContext eventually going away, it makse sense for GtkWidget to
have API for this.
The reason for this is simply that I want to get hash functions that
have their values close together, so they can fit in a smaller range
(the goal here is 12 bits). By using GQuark, we get consecutive numbers
starting with 1 (and applications have <1000 quarks usually), whereas
interned strings can be all over the place.
As a side effect we also save 64 bytes per declaration.
Previously, we wrapped all GtkCssShadowValues in a GtkCssShadowsValue,
even if it was just one shadow. This causes an unnecessary bloat in
css values.
Make each GtkCssShadowValue able to handle multiple shadows instead, and
use gtk_css_shadow_value* API everywhere.
I was seeing crashes in gtk_widget_run_controllers.
We were accessing the controller after calling out
to application code that might remove it. Better
be safe and do the access before.
GtkBuilderScope is an interface that provides the scope that a builder
instance operates in.
It creates closures and resolves types. Language bindings are meant to
use this interface to customize the behavior of builder files, in
particular when instantiating templates.
A default implementation for C is provided via GtkBuilderCScope (to keep
with the awkward naming that glib uses for closures). It is derivable on
purpose so that languages or extensions that extend C can use it.
The reftest code in fact does derive GtkBuilderCScope for its own scope
implementation that implements looking up symbols in modules.
gtk-widget-factory was updated to use the new GtkBuilderCScope to add
its custom callback symbols.
So it does it different from gtk-demo, which uses the normal way of
exporting symbols for dlsym() and thereby makes the 2 demos test the 2
ways GtkBuilder uses for looking up symbols.
Use it as the default object for expression binds and when connecting
signals. It is intended to work kind of as the "this" object while
parsing. In fact, the term "current object" was stolen from the Java
docs and various C++ tutorials for the this pointer.
Set the current object in gtk_widget_init_template() and
GtkListItemBuilder.
This more-or-less replaces the object passed to
gtk_builder_connect_signals() in GTK3.
gtk_builder_connect_signals() is no longer necessary, because all the
setup that made it necessary to have this extra step is now done
automatically via the closure functions.
This is pretty unused and gets in the way of the next steps.
A potential side effect is that for templates the widget was passed as
the user data argument. If that turns out to be important, we have to
special case that situation.
... inside the default vfunc.
Instead, walk the children until we find the first widget that can be
focused. If no child can be focused, return FALSE from grab_focus.
The value returned by gtk_widget_get_settings() depends on the widget's
display, so watch for notify::display instead of using (un)root for
this.
Fixes the warnings seen when show a file chooser from the inspector.
