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().
This was a style property to let theme engines 'opt-in' to more
correct behaviour while maintaining compatibility with existing
themes. GTK+ 3 engines are expected to handle the more correct
behaviour.
