| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
This can cause lagging when scrolling as it causes us to repaint
on every scroll event. This wasn't historically a great problem,
but with smooth scrolling we get a lot more events, so this
now creates visible lagging on slower machines.
|
|
|
|
|
|
|
| |
Let's see how much this breaks. But then, it also fixes things, so more
power to me!
https://bugzilla.gnome.org/show_bug.cgi?id=672173
|
|
|
|
| |
... when the iconview is not the only child in it's parent GdkWindow.
|
|
|
|
|
| |
... and make all the headers to not include gtkadjustment.h anymore. Of
course, also include it in the source files instead.
|
|
|
|
|
| |
This is so smooth scroll events are send/handled by the
parent GtkScrolledWindow if any.
|
| |
|
|
|
|
|
|
| |
The widget window is usually covered by the bin_window.
Its background color will become relevant when we introduce
kinetic scrolling with overshooting.
|
|
|
|
|
|
|
|
| |
These should use :, not ::, though signals would use ::.
See
http://developer.gnome.org/gtk-doc-manual/unstable/documenting_syntax.html.en
and
http://developer.gnome.org/gtk-doc-manual/unstable/documenting_symbols.html.en
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
You shall free with g_slice_free() what you allocate with
g_slice_new().
https://bugzilla.gnome.org/show_bug.cgi?id=665338
|
|
|
|
|
| |
Keynav on an empty iconview was causing segfaults. This
was reported in https://bugzilla.gnome.org/show_bug.cgi?id=664456
|
|
|
|
|
| |
This is necessary to query the device's coordinates when doing the
scrolling.
|
|
|
|
|
|
|
|
|
| |
As the draw handler expects the items to be laid out already, we cannot
queue a layout here to avoid a race condition with the resize that is
queued immediately after, which in turn would lead to a segfault later
in the paint_item() implementation.
https://bugzilla.gnome.org/show_bug.cgi?id=663138
|
|
|
|
| |
and use the new public modifier abstraction API instead.
|
|
|
|
|
|
| |
which are SHIFT and MOD2 on the Mac, and SHIFT and CONTROL otherwise.
Use the new define all over the place and rename variables and
members to not say "shift" or "control".
|
|
|
|
|
|
|
|
|
|
| |
Render GtkIconView cell items with the prelight state flag when they're
being mouse hovered.
This works basically in the same way it's done for GtkTreeView cells,
and e.g. GtkCellRendererPixbuf will need to have its follow-state
property to opt in to prelight rendering.
https://bugzilla.gnome.org/show_bug.cgi?id=615501
|
| |
|
|
|
|
|
|
| |
The code sets old_adj_ptr to the location containing the old weak ref,
but then wants to remove a weak ref from &view->old_hadj, causing warnings
when disposing the widget.
|
|
|
|
| |
Return 0 for the image size if we don't have a pixbuf to measure.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit introduces a new setting, gtk-visible-focus, backed
by the Gtk/VisibleFocus X setting. Its three values control how
focus rectangles are displayed.
'always' is equivalent to the traditional GTK+ behaviour of always
rendering focus rectangles.
'never' does what it says, and is intended for keyboardless
situations, e.g. tablets.
'automatic' hides focus rectangles initially, until the user
interacts with the keyboard, at which point focus rectangles
become visible.
https://bugzilla.gnome.org/show_bug.cgi?id=649567
|
| |
|
| |
|
|
|
|
|
| |
Use a PangoLayout, instead of storing a text buffer per item.
And use gtkpango api instead of implementing it all ourselves.
|
|
|
|
| |
There is only one action here, no need to pretend otherwise.
|
| |
|
|
|
|
| |
Just put the members in GtkIconViewAccessible itself.
|
|
|
|
| |
Just code rearrangement, no other changes.
|
|
|
|
| |
We no longer use the private GtkAccessible api here.
|
|
|
|
|
|
| |
Call gtk_render_frame() after gtk_render_background() there.
https://bugzilla.gnome.org/show_bug.cgi?id=654179
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
prematurely.
In this patch we adress rows_reordered() and row_deleted() callbacks
(since some icon view subclasses manipulate the connected treemodel
from _init()).
|
|
|
|
| |
from the subclass's instance structure initializer
|
|
|
|
|
| |
Indicate what kind of area will be used by default if none is
provided by the user.
|
|
|
|
|
|
|
|
|
| |
exists.
Adding these cases here to cater to icon view subclasses that want to
access icon view APIs from the instance structure initializer instead
of properly waiting for the super class to initialize and adding renderers
from the ->constructor() vfunc.
|
|
|
|
| |
This was leaking a lot of memory; just rely on atk_object_get_name.
|
| |
|
|
|
|
|
| |
This was not handled consistently, but the default handler
does useful things, so we should always chain up.
|
|
|
|
|
|
|
|
|
|
|
|
| |
I've decided that it is isn't feasible to make cell areas runtime-settable
in the time we have left before 3.0, therefore, I'm going with the
approach to allow init() functions to instantiate the default cell area
and issue a warning if a construct property is ignored.
This is not ideal, but it keeps existing icon view and combo box
subclasses working.
https://bugzilla.gnome.org/show_bug.cgi?id=639139
|
| |
|
|
|
|
|
|
| |
gtk_cell_area_[gs]et_style_detail() is no longer needed, as
the passed widget's context would already have all necessary
info.
|
|
|
|
|
| |
gcc 4.6.0 has started to warn about set-but-unused variables.
So don't do that, then.
|
| |
|