Instead, add a function gtk_image_set_icon_size() for the cases where
overriding the icon size is necessary.
Treat icon sizes the same way as pixel sizes, too. So gtk_image_clear()
no longer unsets the icon size.
Instead of returning the icon size with them, make
gtk_image_get_icon_name() and gtk_image_get_gicon() only return the icon
itself.
As a benefit, we can turn them into regular getters that return values
instead of requiring out parameters.
Instead, provide gtk_image_get_icon_size() to query the icon size.
Since setting a clip is mandatory for almost all widgets, we can as well
change the size-allocate signature to include a out_clip parameter, just
like GtkCssGadget did. And since we now always propagate baselines, we
might as well pass that one on to size-allocate.
This way we can also make sure to transform the clip returned from
size-allocate to parent-coordinates, i.e. the same coordinate space
priv->allocation is in.
The event shall no longer be "directed" to the event window, but the
widget. Getting a enter/leave event is enough now to know whether the
pointer is inside or outside the widget.
Add a new ::measure vfunc similar to GtkCssGadget's that widget
implementations have to override instead of the old get_preferred_width,
get_preferred_height, get_preferred_width_for_height,
get_preferred_height_for_width and
get_preferred_height_and_baseline_for_width.
Always have Since: annotations at the very bottom, use the correct
ClassName::signal-name/ClassName:property-name syntax, fix a few typos
in type names, wrong function names, non-existing type names, etc.
Instead of having old and new style, now have a GtkCssStyleChange opaque
object that will compute the changes you are interested in for you.
This simplifies change signal handlers quite a bit and avoids lots of
repeated computation in every signal handler.
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.
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.
The intention was that ::iconic indicates which representation is
preferred (text or icon). We fall back to the other representation
if one is missing.
Add a menu-name property and use it in a default implementation
of ::clicked to switch menus if we are inside a stack. This means
GtkModelButton is no longer entirely generic, but rather expects
to be used inside a GtkPopoverMenu. It still works in other contexts
too, of course.
Rename the "toggled" property to "active", since that is what
GtkActionHelper expects to update for check and radio actions.
Also make the property readable, since GtkActionHelper wants
to read it.
Some recent refactoring changed things so that in_button is no
longer TRUE when released() is called for touch events. As a minimal
fix, let GtkButton do more of the work by chaining up to its
pressed and released handlers, which know how to handle touch
events. This could be further improved by leaving more of the
state handling to GtkButton, like it was done for GtkToggleButton.
on:
- GtkToggleButton
- GtkCheckButton
- GtkRadioButton
- GtkModelButton
- GtkCellRendererToggle
- GtkCheckMenuItem
also update themes:
- Adwaita
- Raleigh
but not the win32 theme.
The new :checked state replaces :active for the actual checkedness of
the widgets and :active is now used exclusively while the button is being
pressed.
https://bugzilla.gnome.org/show_bug.cgi?id=733967
We were only setting the state transiently in ::draw, leading
to various drawing anomalies, such as labels not picking up
the appropriate color from BUTTON styles.
In iconic mode, model buttons will be styled like regular icon
buttons, preferring to show only the icon if one is set, falling
back to showing the label.
https://bugzilla.gnome.org/show_bug.cgi?id=727477
This is not a great name to use in themes; instead, add the
menuitem class, so themes can use .button.menuitem for styles
that are specific to menuitem-like buttons.
Similar in spirit to GtkModelMenuItem, this private GtkButton subclass
can connect to a GtkMenuTrackerItem and present itself as either a
regular button, a check button, or a radio button. Activation and
state tracking is done through the GAction that is associated with
the menu tracker item.
https://bugzilla.gnome.org/show_bug.cgi?id=723014
