When trying to drag, we currently the position of the first motion
event to determine where the drag came from. This might be alright
in the case of the old animation, but the data will be inaccurate
if the user has moved the pointer quite a bit since pressing the
cursor to start dragging. While we could monkey patch the GdkEvent
at the widget layer, this is unintuitive and strange.
Add a new API that takes a set of pointer coordinates describing
the origin of the drag. Additionally, adapt most widgets to use
it and use it with correct coordinates.
https://bugzilla.gnome.org/show_bug.cgi?id=705605
The cell out argument to gtk_icon_view_get_cursor is a pass-through
for gtk_cell_area_get_focus_cell which is transfer none. Without
this explicit annotation, transfer full is defaulted and introspection
bindings will assume ownership of the GtkIconViews reference to the
cell, causing crashes. Additionally add explicit transfer full to
the path parameter because it is expected the caller will free the
returned memory.
https://bugzilla.gnome.org/show_bug.cgi?id=704700
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
Commit da09447914 removed the call to
gtk_style_context_set_background() in favour of always rendering it with
gtk_render_background() during the draw vfunc.
This has the side effect of making the backing window always
transparent, which blocks GTK from applying some optimizations during
the paint cycle. The result is that, especially in clutter-gtk
applications, scrolling performance gets really bad.
This commit partially reverts da09447914
and changes the code so that both gtk_style_context_set_background() and
gtk_render_background() are called.
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 is needed for the SELECTION_NONE mode where nothing is ever
selected, but its also needed for CTRL-<key> keynav that moves the
focus without changing the selection.
https://bugzilla.gnome.org/show_bug.cgi?id=684984
This gets the current cell area of a particular item. Its similar
to gtk_tree_view_get_cell_area().
The code is extracted from gtk_icon_view_set_tooltip_cell which now
just calls the old code.
https://bugzilla.gnome.org/show_bug.cgi?id=678418
If the icon view is empty, we cannot get a reasonable size request from
the cell renderers. So all values we would compute are pretty much
useless.
So we special case it.
This also gets rid of a bunch of crashers from div-by-0 in corner cases.
https://bugzilla.gnome.org/show_bug.cgi?id=677809
This is useful for 2 reasons:
(1) Items actually exist and are clickable
(2) Size computations don't divide by 0
I've not seen problems with this in the wild (mostly because
item-padding defaults to non-0), but noticed this while fixing other
bugs.
Minimum size is necessary so you can see the item. If we can't get that
we need to scroll.
Natural as the maximum is used so that the spacing between items doesn't
increase when resizing the iconview, but empty space is added to the
right/bottom instead.
https://bugzilla.gnome.org/show_bug.cgi?id=677809
While working on the "iconview: Don't shrink items" patch I noticed that
gtk_icon_view_compute_n_items_for_size modifies the natural and minimum
item sizes it got from gtk_icon_view_get_preferred_item_size when
calculating the max number of items which will fit, but later on it
checks against these sizes when calculating the item_size, and these
checks expect these values to be unmodified.
This patch fixes this by modifying the natural and minimum values in
advance and doing all computations with modified values.
https://bugzilla.gnome.org/show_bug.cgi?id=677809
The previous code assumed that the width was always enough for more than
one column, which is obviously not correct when a number of columns is
hardcoded.
With this patch, it will now always check that the width is enough and
otherwise cause scrolling.
https://bugzilla.gnome.org/show_bug.cgi?id=677809
Code was using different places to compute the icon size when layouting
and when doing size requests. This resulted in non-matching behavior in
obscure cases. And that lead to iconviews that were too small.
This ensures that items stay left-aligned instead of slowly expanding into
empty space when widening the iconview. It's also what the iconview did
pre-refactoring.
Note that for cases where natural width != minimum width, the cells
might still expand and shrink back.
