Nulling priv->button in _unset_tree_view() is asymmetrical: we create
it via init(), not _set_tree_view(), so we shouldn’t null in the latter.
Worse, doing so manifests in criticals + a SEGV easily with basic use of
testtreecolumns, removing the TVC from a TV then trying to add it to one
Finally, the wrong null-out meant dispose() failed to unref the button,
so it leaked.
https://bugzilla.gnome.org/show_bug.cgi?id=728452https://bugzilla.gnome.org/show_bug.cgi?id=788614
The overlap was caused by using pack-end for the arrow, which
causes it to be allocated from the other end. Avoid the problem
by using pack-start for both the title and the arrow, and
reordering them according to xalign.
Without this information introspection-based consumers don't realize
they can include context information, but instead think that they
receive an extra gpointer argument (which they don't know how to
handle).
https://bugzilla.gnome.org/show_bug.cgi?id=730745
When a model is sortable, but the the column is not currently used
for sorting, we want to reserve the space for showing the sort
indicator. But we currently set the icon to 'missing-image', which
is not great to show all over the place. So, just set the opacity
to 0.
If we start with a padding of -1 then it can leak out of the size
allocation request for the column when the treeview is empty. The
GtkTreeView will then collect these -1 values and add them together,
returning -n where 'n' is the number of columns.
This is usually not a problem because treeviews tend to be used with a
scrollbar and the width of the scrollbar will be added to this number
bringing it into positive territory again. On Ubuntu, with overlay
scrollbars, this is not the case, however.
https://bugzilla.gnome.org/show_bug.cgi?id=703062
Deprecate gtk_widget_push_composite_child, gtk_widget_pop_composite_child,
gtk_widget_set_composite_name, gtk_widget_get_composite_name.
This API is just bloat and was never useful, this patch deprecates
it and removes all internal calls to the composite child APIs
This replaces the previously hardcoded calls to gdk_window_set_user_data,
and also lets us track which windows are a part of a widget. Old code
should continue working as is, but new features that require the
windows may not work perfectly.
We need this for the transparent widget support to work, as we need
to specially mark the windows of child widgets.
https://bugzilla.gnome.org/show_bug.cgi?id=687842
Rewrites gtk_tree_view_column_request_width() and
gtk_tree_view_size_allocate_columns() to respect the minimum and natural
sizes that are already being returned by
gtk_cell_area_context_get_preferred_width().
The convoluted logic explained (not!) by this comment has been removed:
“Only update the expand value if the width of the widget has changed, or
the number of expand columns has changed, or if there are no expand
columns, or if we didn't have an size-allocation yet after the last
validated node.” This logic seems to have been a workaround for the
“jumping” behavior fixed in 16195ad and is no longer necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=691751
Removes the hidden “resized-width” and “use-resized-width” properties
from GtkTreeViewColumn and instead uses the “fixed-width” property to
serve the same purpose. “fixed-width”, if set, will now override the
auto-sized width (-1 is now a legal value meaning “not set”).
Additional “cleanups” in this commit:
1. When the user resizes the column the “expand” property is now also
set to FALSE, in order to prevent the column from suddenly jumping to a
different width when the window is resized.
2. The code that translated mouse movement to column sizes has been
simplified:
the change in column width is now calculated directly from the distance
the mouse cursor has traveled. Weird behavior that might have happened
previously if the position of the column changed during resizing, is now
prevented.
3. There was some lengthy logic handling the keyboard shortcuts used to
resize treeview columns, which would call gtk_widget_error_bell() once
the minimum or maximum width was reached. Instead of rewriting these
checks I simply set the “fixed-width” property to what was requested,
relying on the fact that it is already clamped between the minimum and
maximum width during size allocation.
I will greatly surprised if anyone notices the missing error bell.
https://bugzilla.gnome.org/show_bug.cgi?id=691751
This commit exposes the get_type() functions and standard
headers for accessible implementations. This makes it possible
to derive from the GTK accessible implementations without
GType magic tricks. This is necessary, because we require the
a11y type hierarchy to be parallel to the widget type hierarchy.
So, if you derive a widget and need to adjust its a11y implementation,
you have to be able to derive its accessible implementation.
This commit probably exposes more than is absolutely necessary,
it also exposes accessibles of widgets that are unlikely candidates
for deriving from.
This way, the a11y code knows if a column was reordered, added or
removed and can do the right things instead of trying to guess and
getting it wrong.
Also, this patch finalizes the changes so that only visible columns
exist to the accessibility interface.
