... so we don't bump a refcount whenever we get the initial singleton.
We want to use this function instead of
_gtk_css_style_property_get_initial_value() everywhere where we compute
values, because some initial values may depend on settings soon.
Resizes are queued via
gtk_widget_propagate_state()
=> gtk_style_context_set_state()
=> gtk_style_context_queue_invalidate()
=> gtk_style_context_validate()
=> _gtk_widget_style_context_invalidated()
so there's no need to queue an extra one.
Symbolic colors are an implementation detail of the CSS engine and have
been superceded by GtkCssColorValue. We don't want them clobbering the
public API. In particular because the only use I could find in the
public API is people using it to shade colors.
Make _gtk_style_provider_private_get_color() return a GtkCssValue (a
GtkCssColorValue to be exact) instead of GtkSymbolicColor.
With this, the symbolic color usage inside GTK is minimized.
The documentation for gtk_file_chooser_get_filenames() states that the
returned filenames are absolute paths, and uses g_file_get_path() to
construct the filename. The same function is used to construct the
filename in gtk_file_chooser_get_filename(), so it should also return
absolute paths.
https://bugzilla.gnome.org/show_bug.cgi?id=371034
When event capturing is enabled, stop propagating scroll events
at insensitive widgets, but don't handle them (don't return TRUE),
so they can bubble up again and reach their handling widgets.
Render a background with gtk_render_background() in draw() instead.
Note that we still use gtk_style_context_set_background() for the header
window.
https://bugzilla.gnome.org/show_bug.cgi?id=688744
This reverts the size_allocate removal from commit
8449e05865. That code was using
_gtk_window_set_allocation() instead of gtk_widget_set_allocation(). And
that broke glade.
We can set for_size to -1 earlier than we did. Doing so makes sure we
only cache one value (as we should in the first place). In GTK 3.6, this
worked properly, but with Previously, this check was moved further up to
avoid interacting with size groups. But after recent refactorings, size
groups are handled way earlier anyway.
... instead of GtkSizeGroupMode. Orientation is what we're interested in
after all. When we need a GtkSizeGroupMode, we can do the translation
where we need it.
Application code can set shortcut folders that are already bookmarks.
This code causes the bookmarks to be refreshed after the shortcut is
added removing any possible bookmark duplicates
https://bugzilla.gnome.org/show_bug.cgi?id=577806
Expose GtkEntry icons as child accessibles of a GtkEntry, and provide
actions to simulate clicking them. Also, refactor the a11y children test
slightly to add a test.
https://bugzilla.gnome.org/show_bug.cgi?id=686347
The bitmasks with the 31st, 32nd and 63rd bit set are added. The make up
the largest bitmasks on 32bit/64bit that can be represented without
allocating and the smallest bitmask on 32bit that must be allocated.
With the fix in 77912a65e2, another bug
got visible: booleans are 32 bits, so if the intersection between the 2
bitmasks happened in higher bits, the return value would be truncated to
FALSE.
This actually made slider handles disappear, so it was pretty visible.
If lookup->missing is empty we don't need to continue looking.
We short circuit in several places as this can happen
after iteratively makeign lookup->missing smaller.
We need to use the allocated codepath if *any* argument is
allocated, not if one arg is not allocated.
This bug caused unnecessary calls to _gtk_bitmask_is_allocated,
as well as return completely wrong result if both bitmask are
allocated.
What is this bin doing with all these crazy deltas? Company does:
<Company> that can safely be removed
<Company> in general, code that isn't obvious can either be understood
<Company> with a bit of thinking or it can be removed
<Company> if in doubt, go for the 2nd of those :)
Most GtkBin subclasses override this strange garbage anyway, so it's
not like this code is ever *run*, per se. Just make it proxy directly
to the child, and hope nothing goes wrong.
Implement get_preferred_width, get_preferred_height, and size_allocate.
This allows GtkBin subclasses to be quick and easy, without the
author doing the subclassing to have to do much work.
If the "wider" label is the smaller one, use the wider size for both
cases. This can happen when ellipsizing a single character, which is
often smaller than the ellipsizing glpyph(s).
Functions should not have a space before the opening parenthesis. So
change output like
alpha (@color, 0.5)
to
alpha(@color, 0.5)
and do the same for "shade" and "mix".
Tests have been updated accordingly.
With ellipsizing, the ellipsized text can have a smaller height than the
non-ellipsized text. So the wider text is also higher. Example:
.<big>TEXT</big>
will ellipsize to the small text.
Reported-By: Rico Tzschichholz <ricotz@t-online.de>
We must make sure to remove the weak pointer when disposing the widget
or when resetting the align widget otherwise glib will try to nullify
invalid memory.
This way we don't need a marker on GtkWidgetParivate that needs to be
unset later, so we have all our data in the same place and can avoid
problems with reentrancy and shenanigans like that.
But the main reason I wrote that is cleaner code.
With this function now available, we can do size computation in 2
ways:
(1) Compute size with size groups
(2) Compute size without size groups
And have (1) use (2) instead of setting flags on widgets. This patch
does exactly that.
With size groups now doing hfw, doing the optimization for CONSTANT_SIZE
was done too early. Size groups need to know that it's a hfw request, so
the other widgets in the size group get the correct behavior.
The label code assumed that Pango treats this as "wrap to as much space
as possible and then ellipsize all the lines", but for Pango, ellipsize
takes precedence over wrap. So do the same thing in GtkLabel.
Also updated is the reftest that checked this behavior.
We compute on-demand for size groups anyway, so we can (in theory, this
patch doesn't do that yet) get around costly cache blowing when
invalidating single widgets of a size group this way.
The current approach of using gtk_widget_get_mapped() is broken:
The usual steps taken when showing a window are:
(1) request the sizes
(2) allocate the sizes
(3) show the window in the allocated size
Showing the window with a random size between steps (1) and (2) would of
course
result in extra work and potential flickering when the widgets get
resized to
their proper sizes.
However, as GtkSizeGroup::ignore-hidden uses gtk_widget_get_mapped() to
determine visibility for a widget, the following will happen:
(1) the widget will request a 0 size
(2) the widget will be allocated a 0 size
(3) the widget will be too small when it is shown
gtk_widget_get_visible() however is set in advance. Note that toggling
visibility also causes a gtk-widget_queue_resize() call already so we
take care of changes in here automatically.
Instead of only checking the ignore_hidden flag when getting the
preferred sizes, respect it already when constructing the list of
widgets. This way, widgets don't queue resizes for groups they're
ignored in anyway.
For loops to loop over lists look nicer and actually do the right thing
with "break" and "continue" statements. So they are vastly preferred to
while loops.
This simplifies code and because sizes are cached by the widgets
themselves, it's not a large performance problem (unless people use huge
amounts of widgets in a single size group, but who does that?
