Use a .activatable style class on the color swatch and tie the
hover effect to it. The color editor simply removes this class
now to get an inert color swatch.
This is more flexible and lets us avoid referring to the
GtkColorEditor type in the theme.
Adapt to the new element names in the previous commit.
This also adds back a selected state which gets used
for when the focus is placed on the separator with F8,
just so this functionality is not forgotten.
The current situation is somewhat sad, with the path
label totally misaligned throughout the rows.
This is fixed by using a size group for the path labels,
so they all have the same allocated size (with the max
of 15 chars). Also, instead of hiding the eject button,
set it child-invisible, so it is hidden and yet it's size
is allocated by GtkBox.
https://bugzilla.gnome.org/show_bug.cgi?id=757303
Follow the same approach as used for the toggle button family:
Keep the button element name for button-like rendering, and
use a distinct modelbutton name otherwise, and add a subnode
for the indicator with name check or radio.
Convert GtkToggleButton and its subclasses to CSS nodes.
Keep the button element name for when we want to render
these button-like (but with .toggle, .check and .radio
style classes for differentiation).
When we want to render them with an indicator, use distinct
element names checkbutton and radiobutton, and add a subnode
for the indicator with name check or radio.
Mirror the behavior of gtk_widget_queue_resize() and always queue a
redraw. If we ever want to cause allocates without redraws we can add
gtk_widget_queue_allocate_no_redraw() then.
I had initially assumed gtk_widget_size_allocate() would take care of
queueing redraws, but it does not do that when neither size nor position
change. And that is obviously what's happening after
gtk_widget_queue_allocate().
Fixes buttons sometimes not redrawing (the record button in
widget-factory after locking it, all buttons when switching to the dark
theme).
We have to remove the page itself from the intermediate box
first, before removing the box from the notebook. Otherwise,
reffing the page to keep it alive is ineffective: the box
gets destroyed, and that destruction recurses over the page.
This fixes the problem in
https://bugzilla.gnome.org/show_bug.cgi?id=756385
This commit creates entry and button subnodes for the buttons
in GtkSpinButton. The nodes are ordered like this for horizontal
spinbutton
+ entry
+ image.left
+ image.right
+ progress
+ button.down
+ button.up
and like this for vertical ones:
spinbutton
+ button.down
+ entry
+ button.up
This arrangement requires cooperation from GtkEntry to place
the entry subnodes correctly, and some small changes in the theme.
This commit also fixes progress rendering in vertical spin buttons.
When gtk_widget_show() or gtk_widget_hide() is called, don't queue a
resize on the widget itself but on the parent.
The widget itself may already be marked as in need of a resize and
the call would be optimized out and never reach the parent.
The parent size will change though because a child widget just changed
its visibility.
Fixes a bunch of issues with menus appearing black, toolbas not hiding
in widget-factory and also various reftests.
This commit toggles the big switch. We now don't run size_allocate()
from the toplevel up anymore in cases where we don't need to.
Things might be broken in subtle ways as a result of this commit. We'll
have to find them and fix them.
Widgets that already have a resize queued don't need to walk the whole
parent chain and queue another resize. It's enough to do it once per
resize.
This also means that sizegroups cannot use the shortcut of just
invalidating the first widget in the group anymore. That widget might
already have a resize queued while others don't.
This happens way too much, so it's disabled unless GTK_DEBUG=geometry is
on.
Also, we can't detect it in the call to queue_resize() yet, only during
size_allocate(), so the warning comes after the signal emission.
... and API to set and unset it.
It is set when gtk_widget_queue_resize() is called.
It is unset when gtk_widget_get_preferred_width/height() is called.
So far it is not used.
Before this commit, a widget tree like this:
Window
AnyContainer (part of SizeGroup1)
GtkClutterEmbed
SomeWidget
when calling gtk_widget_queue_resize(SomeWidget), would invalidate
SizeGroup1, when it should have stopped at the GtkClutterEmbed (which is
a RESIZE_IMMEDIATE child).
This is so widgets can queue a rerun of their allocation logic, but
without triggering resizes everywhere.
For now, it just calls gtk_widget_queue_resize().
Ignore the geometry widget passed to gtk_window_set_geometry_hints().
Usind the widget itself was a hack that complicates the size request
machinery.
It is also incorrect in that it doesn't respect height-for-width.
Last but not least, it was only used by gnome-terminal and that
application can easily work without it.
And remove the API to set that variable.
If you want the entry to not fill its whole allocated area,
gtk_widget_set_valign (entry, GTK_ALIGN_FILL);
will give you the old behavior.
When printing a "compound selector", make sure the name and universal
selectors are printed at the beginning and class, id, etc. selectors are
printed last.
If the svg pixbuf loader is not available, we end up with criticals
from gtk_css_image_icon_theme_draw because gtk_icon_info_load_symbolic
returns NULL without setting an error.
Avoid this by propagating the load error.
Sadly, interned string properties cannot be handled generically
at all - GObject insists on inserting a strcpy in any attempt
to set a string property with generic api, destroying the
internedness of the string.
Therefore, we have to special-case GtkCssNode in the property
editor code :-(
This changes widget paths for widgets with a CSS name to return that CSS
name, now that we have added API for it.
This means that style properties are now matches using the CSS name.
Also fix the theme to use the correct name when matching style properties.
... and gtk_widget_path_iter_get_object_name(). This allows applications
that still use widget paths to use the new object names to get the
correct styling.
Mutter and webkit-gtk are examples here.
The search window of a tree view was implemented by showing without
making it visible by by positioning it outside the screen edge. This is
not possible on Wayland, so implement another method for being able to
enter text into a non-visible entry.
The new method is implemented by, before showing the window, pass the
key event directly to the IM context backing the entry. If the key
event triggered the context to commit new text or change the preedit
content, the search window is shown, and from that point the key events
are forwarded directly to the entry widget.
https://bugzilla.gnome.org/show_bug.cgi?id=756780
Take into account and compensate for the size of the client side
decorations widgets in gtk_window_move() and gtk_window_get_pos()
including gravity.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=756618
When client side decoration is used, the size passed to
gtk_window_resize() or retrieved from gtk_window_get_size() for top-
level windows also accounts for the client side decorations widgets
such as the title bar or the shadow borders.
Add up the size of these additional controls to the given size to get
the size expected.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=756618
gtk_inspector_object_tree_find_object accesses the type information
of the object, so we can't safely use it on an already decaying
object when we get a weak notify. Instead just walk the tree and
compare pointers, that is safe.
https://bugzilla.gnome.org/show_bug.cgi?id=756852
Create css nodes for icons in entries, with name image, and use
gtk_style_context_save_to_node() for them. We still set the
style classes .left and .right on them.
Use the new element names instead of the type name and style
classes.
Note that there is one problem with moving away from type names
here: it turns out that style properties only work if the selector
uses the type name.
See the previous commit for why this is necessary.
Also make gtk_widget_class_set_css_name work by looking at
the correct class for the name.
Note for future reference: GTK_WIDGET_GET_CLASS() does not
work in the instance init function.
The widget path machinery assumes that we always have types,
and without this change, it will start spewing warnings when
we start to introduce node names.
If a window is decorated, we need to draw the frame and shadow, even if
it is app-paintable - it's just nonsense to have a frame that we handle
events on, but expect the app to paint it. (We paint the titlebar in
any case.) If a client wants to handle all painting, it should use an
undecorated window.
https://bugzilla.gnome.org/show_bug.cgi?id=756886
When the $(resource_prefix)/gtk/help-overlay.ui resource exists,
load a GtkShortcutsWindow from it for each GtkApplicationWindow,
and set up a win.show-help-overlay action with accels <Primary>F1
and <Primary>? to show it.
Use CHILD1/CHILD2 instead of 0 and 1, always use the same order and
don't check for child NULL-ness, because it will be done in
gtk_paned_set_child_visible anyways.
Avoid crashes when passing an invalid location to a
gtk_text_buffer_get_iter_at_*() function.
A boolean is returned to know if @iter has been set to the exact
location.
Unit tests are added.
https://bugzilla.gnome.org/show_bug.cgi?id=735341
When the search entry is shown, the 'special' nature of
., ~ and / should not trigger the location entry, because
that interrupts the search and is likely not what the
user intended.
https://bugzilla.gnome.org/show_bug.cgi?id=756505
Disclosure triangles are usually used pointing down, however
in this case the popover spawns in the upper direction, which
makes it odd looking.
Instead of pointing always down or up, point down when not toggled and
animate a rotation when toggled.
https://bugzilla.gnome.org/show_bug.cgi?id=756568
Since the change to use GtkPlacesView we don't want to show
internal storage on the sidebar.
In our case we were checking for drive_can_eject and
drive_is_media_removable.
However for some external hard drives it's reported that they
are not ejectable nor the have removable media. So the only
attribute that they have different from internal drives is that
they can be stopped.
So check for if the drive can be stopped to decide if it is
external or internal.
On the way realized we don't need to check for the mounts associated
with the volume to know if the volume can be ejected or not. So remove
that code.
https://bugzilla.gnome.org/show_bug.cgi?id=756589
It is assumed that border.top is the same than pointing_to.height (which
equals the strong cursor position), which is not since some time ago.
The border calculation has been move on top too, it is now used in the
Y position one, and doesn't depend on anything we calculate later.
Text handles are subsurfaces on wayland, so sort of their own toplevel.
This made gtk_widget_translate_coordinates() to bail out there, resulting
in text handles being mispositioned and jumpy. To fix this, translate to
toplevel GtkWindow coordinates manually, and translate coordinates from
there.
Along the way, the coordinates reported in ::handle-dragged have been
fixed so there is no small jumps in either axis (most noticeable in the
X axis when you started dragging, and in the Y axis when moving between
lines of different heights.
Make it what it is - the enum - so that that it is sure that the hint
will fit in the field. Without this, any hint that doesn't fit in 3
bits will be truncated to the 3 least significant bits, causing
unexpected behaviour.
https://bugzilla.gnome.org/show_bug.cgi?id=756496
Otherwise the popopver will be automatically unmapped in
_gtk_popover_update_child_visible() when the X axis (coming more
or less directly from events) goes outside the textview.
we used to consider every button inside osd containers linked,
this is not true anymore, now those buttons behave normally.
This will clearly cause breakage in applications.
According to http://datatracker.ietf.org/doc/rfc2911/, The 'name'
attribute syntax is essentially the same as 'text', including the
REQUIRED support of UTF-8 except that the sequence of characters
is limited so that its encoded form MUST NOT exceed 255 (MAX) octets.
CUPS will not print jobs with names exceeding 255 characters.
https://bugzilla.gnome.org/show_bug.cgi?id=755988
Passing GTK_ICON_LOOKUP_GENERIC_FALLBACK to the icon lookup doesn't work
for GIcons, so we have to make sure we use the right GThemedIcon.
Fixes image-icon-name-use-fallback reftest.
If the last tag toggle is the end iter, the function returned the wrong
tag toggle.
This resulted in some bugs where the view wasn't relayout/redrawn
correctly.
The function also always returned TRUE, probably because the return
value is used nowhere. But for consistency with
_gtk_text_btree_get_iter_at_first_toggle(), it's better to keep the
return value, and also because otherwise the function would be wrong (it
doesn't always return a tag toggle, if there is none).
https://bugzilla.gnome.org/show_bug.cgi?id=755413
_gtk_accessibility_init() only gets called if the default
display changes, but in case gdk_init() is called before gtk_init()
the default display is already set and no property notification occurs.
This can happen quite easily in pygobject where
"from gi.repository import Gdk, Gtk"
will call gdk_init() followed by gtk_init() in the Python overrides.
This fixes it by checking for a default display in all cases.
Removing pages from the assistant with gtk_widget_destroy() used
to work. It broke with the recent interposition of a box between
each page and the notebook. Fix this by cleaning up when the box
child is removed.
https://bugzilla.gnome.org/show_bug.cgi?id=756042
In fact there were two issues:
1. GtkFlowBoxChild with "can-focus"==FALSE should pass the focus
to its child immediately.
2. GtkFlowBox with "can-focus"==FALSE should cease its custom keynav
implementation and fall back to the default GtkContainer behavior
which is more natural.
Thanks to these changes the flow box can act as a better replacement
for GtkGrid and similar containers.
https://bugzilla.gnome.org/show_bug.cgi?id=753371
Move focus to list when search results appear to make it
possible to select the first search result by just hitting
Enter. To keep this from interfering with keynav, we need
to make sure that we still handle Escape to search. And when
search comes up empty, we need to move the focus back to the
entry.
https://bugzilla.gnome.org/show_bug.cgi?id=755926
The stack calls gtk_widget_grab_focus on the last focus widget,
which selects the text in the entry, so we need to make sure to
move the focus there first to keep that from happening.
https://bugzilla.gnome.org/show_bug.cgi?id=755931
Once a window is maximized/fullscreen, resize increments should be
ignored otherwise the window may appear smaller than the screen size.
That also applies to configure requests as well.
https://bugzilla.gnome.org/show_bug.cgi?id=751368
We were calling gtk_container_should_propagate_draw
twice for each child. We can avoid this by splitting
out an gtk_container_propagate_draw_internal function.
Almost all callers of _gtk_widget_draw already did their own
cairo_save/restore, so drop the save/restore calls inside
_gtk_widget_draw and instead fix the last caller, gtk_widget_draw,
to do the same.
Call gtk_popover_update_position instead which will pick up the new
transition_diff value and pass it on to
_gtk_window_set_popover_position, which in turn will move the window
correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=755435
Check whether the given popover even changed size in
_gtk_window_set_popover_position. If not, just move its GdkWindow
without calling gtk_widget_queue_resize. Using popover_get_rect here is
still relatively costly, but popover_size_allocate would be doing that
anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=755435
We can use gdk_window_peek_children here, instead of copying
the list. Note that we preserve the bottom-to-top ordering by
iterating the list from the end.
gdk_window_get_children_with_user_data was doing a list
reversal while filtering the list.
The string we were using is the representation of the internal text
in the popover entry. However that can be freed before setting the
bookmark label, if i.e. the row is destroyed and therefore the popover
as well.
To avoid that, duplicate the label in a local variable.
One of the consequences is that for those people using development version
we migth screwed its bookmarks file, since the bookmark manager wrote
garbage from the already freed label.
https://bugzilla.gnome.org/show_bug.cgi?id=755215
We are passing widget coordinates to gtk_text_view_window_to_buffer_coords()
which expects coordinates to be relative to the text window in this case.
This may result in drop coordinates being displaced if the side windows to
the top/left sides are visible and taking space, so the DnD indicator will
point to the wrong position.
This can be seen on gnome-builder and gedit when displaying line numbers.
The row and rename popovers are always relative_to a row.
We also keep a pointer to them so we can interact with them in
callbacks.
However, if the row is destroyed its associated popovers will be
destroyed as well as relative_to destroyes and frees memory of its
associated widget when its relative_to widget is destroyed.
If we, for example, update the places while the popover is shown we are
going to access and invalid widget on the next time.
To avoid that, connect to the destroy signal of the popovers and clean
the sidebar pointers when that happens.
https://bugzilla.gnome.org/show_bug.cgi?id=755444
The patch did not check for Visual Studio 2008 correctly, plus it
would break the build on later Visual Studio versions, as it should
be __popcnt(), not __popcount(). Fix that.
The popcount builtin was added in GCC after version 4.2 (which is what
some *BSDs are using), which means we need to be more specific when
using it than just asking for GCC.
While we're at it, we can improve the compiler detection, and use a
builtin popcount on Clang ≥ 3.1 and MSVC 2008.
https://bugzilla.gnome.org/show_bug.cgi?id=755455
Instead of handling the horizontal and vertical peers separately
(and often, duplicatively), collect all peers in one go. At the
same time, avoid creating and destroying hash tables more often
than necessary.
At the time we populate the model "initially" in constructed(),
it has already been filled and cleared a couple of times (we do
that every time one of the construct properties gets set). So
we can't assume that the model is empty, and have to clear it
first. Otherwise, we add duplicates to the list.
https://bugzilla.gnome.org/show_bug.cgi?id=748080
The default event bubbling paths are prone to just running event controllers
even after the widget was potentially unrealized/destroyed in an event
handler callback, so bail out early if that's the case.
https://bugzilla.gnome.org/show_bug.cgi?id=755352
To GtkGesture machinery, if an event triggers a controller/gesture signal,
and gesture reset/cancellation as a result, the event has been managed
after all.
Commit e3bd895667 effectively changed the return value of the
wrapping gtk_event_controller_handle_event() function, which broke some
paths (eg. gtk_popover_button_press() wouldn't while the GTK+ grab was
active for this reason because the button press event was consumed early
on gtk_window_check_handle_wm_event()).
That patch is not too off-track given potential child widgets' behavior,
we want nonetheless to distinguish the denied vs cancelled paths here
(because GtkWindow itself relies on the GtkGesture behavior described in
the first paragraph on the begin_move/resize paths), so just reset
gestures after the event has already gone through the GtkEventController
so the return value is unaffected.
Traditionally a sequence is set to GTK_EVENT_SEQUENCE_DENIED state when
it is to be ignored, which means it is dormant, but still managed by the
gesture (accounting, "denied" sequences still make "slots" in multitouch
gesture busy, etc...).
This gesture will run for all button presses and releases in the window
though when presses happen on the "window content" region, and we can't
account for every children to be as educated as setting the proper mask
on every window, or ensuring events will be propagated as they should.
In order to cater for this, just reset the gestures, we can live without
such accounting in these specific GtkGestureSingle gestures.
https://bugzilla.gnome.org/show_bug.cgi?id=754098
Instead of using a fixed size, use a factor of the surface size. This
helps in situations where animations of surrounding widgets are used
and cause a rapid rate of surface destroy/create cycles.
It makes no sense to skip denied sequences here, the gestures are
still carrying out the accounting for these, which must be also put
to an end if we're possibly not receiving any further events from
this sequence.
https://bugzilla.gnome.org/show_bug.cgi?id=754098
At the time event_check_cancel_sequence_on_hierarchy() is called, the widget
has been already unparented. Given the widget itself is being destroyed,
cancellation on it is impending in one way or another, we still must
propagate cancellation across all parents, so retrieve it early before
possible widget destruction.
https://bugzilla.gnome.org/show_bug.cgi?id=754098
Otherwise it's attempted through a timeout, which gets cancelled early after,
and the slider disappears after a while with no mouse activity despite the
ongoing implicit grab.
Once the grab is finished, check_update_scrollbar_proximity() will be called
again on both scrollbars, and the fade out animation will be triggered as a
result.
https://bugzilla.gnome.org/show_bug.cgi?id=754745
When right-clicking in an empty folder, you should get a context
menu, not a crash. The code for positioning the popover was not
handling the eventuality of no row under the pointer. Just position
the popover right at the click location in this case.
https://bugzilla.gnome.org/show_bug.cgi?id=755021
A lot of time was spend rendering the shadows on windows with CSD, in
particular the corner pieces, since they are the largest parts. This
patch catches this particular case and caches the pre-rendered blur
masks.
This makes the shadow code go from 25% to 8% of the time when resizing
gtk3-demo.
We need to rename the projects so that when these projects are added
into an all-in-one solution file that will build the GTK+ 2/3 stack,
the names of the projects will not collide with the GTK+-2.x ones,
especially as GTK+-2.x and GTK+-3.x are done to co-exist on the same
system. This is due to the case that the MSVC projects are directly
carried over from the GTK+-2.x ones and was then updated for 3.x.
We still need to update the GUIDs of the projects, so that they won't
conflict with the GTK+-2.x ones.
Use the common automake module from the previous commit in the
Makefile.am's, which means that the Makefile.am's in gdk/ and gtk/ can be
cleaned up as a result. As a side effect, the property sheet that is used
to "install" the build results and headers can now be generated in terms of
the listing of headers to copy during 'make dist', where we can acquire
most of the list of headers to "install", so that we can largely avoid the
situation where the property sheet files are not updated in time for this,
causing missing headers when this build of GTK+ is being used.
Also use the Visual Studio Project file generation for the following
projects:
gtk3-demo
gtk3-demo-application
gtk3-icon-browser
gdk-win32
gdk-broadway
gail-util
So that the maintenace of these project files can be simplified as well.
https://bugzilla.gnome.org/show_bug.cgi?id=681965
The GtkEventController event mask is private, and set early by GtkGesture
implementations. Being this private data, there is no corresponding
property, so this code is a no-op, there is just no need to listen to
changes there.
We use to rely on grab broken events for most of the event sequence
lifetime, this breaks though on GDK_BUTTON_RELEASE/GDK_TOUCH_END, as there's
no longer a grab at that time.
For these cases (and all others where there's destroy/unrealize calls
involved during event dispatching), catch this on the late
WIDGET_REALIZED_FOR_EVENT calls on widget event handling functions.
https://bugzilla.gnome.org/show_bug.cgi?id=754098
This avoids a lot of overhead in the common case where a signal
is not connected and we're just using the class vfunc (which is true
for all in-libgtk widgets). Additionally it makes backtraces in
debuggers and profiles much much nicer to look at.
https://bugzilla.gnome.org/show_bug.cgi?id=754986
These days exposure happens only on the native windows (generally the
toplevel window) and is propagated down recursively. The expose event
is only useful for backwards compat, and in fact, for double buffered
widgets we totally ignore the event (and non-double buffering breaks
on wayland).
So, by not setting the mask we avoid emitting these events and then
later ignoring them.
We still keep it on eventbox, fixed and layout as these are used
in weird ways that want backwards compat.
It turns out that xgettext does not understand translatable="1",
so don't make gtk-builder-tool produce this, even though
GtkBuilder can parse it just fine.
https://bugzilla.gnome.org/show_bug.cgi?id=754928
This changes textview to share the style context with the pixelcache.
Doing so allows pixel cache to optimize the surface creation and use
a CAIRO_CONTENT_COLOR instead of CAIRO_CONTENT_COLOR_ALPHA when
appropriate.
https://bugzilla.gnome.org/show_bug.cgi?id=754658
We can take a fast path if the background for a widget is opaque by using
a CAIRO_CONTENT_COLOR instead of a CAIRO_CONTENT_COLOR_ALPHA surface. Most
blit'ing backends have a fast path for this, including Pixman and Quartz.
https://bugzilla.gnome.org/show_bug.cgi?id=754658
This new private API, _gtk_style_context_is_background_opaque(), is meant to
be used by internal Gtk+ wigets to optimize fast paths for cases where
applicable. One such use would be to use a CAIRO_CONTENT_COLOR surface
instead of CAIRO_CONTENT_COLOR_ALPHA.
https://bugzilla.gnome.org/show_bug.cgi?id=754658
Merge it into GtkWidgetPrivate. In my measurements, about half
of all widgets have a non-default auxinfo struct, and we use this
information in size allocation, so it is nice to avoid the gdata
overhead.
We only use widget paths for a few widgets nowadays (notebook,
treeview, pathbar, combobox), so we can save some space by
not having this field in GtkWidgetPrivate.
The hash table is only accessed at creation and destruction time,
and many widgets don't use templates at all, so no need to have
this permanently occupying space.
This reverts commit 3eacfa88f2.
Apart from the patch not being correct, we don't want to expose private
structures in header files if we can avoid it.
And this type-checking overhead is not an optimization that is even
measurable.
https://bugzilla.gnome.org/show_bug.cgi?id=754932
Statistics for the gtk3-demo listbox example show that the
vast majority of calls to _gtk_allocated_bitmask_resize go
from a size of 2 to 2. Don't needlessly call realloc() in
this case.
The previous code was crashing when used as the returned classes array
would have been invalid after the first deletion. So if a 2nd class
would be deleted, invalid memory might have been referenced.
This function is getting called a lot. Statistics for the gtk3-demo
listbox example show most calls with 0-4 classes. Unrolling the cases
a bit brings the instruction count in callgrind from 93M to 52M.
The same trick that was applied to _gtk_css_change_for_child in
the previous commit can be applied to _gtk_css_change_for_sibling
as well, and that is what this commit does.
With both functions converted, gtk_css_change_translate is no
longer needed and gets dropped.
The function to translate GtkCssChange enum values to the PARENT
ones is called very frequently. This patch speeds it up tremendously.
The callgrind instruction count for this function in the listbox
demo goes from 108M to 7M.
My statistics show that more than half of all calls end up
with 0 matches, so we can avoid some overhead by not allocating
an array at all in this case.
We are dealing with really short lists here.
95% are < 10 matches, and the longest I've been able to record was 19.
So just do away with the hash table and do sorted insertion in
the array directly.
The logic here is that G_ENABLE_DEBUG is for compiling out
debug spew that can be triggered at runtime with the GTK_DEBUG
environment variable, while G_ENABLE_CONSISTENCY_CHECKS is for
consistency checks that are applied unconditionally.
