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.
gtk_paint_layout is utterly broken. Someone needs to fix it so we use
the cairo_t's matrix and don't juggle with both Pango and cairo matrices
everywhere.
When fitting a widget into its allocation, the second dimension
is always dependent on the first, so gtk_widget_get_preferred_size()
cannot be used directly (because we want the natural height for
the allocated width, not the natural height for the natural width,
which is generally a smaller height than the height-for-minimum-width
or height-for-allocated-width).
Added test to testadjustsize to ensure proper behaviour.
The function reverses the transform that GTK does before emitting a draw
event. So we can use it in "old" widgets to revert the coordinate system
properly.
This mostly goes to keep consistency with the changes to GtkSizeRequest
in the last patch, as GtkCellSizeRequest requires GtkCellRenderer and
GtkCellRenderer implements GtkCellSizeRequest there's no use in keeping
them separate.
This patch renames the functions:
gtk_cell_size_request_get_request_mode()
=> gtk_cell_renderer_get_request_mode()
gtk_cell_size_request_get_width()
=> gtk_cell_renderer_get_preferred_width()
gtk_cell_size_request_get_height()
=> gtk_cell_renderer_get_preferred_height()
gtk_cell_size_request_get_size()
=> gtk_cell_renderer_get_preferred_size()
gtk_cell_size_request_get_width_for_height()
=> gtk_cell_renderer_get_preferred_width_for_height()
gtk_cell_size_request_get_height_for_width()
=> gtk_cell_renderer_get_preferred_height_for_width()
... and moves the corresponding vfuncs to GtkCellRenderer.
The patch also renames the implementations of these functions in cell
renderers to include the word "preferrred".
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".
Previously, we tried to move the context's origin to the widget's top
left location, no matter what window the paint was happening on. Now we
only do that for child windows of the widget's window and leave the
context untouched for windows that the widget has created outside its
own hierarchy. In those casses, we also don't clip the context to
the widget's allocation.
Includes fixes to GtkHandlebox for this effect and fixes all known
issues with it.
These semantics assume that gtk_widget_draw() should only draw the parts
of a widget that are inside child windows and not draw stuff that is
located in completely different GdkWindows. In the handlebox case, it
means that it should only draw the handle when it is attached, but not
when it isn't. We'll likely need a special draw function for the
detached handlebox if we want to draw it.
I've seen (and written) quite some widgets (and theme engines) that use
cairo_paint() to draw the background. So avoiding overdraw makes sense.
Also move all that setup into a _gtk_widget_draw_internal() function
that will be used by all functions that can be used by other functions
that draw widgets.
1) Don't directly draw in motion-notify, instead call
gtk_widget_queue_draw()
2) Don't draw ticks in expose events anymore, only when they were
changed
For now, the draw signal is emitted by default from the expose event, so
widgets can chose to either implement the expose event or the draw
function.
This is for the transitional period from expose event to draw signal.
Note that for now subclasses can only implement the draw function when
none of their parents implemented the expose event.
The functions are gtk_widget_get_allocated_width() and
gtk_widget_get_allocated_height().
They are currently identical to using width/height of
gtk_widget_get_allocation(), but are introduced for ease of use (no need
to use a custom struct) and to free people from having to think about
allocation.x and allocation.y (which is where the origin of the cairo
context in GtkWidget::draw is located).
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.
This removes:
gtk_widget_set_default_colormap()
gtk_widget_get_default_colormap()
gtk_widget_get_default_visual()
Colormaps are gone, and the default visual is the system visual of the
default screen.
Add gtk_window_set_visual() and a "visual" property. This allows
changing the window visual to the rgba one and other awesome things
(like implementing the trayicon spec).
We now return the visual of the topmost widget in widget's stack that
has a window. If no such widget exists, but a GtkWindow is a parent, we
return its visual (note: GtkWindow Will gain support for setting visuals
soon). If a window doesn't exist, we return the system visual of the
default screen.
This change has multiple reasons:
- Colormaps are gone
Now visuals are the most important resource for creating GDK windows.
- Allow widgets to change visuals for themselves and their children
By walking the hierarchy, we ensure that child windows have the same
visual as their parents by default. But widgets can still select a
different visual in their realize handler when creating the GDK
window.
- Have a replacement for gtk_widget_set_colormap()
That function is going to die with colormaps, so a replacement was
needed. That replacement is going to be gdk_window_set_visual().
- Make a future transition to no-window GTK easy
Should we ever attempt a change to make all GTK widgets no-window, a
gtk_widget_set_visual() would be silly, as only widgets with windows
can have their own visuals. So only toplevels will gain the ability to
change it.
