These days exposure happens only on the native windows (generally the
toplevel window) and is propagated down recursively. The expose event
is only useful for backwards compat, and in fact, for double buffered
widgets we totally ignore the event (and non-double buffering breaks
on wayland).
So, by not setting the mask we avoid emitting these events and then
later ignoring them.
We still keep it on eventbox, fixed and layout as these are used
in weird ways that want backwards compat.
Code exists in the wild that calls this function after the widget has
been destroyed (and the pixel cache released). Simply check that the
pixel cache exists to preserve the existing state.
I believe that first_column can only ever be NULL here if
last_column is NULL too, in which case we'd exited already.
But coverity doesn't see that, so add an explicit exit.
GtkTreeView has a particularly expensive drawing path. This can cause
issues when part of animated widget sequences. Caching the content while
a model is attached helps reduce the number of full redraws during
exposure greatly.
https://bugzilla.gnome.org/show_bug.cgi?id=751082
Just use the last coordinates given on XdndPosition/drag_motion() in
order to trigger scrolling.
When running on Xwayland, the pointer position is unknown at this
stage on the X11 side, so the coordinates given here are bogus.
This change avoids both roundtrips and this situation.
https://bugzilla.gnome.org/show_bug.cgi?id=749679
When a treeview is destroyed while rubberbanding is going
on, we crash because the rb tree is nuked before we want
to access it to stop the rubberbanding. To avoid this crash
end the rubberbanding early in destroy().
See
https://bugzilla.redhat.com/show_bug.cgi?id=1173904
GPUs generally have problems when you create a 35000px wide surface.
Luckily X catches this and sends a BadAlloc. Which GTK immediately
abort()s on.
Testcase included.
https://bugzilla.redhat.com/show_bug.cgi?id=1163579
This is so signal handlers have an opportunity to undo its effect by
returning GDK_EVENT_STOP on ::button-press-event, just like they used
to do pre-gestures.
https://bugzilla.gnome.org/show_bug.cgi?id=735965
Use the left border color for tree lines. This is similar to
our use of top border color for grid lines. As a side-effect,
tree lines now get recolored when they are in a selected row.
https://bugzilla.gnome.org/show_bug.cgi?id=415415
The pre-gestures code used to compare the current button press with the
previous one on !activate_on_single_click, and unset the previous event
data so ::row-activated would be emitted every 2 clicks.
So do the same with the multipress gesture and reset it after every 2nd
click to have ::row-activated emitted multiple times while manic clicking.
https://bugzilla.gnome.org/show_bug.cgi?id=735353
That gesture is meant to handle clicks on multiple buttons, so unset
the GDK_BUTTON_PRIMARY default. Also, remove unnecessary boilerplate
with the new GtkGestureSingle/GtkEventController defaults.
https://bugzilla.gnome.org/show_bug.cgi?id=734285
This check used to be present in the pre-gestures code, but was unintentionally
removed when splitting code into drag/multiclick gestures. The policy used to
be that if clicking happened on an already selected node, DnD would happen
instead of rubberband selection, so this behavior is resuscitated.
https://bugzilla.gnome.org/show_bug.cgi?id=734143
The rules-hint property has always been a fairly bad application API, as
it set some wrong expectations for the developers; deferring to the
theme makes it impossible to design application reliably, and if this is
a usability setting we should either impose this setting on every theme,
or simply drop it.
Our own default theme does not honour the zebra striping, which makes
this function even more questionable.
In practice, usability studies on zebra striping have demonstrated that
alternating colors on a list it improves readability just as much as
clear ruling between rows, or by visually differentiating the selected
row. Zebra striping improves readability (or, at least, it does not
hinder it) on static displays, like a table on paper or a document; on a
dynamic display, like an application's UI, there are different
strategies that yield similar, if not better, results.
https://bugzilla.gnome.org/show_bug.cgi?id=733312
The animated scrolling interferes with incremental validation.
As short-term solution, disable scrolling animation during
incremental validation. This is not a proper solution, but
it avoids broken behavior like scrollbars that are not reacting
to clicks. The problem was visible, e.g. in the list view
example in gtk3-demo.
The animated scrolling interferes with incremental validation.
As short-term solution, disable scrolling animation during
incremental validation. This is not a proper solution, but
it avoids broken behavior like scrollbars that are not reacting
to clicks. The problem was visible, e.g. in the list view
example in gtk3-demo.
The reparenting happening on the column header so it gets a movable
window breaks the implicit grab, so this is one situation were we
want a pointer grab, if just to replace it.
https://bugzilla.gnome.org/show_bug.cgi?id=732933
Code was expecting view coordinates, not widget ones, as we're
only dealing with horizontal displacements, just adding the
horizontal adjustment value suffices.
https://bugzilla.gnome.org/show_bug.cgi?id=732933
Regions are done in a very non-css way. They don't fit the DOM in that
they don't integrate into the CSS tree and they have very weird matching
behavior in selectors.
So I'm deprecating them now. GtkNotebook and GtkTreeview will continue
to use them and as long as they do, we can't remove the code for it.
But once those are ported it might be safe to remove the code as it will
clean up lots of places in the code by quite a bit.
The rubberband rendering code was assuming that we just have
a 1-pixel border and the rest of the rubberband is uniform.
That is not a safe assumption to make with css-styled
rubberbands, so remove it.
The code is actually prepared for that, the gesture was initially limited
to only handling GDK_BUTTON_PRIMARY because it only used to handle row
activation.
This gesture acts only on events from the bin window, and checks that
either the pressed row is draggable, or the conditions for rubberband
selection apply.
A multipress gesture takes care of autosizing on double click, and
a drag gesture is used for both column dragging/resizing (only one
can happen at a time).
Otherwise the event is possibly handled, but still propagated further anyway.
Ensure the event is consumed by claiming the current sequence on the
GtkGestureMultiPress::pressed handler.
::row-activated only used to be triggered by GDK_BUTTON_PRIMARY, so make
the multipress gesture handling this now to be only triggered by that same
button.
https://bugzilla.gnome.org/show_bug.cgi?id=731020
Mainly doing s/TARGET/BUBBLE/ on the fully ported widgets, but GtkTreeView
where the double click handler has moved to GTK_PHASE_TARGET so it runs
parallelly to the still existing event handlers.
Event controllers now auto-attach, and the GtkCapturePhase only determines
when are events dispatched, but all controllers are managed by the widget wrt
grabs.
All callers have been updated.
The propagation phase property/methods in GtkEventController are gone,
This is now set directly on the GtkWidget add/remove controller API,
which has been made private.
The only public bit now are the new functions gtk_gesture_attach() and
gtk_gesture_detach() that will use the private API underneath.
All callers have been updated.
When the adjustment changes (due to e.g. a mouse wheel scroll) we update
the prelight. The part that un-prelights the previous prelight was
broken by the the pixel cache, as it called update_prelight in the
middle of the scrolling operation, where the windows were moved
but the tree_view->priv->dy was not changed to the new value. This
caused the updates to the pixel cache to go to the wrong place.
We fix this by fully doing the scroll before we update_prelight().
https://bugzilla.gnome.org/show_bug.cgi?id=728284
GTK_TREE_VIEW_TIME_MS_PER_IDLE is currently 30 milliseconds, meaning
that validate_rows will validate rows up until all the validations have
taken over 30 msecs. So it's likely to block redrawing via the clock
frame update mechanism, as that tops at 16.66 milliseconds per frame
(1/60th of a second).
Stop validating rows if we've spent more than 3/5 of our allotted budget
for inter-frame processing, so as to avoid blocking.
In the future, we would probably want to calculate how long we would
have left until the next frame, especially if higher priority idles
and timeouts have already consumed a portion of that allotted time.
https://bugzilla.gnome.org/show_bug.cgi?id=726871
Stop ignoring various crossing events from grabs:
Enter events with type GRAB/GTK_GRAB/GTK_UNGRAB/STATE_CHANGED:
Ignoring these events was added as a workaround for synthesized
events not having the right coordinates (see bug 555109) but
now they do have the right coordinates. (see bug 704456)
Leave events with types types GTK_GRAB/GTK_UNGRAB:
Ignoring these events was added because since we were ignoring
the enter events as above, ignoring the leave events meant we
could lose the prelighted row in a grab-triggered leave/enter
pair. (See bug 653676. It's also now impossible to
reproduce the leave events that were reported in that bug as causing
problems.)
Leave events of type GRAB.
Ignoring these events was added without a ChangeLog entry in 2001,
possibly to keep the prelight from flashing when activating menus.
But ignoring these events could lead to stuck prelighting, and we don't
do it for any other widgets.
https://bugzilla.gnome.org/show_bug.cgi?id=726209
The bug this patch is fixing is that currently if you have a GtkPopover in
clicking off the popover to dismiss it on a GtkTreeView (which triggers
a synthetic enter event on the GtkTreeView) will leave the GtkTreeView
in a confused state until the user moves the mouse again.
That doesn't make sense.
And it causes issues, because when holding down the tab key, we
show/hide a lot of windows and cause a lot of map/unmap events that
stall the event pipeline.
Add documentation for GtkTreeView::move-cursor
Add links to GtkTreeModel::row-inserted and GtkTreeModel::row-deleted
in the documentation for gtk_tree_view_set_reorderable ().
https://bugzilla.gnome.org/show_bug.cgi?id=725560
gtk_tree_view_remove_column was first removing the column from
its list, then call gtk_tree_view_column_unset_tree_view, which
would then call gtk_container_remove to remove its button from
the treeview. But the treeview remove implementation relied
on the column being still in the list in order to recognize
the button as 'special', so in effect the button was never
properly removed and thus, leaked.
Fix this by callling unset_tree_view before removing the
column from the list.
https://bugzilla.gnome.org/show_bug.cgi?id=724891
Suprisingly, this bug has been there for a very long time.
I'm fixing it now because we now use a custom search entry
in the app chooser dialog, and this is causing the templates
cleanup test to fail.
The bin window's background would have to be drawn in the bin window's
size and inside the pixel cache draw function to not cause transparency
issues.
But because it's unnecessary as the view window draws the same
background, we just skip it.
https://bugzilla.gnome.org/show_bug.cgi?id=709027
Don't recurse the mainloop in _gtk_tree_view_column_start_drag().
It doesn't serve any discernible purpose, and recursing the
mainloop from the flush-events phas of the frame clock breaks
frame synchronization with mutter.
https://bugzilla.gnome.org/show_bug.cgi?id=705176
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
This invariant stopped being guaranteed when we moved the visible area
validation from a high priority idle to a tick callback.
Fixes redrawing bugs like row expanding sometimes not having any visual
effect.
Instead of storing the rect in the bin window, store the row and column
the editable belongs to and compute the rect lazily. This way, we don't
need to keep the rect up to date.
Fixes /TreeView/scrolling/new-row-mixed/path-500 test.
We register an invalidate handler on the bin window to get told
of child widget invalidations, although we manually need to discard
invalidates from the scroll operation.
Additionally we invalidate all of the pixel cache whenever
the TreeView itself is queue_draw()n to handle e.g. style (bg)
changes, or changes due to model changes causing queue_draw() in
the tree view.
We used to divide the row in thirds vertically, and use the outer thirds for GTK_TREE_VIEW_DROP_BEFORE and AFTER, respectively.
Now we use *fourths*. This is so that we get equal areas for these:
GTK_TREE_VIEW_DROP_BEFORE
GTK_TREE_VIEW_DROP_INTO_OR_BEFORE
GTK_TREE_VIEW_DROP_INTO_OR_AFTER
GTK_TREE_VIEW_DROP_AFTER
This makes hovering tree rows much more positive.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
This reverts commit 666d10ec76.
This change severely broke any treeviews without horizontal
scrollbars. Basically, ellipsization never kicks in, and instead
the treeview content just extends outside the visible area,
rendering it inaccessible. This broke e.g. the control-center
keyboard shortcuts panel, the gnome-disks device list, etc etc.
This is an (unintentional) side effect of my changes to GtkTreeView's
get_preferred_size() implementation. It seems odd to me that
GtkTreeView directly determines its own size when inside a
GtkScrolledWindow, but since it does, it should be using its natural
size, not its minimum size.
gtk_tree_view_column_unset_tree_view() resets column->priv->tree_view to
NULL.
The function is called when a column is removed, but later from the same
function we would call _gtk_tree_view_column_unrealize_button(), which
expects column->priv->tree_view to be != NULL, causing these critical
warnings
Gtk-CRITICAL **: gtk_widget_unregister_window: assertion
`GTK_IS_WIDGET (widget)' failed
This commit moves the call to unset the tree view after the button is
unrealized.
https://bugzilla.gnome.org/show_bug.cgi?id=695473
This was causing warnings on widget unparent like:
Gdk-CRITICAL **: gdk_window_has_native: assertion `GDK_IS_WINDOW (window)' failed
Becasue the window was not properly removed from the lists on unrealize.
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 ddceddaa84 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 ddceddaa84
and changes the code so that both gtk_style_context_set_background() and
gtk_render_background() are called
Since 16195ad the “expand” property is always set to FALSE when a
column is resized. This commit takes a different approach and enables
“expand” whenever the column is wide enough. An appropriate
“fixed-width” (so that the desired width is achieved after expanding) is
calculated using equations that are explained in the code.
https://bugzilla.gnome.org/show_bug.cgi?id=691751
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
Splits up size_request() so that the height calculations are only done
when get_preferred_height() is called and the width calculations are
only done when get_preferred_width() is called. Since
get_preferred_width() does not change the treeview->priv->width value,
treeview->priv->prev_width will always be equal to it and can therefore
be removed. The only place where prev_width was used is a block in
gtk_tree_view_size_allocate(). This block seems to be adjusting the
horizontal scrollbar to account for treeview->priv->width having been
changed in size_request() and should no longer be necessary. A similar
block immediately above it seems to already account for the width change
in size_allocate().
https://bugzilla.gnome.org/show_bug.cgi?id=691751
After “validation” (i.e., background size calculations) of some cells,
size_request() was called here to update the internally cached size of
the treeview. Apparently not updating the sizes leads to some kind of
“inconsistency” that messes with top_row_to_dy(). In the GTK3 model for
size allocation, things are more complicated. The treeview can’t just
go ahead and calculate its own size any more; instead it reports both a
“minimum” and a “natural” size, and it doesn’t know what size it will
actually get until size_allocate(). It may be necessary to update
top_row_to_dy() to deal with not knowing the exact size.
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.
We currently invalidate the whole tree every time the style state
changes in the tree view. The primary reason for this is to catch
default font changes as that may affect text cell renderers. But
cell renderers could *potentially* also read other style properties
(although that seems weird and unlikely).
We handle this by invalidating only when some state that affects sizes
is changed. This includes all the font properties.
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
Currently the GdkWindow used for dragging is created once when
the first drag starts, and the reused identical each time.
Instead, just recreate it for each drag, with the correct size.
Deprecate public API where appropriate and make it no-ops.
Remove all calls to it.
Get rid of the 'transition' css property.
For now, this means spinners don't animate anymore.
Style properties should not be cached, they should be queried live.
Also, this fixes the case where the expander size wasn't set when
constructing the widget which caused expanders to go missing.
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.
Don't handle mouse button events greater than 5 so
they can bubble up to be used by the application.
This was causing nautilus list view to not go forward
and backwards when pressing the extra mouse buttons
designated for that.
Fixes bug 673441
Signed-off-by: Nelson Benitez Leon <nbenitezl@gmail.com>
Since we check for !list->next (and !list->prev for RTL) to set the
GTK_REGION_LAST flag, we have to filter out invisible columns before
looping; if we don't do that we might end up assigning GTK_REGION_LAST
to an invisible column.
https://bugzilla.gnome.org/show_bug.cgi?id=672937
In particular gtksettings.h and gtkstylecontext.h needed to be included
in lots of places now.
Also, I order the includes alphabetically in a bunch of headers.
The widget window is usually covered by the bin_window.
Its background color will become relevant when we introduce
kinetic scrolling with overshooting.
There's no reason this should be a focus ring rather than an actual
frame. In the past this was probably used to get a dashed effect, but
now we even support that natively for borders.
Otherwise, we could sometimes fail to update the cursor node when the
right row was deleted.
Also, I'd like to file a formal complaint that this node/tree
differentiation makes writing comparisons too complicated.
https://bugzilla.gnome.org/show_bug.cgi?id=668169
Instead, focus nothing and wait until we get focus before doing so. This
restores previous behaviour but still emits proper cursor-changed
events.
Fixes a bunch of bugs in the filechooser which populates the treeview
asynchronously.
https://bugzilla.gnome.org/show_bug.cgi?id=613728
No more signal handler is needed, therefore the code can also get rid of
tracking the treemodel. And we use a faster approach for iterating the
changed cellrenderers: We just iterate all columns instead of over all
cell accessibles, as that number is likely quite a bit smaller.
There was a corner case where the changed signal was not emitted.
If rows were built like this:
1 (not selected)
+ 2 (selected)
+ 3 (not selected)
And row 1 was removed, no signal would be emitted.
I like it when writing tests actually finds bugs that have been around
since 2003 - introduced by 4a03ea2334
actually. :)
We get certain cases, in particular with SELECTION_MULTIPLE, where we
cannot figure out in advance of real_set_cursor() if the selection will
actually change.
Previously, the cursor would just become invalid, which used to
reselect the first row in the treeview later on (without a
cursor-changed signal). This leads to a crash now with the recent
refactorings.
The patch is longer than I'd like it to be, but the situation is kinda
complicated, because we want to make sure to move the cursor to a good
row. It works like this:
1) From the deleted row, search forward for the first row that is not
going to be deleted and is not a separator.
2) If no such row exists, search backwards for a row that is not a
separator.
3) If no such node exists, clear the cursor.
Previously the code used a GtkTreeRowReference, which was (a) less
performant and more importantly (b) hiding errors.
The errors being hidden were the referenced row becoming invalid or
collapsed, because such rows would not be valid cursor rows and it would
be necesary to select a new row and emit a "cursor-changed" signal.
So if a crash bisects down to this commit, it is very likely that the
cursor has not correctly been updated and the cursor row is invalid.
Previously, when the cursor was a descendant of the collapsed row,
the cursor path was set to the collapsed row, but this was not
communicated via cursor-changed events.
_gtk_tree_view_find_path() was not a name that not really described what
the function does. And I kept forgetting it. Also, it took the tree view
as an argument and that was completely unnecessary.
Turned assertion into silent return.
This assertion is only hit when dragging from an empty tree view. In
this case, gtk_tree_view_begin_drag() is triggered from gtkdnd.c and not
from gtk_tree_view_maybe_begin_dragging_row(). We actually want to
cancel the drag at this point, but that is not possible with the GTK+
API as far as I can see.
The alternative is to not allowing the drag to start. This could be
done by simply unsetting the tree view as drag source when it is empty
and setting it as drag source again when rows are added. I didn't
choose to go with this for now, since this will likely break third party
code.
In gtk_tree_view_state_flags_changed() we were setting the background on
the bin_window without the necessary "view" style class, making the
treeview render with the wrong color in some circumstances (such as when
adding an empty treeview in a window, as spotted by Brian Smith).
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.
.. as a replacement for _gtk_rbtree_node_find_parity(). Instead of 1 or
0, the function now returns the index of node in the complete tree
(counting from the root). And this is of course identical to the row
number.
Track the RBNode/RBTree instead of keeping a TreeRowReference. This is a
whole lot faster and less error-prone.
Also, notify the accessible of removal of rows before actually removing
them, so we have a chance to clean up.
The default (out) transfer mode is "full", but the passed "model" pointer gets
set to gtk_tree_view_get_model() which is "transfer none". This caused Python
programs to free the model after calling this, causing crashes.
in gtkimcontextsimple and gtktreeview, which are the easy places,
but also true bugfixes, because on OSX we can't use the virtual META
here, we needs MOD2 as delivered in key events.
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".
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
Now that we are not allocating treeview column buttons anymore
with invisible headers, we can't rely on their allocations for
other things like cell area computations anymore. Use x-offset
and width of the column directly, instead.
Include the child widget path in the returned path now. This allows
customizing the path of the current widgets - like adding flags to child
widgets (and maybe siblings in the future).
Patches by Benjamin Otte.
The "invalidate last column" hack is removed. It is now of no use since
the entire widget will be redrawn when a single column changes.
We have to redraw if we are below a couple of rows that changed height
in do_validate_rows(). This will still require a redraw for a large
amount of cases, can we do better? You would expect that a redraw of
the tree view is not required when the dy changes with the same delta
as the delta of the height accrued when validating the nodes. This
further optimization will likely require changes to the top_row/dy
synchronization code.
It turns out that the gtk_grab_remove() can trigger a do_prelight()
call, which may end up changing prelight_node, and then the state
gets messed up. Moving the grab removal until after we're done with
button_pressed_node and prlight_node makes expanders work reliably.
One thing that is still not right is that the expander doesn't get
prelight again after the animation is done, if you manage to release
without any additional motion events.
https://bugzilla.gnome.org/show_bug.cgi?id=641039
Expander animation has been replaced by implicit animations
from the style context.
Column headers are also properly themed, GtkContainer::get_path_for_child()
is implemented and the treeview resets column buttons style on columns
being reordered.
The default CSS has changed to theme treeviews sensibly.
This function is useful to figure out whether the tree view is "blank"
at a given location. For such locations you might want to popup a
custom popup menu, clear the current selection or start rubber banding.
In the future, we are planning on updating GtkTreeView's user
interactions to take advantage of this new function.
Part of bug 350618.
I have never really liked the updates done to the adjustments in
do_validate_rows() and other validation functions. But it is really
required. I have to come up with a real solution to this one day.
Check (x, y) is inside background area. If yes, continue processing
and clamp the coordinates into cell area. This way we will properly
handle getting a cell (which is only used for setting the focus cell)
for clicks in the indentation area (in LTR and RTL mode) and clicks
in the focus rectangle area in case focus-line-width is large.
When focus is initially grabbed and there is no focus column, when selecting
the first column for focus, further explicitly focus into the first cell
using gtk_cell_area_focus().
the edge.
When focusing left/right or up/down inside GtkCellArea, now we save what
was the last focused cell and if we hit the side (or top or bottom) of
the view we then restore focus to the last focused cell.
This function did alot of nothing, gtk_cell_area_focus() simply returns whether
the focus stays in the area (column) or not, seems not to cause regressions to
just call it directly instead.
Instead this is now enforced in gtk_tree_view_get_cell_area_height().
There are rows for which a height in between 0 and expander_size is
allowed, for example separator rows.
This argument allows the caller to specify that only an editable
cell should start editing but an activatable cell should not toggle
it's state, this is important for public apis like
gtk_tree_view_set_cursor_on_cell() which are only intended to
programatically bring attention to the editing of a specific
row or cell but not actually change any data.
GtkTreeView & CellAreaScaffold updated for the last minute api change.
This fix is incorrect, treeviews dont rely on the expander size for drawing
separator rows (added XXX comment in line), need to fix this somewhere else
Now we bookkeep the treeview assigned padding asides from the
requested width stored in the GtkCellAreaContext, this removes
the need for bookkeeping the deepest expanded depth in gtktreeview.c
At allocation time, just remove the padding from the allocated width
of the column and feed the rest to the underlying cell area.
The function has been re-implemented around GtkCellArea. This commits
also brings back the invocation of this function in
gtk_tree_view_button_press(). I shouldn't have removed this.
This is a premature patch, it traverses the tree's expanded
rows and fetches the deepest depth every time we allocate a
column. The deepest depth should rather be cached and pushed
when a row expands, then recalculated when the deepest expanded
row collapses.
Removed gtk_tree_view_get_real_requested_width_from_column() from
gtktreeview.c in favor of this function in the treeviewcolumn domain
(since this function goes and checks treeviewcolumn internals, settings
and derives the real requested width, seems logical this should be done
by the treeviewcolumn instead).
Now the GtkTreeViewColumn takes care of move/resizing its window and
allocating its button (except for the special case of current drag_column
where the column doesnt actually get reallocated).
Some details:
- button_request was not needed, consult the minimum request of the button
- gtk_tree_view_column_get_button() needed to be public as people can set
tooltips on the button (and libgail accesses the button).
This is because focus in treeviews can be given to cells that cannot do anything
with activation (for better keynav), so we dissociate the concept of cell
activation and focusing.
This is still very much a work in progress, but it renders and more or
less works. I will be fixing up the details in the very near future.
Important: this commit breaks ABI as it modifies the GtkTreeViewColumn
structure in gtktreeviewcolumn.h. This is a sealed structure that needs
to be moved to an internal header file, most likely gtktreeprivate.h.
This should be implemented as propery height-for-width by
the treeview-refactor branch. This commit includes a FIXME
comment that scroll adjustments should not be updated from
inside size requests but only after receiving an allocation.
This patch adds the GtkScrollablePolicy type property to GtkScrollable
and implements it in all subclasses. GtkScrolledWindow observes this
property to make a good guess about when to show/hide scrollbars for
height-for-width content.
Most scrollable children do not do height-for-width *yet* but
most certainly will (toolpalette, treeview, iconview, textview
widgets all TODO), for scrollable widgets that do have a minimum
and natural size, it's important for them to observe the state
of this property in order to properly drive the scroll adjustments
according to the desired GtkScrollablePolicy. This patch makes
GtkViewport do this.
Patch also adds tests/testscrolledwindow.c to display the effects
of this property.
