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.
The scrollable patch removed set_scroll_adjustments (NULL, NULL) from
gtk_tree_view_init() which ensured the treeview would have adjustments
at all times, this patch adds set_v/hadjustment (NULL) to _init to ensure
the same thing (without it, there are crashes when trying to access the
adjustments notably from set_headers_visible() in gedit).
It is just too annoying to have to implement these properties in
every scrollable. Instead, we now have ::min-content-height/width
in GtkScrolledWindow.
We also add GtkScrollablePolicy to determine how to size the
scrollable content.
The GtkScrollable interface provides "hadjustment" and "vadjustment"
properties that are used by GtkScrolledWindow. It replaces
the ::set_scroll_adjustment signal. The scrollable interface
also has ::min-display-width/height properties that can be
used to control the minimally visible part inside a scrolled window.
The gtkprivate.h header contains GtkWidget-specific private symbols that
are not useful except in a handful of cases. Basically everything
includes gtkprivate.h for the GTK_PARAM_* macros.
https://bugzilla.gnome.org/show_bug.cgi?id=632539
The idea is that it is way more common to want to manipulate the
actual list, rather than the headers. Once you Tab into the treeview
(and the list part gets the focus), you can use Shift-Tab to focus
the headers.
This means that some hysteresis is added to the focus chain, but
it makes the treeview a lot more convenient to focus with the keyboard.
Signed-off-by: Federico Mena Quintero <federico@novell.com>
Because validate_visible_area() can modify the window size (and thus
the underlying surface), it should not be called from within the draw
method. Given that the presize handler is run with a higher priority
than redraw, and the presize handler will validate the visible area,
there should not be cases wherein the draw method is called and
validate_visible_area() has not been run yet.
However, one such a case was gdk_window_process_updates(), which would
trigger the draw method at some point. We now work around this
by factoring this in a new gtk_tree_view_bin_process_updates() function
that will run the presize handler first if needed.
Note: for other platforms, it might still be the case that the draw
method is called and validate_visible_area() has not been run yet.
(For example the Mac backend calls gdk_window_process_updates() from
the drawRect method, and the redraw-in-idle handling thus works
differently). This does not seem to be a problem now, if
it will be in the future we need to take care of that then.
It doesn't make sense to keep them separate as GtkSizeRequest requires a
GtkWidget and GtkWidget implements GtkSizeRequest, so you can never have
one without the other.
It also makes the code a lot easier because no casts are required when
calling functions.
Also, the names would translate to gtk_widget_get_width() and people
agreed that this would be a too generic name, so a "preferred" was added
to the names.
So this patch moves the functions:
gtk_size_request_get_request_mode() => gtk_widget_get_request_mode()
gtk_size_request_get_width() => gtk_widget_get_preferred_width()
gtk_size_request_get_height() => gtk_widget_get_preferred_height()
gtk_size_request_get_size() => gtk_widget_get_preferred_size()
gtk_size_request_get_width_for_height() =>
gtk_widget_get_preferred_width_for_height()
gtk_size_request_get_height_for_width() =>
gtk_widget_get_preferred_height_for_width()
... and moves the corresponding vfuncs to the GtkWidgetClass.
The patch also renames the implementations of the vfuncs in widgets to
include the word "preferrred".
validate_visible_area() can change the vertical adjustment and thus
trigger window moves/scrolls. This seems to change the surface for
which gtk_tree_view_bin_expose() just created a cairo context. Creating
the cairo context after the call to validate_visible_area() fixes
such crashes.
The keysyms create a lot of potential namespace conflicts for
C, and are especially problematic for introspection, where we take
constants into the namespace, so GDK_Display conflicts with GdkDisplay.
For C application compatiblity, add gdkkeysyms-compat.h which uses
the old names.
Just one user in GTK+ continues to use gdkkeysyms-compat.h, which is
the gtkimcontextsimple.c, since porting that requires porting more
custom Perl code.
Since we have a new mechanism for requesting sizes: GtkSizeRequestIface;
it makes no sense to maintain this cache on the GtkWidget structure...
removing the requisition cache however does not break the old "size-request"
signal which is there for backwards compatability reasons.
In any case widget->requisition should not have been accessed,
gtk_widget_get_child_requisition() would have been the correct way
to consult the cache.
This commit also deprecates the newly added gtk_widget_get_requisition()
API and makes it fallback on gtk_size_request_get_size().
