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.
This test is constructed in such a way that it breaks when you
(currently!) do not trigger a size-request from validate_visible_area.
Especially row expansion appears to have a need for this currently.
GtkComboBox now sports a construct-only "has-entry" property which
decides if it uses a GtkEntry to allow additional user input. Also
it has a new "entry-text-column" to fetch strings for the entry
from the model.
This patch deprecates the GtkComboBoxEntry and updates the rest of GTK+
to use the new semantics on GtkComboBox instead.
GtkComboBoxEntry will be removed altogether before GTK+ 3, in a
later commit.
We expand a tab if either tab-expand is set, or the generic widget
expand property in the correct direction is set. And we do not
propagate expand flags from tab labels to the notebook, only
the expand flags from the pages.
We expand a child when it either has the table-specific expand flag
or the generic expand property set. Override compute_expand so that
it also takes the table-specific expand flags of children into
account.
https://bugzilla.gnome.org/show_bug.cgi?id=628902
This consists of:
* expand a child if either child->expand || gtk_widget_get_expand(child)
* override compute_expand so that child->expand will cause us to
return TRUE for gtk_widget_get_expand()
https://bugzilla.gnome.org/show_bug.cgi?id=628902
GtkWidget now has flags for horizontal and vertical expand, and
a compute_expand() method. compute_expand() is used by containers
to set a default expand flag. (If a widget has expand set explicitly,
it always overrides the results of compute_expand.)
GtkContainer has a default implementation of compute_expand which
simply walks over all child widgets and sets expand=TRUE
if any child is expanding.
The overall effect is that you only have to set expand on
leaf nodes in the widget tree, while previously you had to
set expand all the way up the tree as you packed every
container. Also, now containers need not have their own child
properties for expand.
For old containers which do have "expand" child properties,
they should override compute_expand and include the child
properties in whether the container is expand=TRUE.
Also, the old container should use
"child_prop_expand || gtk_widget_compute_expand()" everywhere
it previously used simply "child_prop_expand"
https://bugzilla.gnome.org/show_bug.cgi?id=628902
Safe space in the private struct, always set the cursor when we
update visibility, since the cursor depends on resizability conditions
too. And don't set the shape needlessly.
This was caused by get_drag_edge() returning -1 to mean 'no drag',
but callers didn't really pay attention. Change get_drag_edge()
to return a boolean instead.
Call gtk_tree_view_set_cursor() in addition to
gtk_tree_selection_select_iter() when selecting the file in
show_and_select_files() so the preview update machinery gets
triggered.
(cherry picked from commit 795c8070db)
This patch makes the scrolled window reconsider allocating the child
the full width or height (depending on the child's request mode) without
a scrollbar. For instance when the child is height-for-width; the child
will first be tested if the content's height for full allocated width
(without a vscrollbar) will allow the contents height for that width
to fit the allocated height.
Patch is a simplified version of code inspected in st-scroll-view.c.
Note that this patch assumes children will begin to scroll only after
reaching their minimum size; adding a property to the future
GtkScrollableIface to decide whether to scroll-to-minimum or scroll-to-natural
will effect this code (it should then reconsider whether the child
will scroll below the natural size instead of the minimum).
Patch addresses bug 629778.
If you set a geometry widget via gtk_window_set_geometry_hints() it
becomes very hard to compute appropriate toplevel sizes in pixels
to make the window a particular size. Synthesizing strings and passing
them to gtk_window_parse_geometry() is possible, but to avoid
avoid such ugliness, add functions:
gtk_window_set_default_geometry()
gtk_window_resize_to_geometry()
That act like gtk_window_set_default_size() and
gtk_window_resize() but are in terms of the resize increments of the
geometry widget.
https://bugzilla.gnome.org/show_bug.cgi?id=631796
gtk_window_parse_geometry() gets the size of the window in order
to interpret the position of the window; calling it before, say,
calling gtk_widget_show_all() on a window is a subtle trap, so
add a warning in the case we can easily detect.
https://bugzilla.gnome.org/show_bug.cgi?id=631794
The geometry widget feature of gtk_window_set_geometry_hints() has
never really worked right because the calculation that GTK+ did to
compute the base size of the window only worked when the geometry
widget had a larger minimum size than anything else in the window.
Setup:
* Move the GtkSizeGroup private functions to a new private header
gtksizegroup-private.h
* Add the possibilty to pass flags to _gtk_size_group_queue_resize(),
with the flag GTK_QUEUE_RESIZE_INVALIDATE_ONLY to suppress adding
the widget's toplevel to the resize queue.
* _gtk_container_resize_invalidate() is added to implement that feature
* _gtk_widget_override_size_request()/_gtk_widget_restore_size_request()
allow temporarily forcing a large minimum size on the geometry
widget without creating resize loops.
GtkWindow:
* Compute the extra width/height around the geometry widget
correctly; print a warning if the computation fails.
* Always make the minimum size at least the natural minimum
size of the toplevel; GTK+ now fails badly with underallocation.
* Always set the base size hint; we were failing to set it
properly when the specified minimum size was overriden, but
it's harmless to always set it.
Tests:
* New test 'testgeometry' that replaces the 'gridded geometry' test
from testgtk. The new test is roughly similar but creates a bunch
of windows showing different possibilities.
* The testgtk test is removed. No need to have both.
https://bugzilla.gnome.org/show_bug.cgi?id=68668
1,936 (112 direct, 1,824 indirect) bytes in 4 blocks are definitely lost in loss record 13,453 of 13,673
at 0x4005BDC: malloc (vg_replace_malloc.c:195)
by 0x69615A1: cairo_region_create (cairo-region.c:196)
by 0x683BFBF: gdk_cairo_region_create_from_surface (gdkcairo.c:455)
by 0x670C882: set_grip_shape (gtkwindow.c:5020)
by 0x670CFBF: resize_grip_create_window (gtkwindow.c:5271)
by 0x670C466: gtk_window_realize (gtkwindow.c:4902)
Signed-off-by: Benjamin Otte <otte@redhat.com>
We need to be a little more careful when determining the overlap
between the new allocation and the grip area. This was causing
vertical scrollbars in evince to overlap with the grip.
This is safer, since GtkWindow subclasses may override realize
and end up with has_resize_grip == TRUE, but grip_window still
being NULL - as is the case with GtkPlug.
We need to position the grip window in size_allocate after all,
otherwise the grip ends up in the wrong place when the window
is realized early.
Also, avoid shadowing a variable.
This was another case of making sure size-request was called
before other code was doing get_child_requisition(), now caching
is done via the same api so no need for that line.
Old code was probably doing size-request on all children initially,
and then calling get_child_requisition() in other passes, now these
are cached after the first request anyway.
If there are both horizontal and vertical scrollbars, there is
an unused 'corner' into which the resize grip fits. Individual
scrollbars need to be shortened and moved to make room for the
resize grip.
We remove the resize grip from GtkStatusbar, but keep the code
that makes the content avoid the grip, and adapt it to GtkWindow
grips.
The gtk_status_bar_set/get_has_resize_grip() functions and related
properties are removed.
Allow any window to display a resize grip, in the south-east or
south-west corner, depending on text direction. This is implemented
as a shaped window that gets overlayed on top of whatever content
is there. We add api that allows widgets to avoid the resize grip,
if desired.
The ::has-resize-grip property controls if a window may display
a resize grip. It will only be displayed if the window is resizable
and not maximized.
The size and visual appearance of the resize grip is under theme
control, using the resize-grip-width/height style properties and
the paint_resize_grip style function.
If you type 'subfolder/' and hit Enter, the file chooser will switch you to
it. But if you type just 'subfolder' without the trailing slash, apps would
receive *that* filename (e.g. file:///foo/bar/subfolder) as the response, and
they would likely print an error that they can't open that file (as it is
a folder). So, we change the file chooser's current folder to that subfolder
in this case.
Signed-off-by: Federico Mena Quintero <federico@novell.com>
Previously name_entry_get_parent_info_cb() would fail as it doesn't handle SELECT_FOLDER.
Now we just make that function act the same as for CREATE_FOLDER mode. In either
case, if you type "/blah/nonexistent" and hit Enter, you want a folder
with that name to be created (under the already-existing /blah).
Signed-off-by: Federico Mena Quintero <federico@novell.com>
The old save_entry_get_info_cb() was misnamed; it is actually used
to see if a file's presumed parent *is* a folder. So we rename
it to name_entry_get_parent_info_cb().
Signed-off-by: Federico Mena Quintero <federico@novell.com>
file_exists_get_info_cb() used to let some actions fall through to
the code that checks for the file type of the selected file's parent
(e.g. to see if /foo/bar *is* indeed a folder if you type /foo/bar/baz).
However, we need to be more explicit for each file chooser action, as
in SELECT_FOLDER mode typing /foo/foldername and hitting Enter would not
give you an immediate selection, but rather the file chooser would
complain that it couldn't create that directory as it already exists.
Signed-off-by: Federico Mena Quintero <federico@novell.com>
The ownership of the return value for gdk_pixbuf_get_from_window() and
gdk_pixbuf_get_from_surface() was determined by the first argument.
Because that is an ugly design and the functions are new to GTK3, we
decided to adapt them.
And that adaptation was quite easy since almost no one passses anything
but NULL as the first argument.
It turns out that the previous handling of just providing a way to set
visuals just on toplevels was not sufficient. In particular it
complicated the various implementations of the tray icon specification.
This patch reintroduces gtk_widget_set_visual() which behaves very
similar to GTK2's gtk_widget_set_colormap().
A future commit will remove the gtk_window_set_visual() function.
