The introduction of the trough node was not properly carried
into the code constructing stepper nodes, and was causing
assertion failures there. This was only showing up on Windows,
since Adwaita and HighContrast don't have steppers.
We were not queuing a draw (and not updating the CSS node) when
the slider visibility changed. This was exposed by the Trough
button in tests/testscale.
Fix this by taking slider visibility into account when deciding
whether to queue a draw in response to adjustment changes.
We only allocate a size to the currently visible child, so we obviously
need to rerun allocation when the visible child changes.
In the case where the stack is not homogenous, we also need to queue a
resize because our size request just changed.
Using lookup_icon() and lookup_by_gicon() with a size multiplied by a
scaling factor is almost certainly going to get worse results than using
their for_scale() variants.
A GdkPixbuf has no scaling factor, so drawing directly from it can only
using a scale of 1, to avoid blurry, fuzzy icons.
You should be using gtk_render_icon_surface() anyway.
We've by now disabled and then remved all of the tests that use these
functions because they never worked properly. So let's depecate these
functions before somebody starts using them.
It looks like the param spec for interpolate-size was
copied from the line above it, which is a read only property.
There is a setter for interpolate-size, and it is implemented in
set_property().
When setting the parent of a widget, queue_resize() on the widget will
be optimized away if the widget already had a resize queued.
Plus, we do not need to resize the widget as its size request is not
going to change.
This makes sure that hidden widgets always have priv->alloc_needed set
on them.
The constructor sets that flag, so we want to have it back when we
revert to this state.
This fixes GtkWindow skipping a size_allocate() when reshowing a
previously hidden window and thereby not updating its allocation and
clip. And that in turn would lead to draws not happening and us beig
left with a black window.
There was still style context saving in the draw function,
and the CSS node was not always properly updated and positioned.
Fix these things, and use the same CSS node for the arrow
drawing as well.
Similar to buttons-in-toolbars, it can make sense for listbox rows
to not take away the focus from the main application view, for
instance when used for navigation. Support this by taking the newly
added GtkWidget:focus-on-click property into account.
https://bugzilla.gnome.org/show_bug.cgi?id=757269
The differences between the existing properties and the newly added
GtkWidget:focus-on-click property are minimal (different owner_type
in GParamSpec), so it is extremely unlikely that dropping the former
would break anything.
https://bugzilla.gnome.org/show_bug.cgi?id=757269
There are currently three widget that implement such a property, and
there are other widgets for which the behavior can make sense. It
seems like a good time to add the property to GtkWidget itself so
subclasses can choose to respect it without adding their own property.
https://bugzilla.gnome.org/show_bug.cgi?id=757269
The list of popovers will specify the stacking order, a
_gtk_window_raise_popover() private call has been added so popover
widgets can request being on top.
Also, the stacking on popovers is ensured on gtk_window_size_allocate(),
after the size/stacking changes on the child widget have finished, this
will ensure popovers are kept on top of window contents.
https://bugzilla.gnome.org/show_bug.cgi?id=756670
Previous commit 305b34a "GtkWindow: fix move/get position with CSD"
introduced a regression because some windows presumably use shadows but
actually don't, resulting in a negative offset being wrongly applied.
Problem is that get_shadow_width() would return non-zero shadows even
for windows that have no shadow, thus causing the negative offset.
Fix the logic in get_shadow_width() and gtk_window_should_use_csd() so
that get_shadow_width() returns accurate values.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=756618
Use the element name menuitem for GtkMenuItem, GtkCheckMenuItem
and GtkRadioMenuItem. GtkSeparatorMenuItem gets the name separator.
Add a subnode with name arrow if a submenu is attached.
Give the radio and check menu items a subnode with name check or
radio.
Use the element name menu for the main node, and use two subnodes
with name arrow and style classes .top and .bottom for the arrows
of scrolling menus.
GtkMenu and GtkMenuBar, the two implementations of GtkMenuShell in GTK,
already draw it.
Furthermore, rendering a background here will overdraw any rendering
that the subclass will do, such as arrows for scrolling menus.
This is kind of a hack the way it's implemented, but it's necessary
for performance to ignore transient nodes as they get created all the
time (via gtk_style_context_save()) and invalidate the whole treeview.
And that causes resizes and redrawing of the treeview and performance of
the inspector would go down the drain now that we display a larger part
of the node tree.
Use combobox as the element name for the main CSS nodes of
GtkComboBox and GtkComboBoxText. Add the .combo style class
to the button and entry. in a GtkComboBox or GtkComboBoxText.
Unfortunately, GtkFileChooserButton is different from the other
pickers in that it is not a button, but rather has a button.
We ignore the difference for styling purposes, and just add
a .file style class to the button.
When the CSS style of a node changes, we want to display the new values
in the inspector.
This for example allows to see how styles update on hover or during
animations.
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.
