Seems commit 7b42d4feda makes
GtkSpinner a direct subclass of GtkWidget but forgets to
update the header file to include gtkwidget.h instead and
declare the instance and class structures properly (assuming
this was just a missed file in the commit).
Originally the GtkSizeRequestIface patches left GtkSizeGroup working
only by bumping the minimum sizes - this commit fixes size groups to take
both minimum and natural requests into account.
Since the location button is hidden in save mode, we need to add the
path bar to the size group too. The location button still has to be in
the group though, because it's larger than the path bar (when
shown). Instead of using the recent/search icons, add their hboxes so
that themed widget spacings don't introduce variations.
With this new approach at request and allocate time, the average child size
is used to determine a good guess at how many columns will fit the box
width; afterwards extra columns are appended and checked to fit.
Then the row heights are calculated based on height-for-width of each
child in the row which now may have individual widths.
The detail strings now have more "detail" by default, so gtkstyle.c
needed to be updated to properly handle this. Tests like testtreeview,
testtreesort now have proper background drawing again.
This strncmp trick was the best I could think of so quickly, if anybody
has an idea to do this in a better way, let me know.
h-align = START,END,CENTER,FILL
v-align = START,END,CENTER,FILL
margin-left,right,top,bottom
margin
These should obsolete all such similar properties on
layout containers, GtkMisc, GtkAlignment, GtkContainer::border-width
Margin is outside the size request.
If margin were not outside the set_size_request() it would not work the
same way as container-supplied (child property) padding.
Conceptually set_size_request() forces the value from the subclass
(the original unadjusted request) and then we go on to adjust
the request further by adding the margin.
A subclass calls gtk_container_class_handle_border_width()
in its class_init
This marks the subclass as expecting GtkContainer to deal with
border width automatically, which GtkContainer then does.
Use these new methods to handle set_size_request (aka aux_info)
inside gtkwidget.c, instead of having external code mess with it.
The virtual functions can be used for other purposes in the
future. For example, GtkContainer::border_width could be
automatically implemented for all container subclasses.
Did not update uses in other files because the plan is to
get rid of those other uses anyhow. So don't want to make
this function available in the header.
This is better than peeking aux info then testing != NULL
in several ways:
- it returns const aux info so if we don't create we can't write
- it ensures that the default we assume if aux_info is NULL is
the same as the default we set if we've created the aux info
- it avoids typing in != NULL checks
We are not re-entrant and there is no reason for widgets to
do this, most likely they'll just get unexpected bugs because
the wrappers may modify the request.
Computing the request should logically rely only on the
widget itself, not on any adjustments caused by set_size_request,
size groups, and so forth.
https://bugzilla.gnome.org/show_bug.cgi?id=628829
In GtkBin and GtkWidget we tried to provide handy defaults that
call get_width if there's no get_width_for_height and
get_height for get_height_for_width.
However, they used the wrapper API on GtkSizeRequest instead of
chaining directly to the other method implementation.
This could result in all kinds of surprising behavior, for example,
get_width_for_height() would now already include the effects of set_size_request().
If nothing else it's inefficient. But it's just conceptually wrong,
because to chain to another implementation, we should call the other
implementation, not call a wrapper around the other implementation
(when we're already inside a previous invocation of the wrapper,
i.e. compute_size_for_orientation() ends up reinvoking itself
in the same orientation on the same object which it pretty
likely isn't intending to do)
https://bugzilla.gnome.org/show_bug.cgi?id=628829
32K of border ought to be enough for any pixel dimensions. At least
until screens are so huge we start using doubles.
This saves a nice 64 bits of space when we have a GtkBorder
stored somewhere.
Signed integers are used to avoid surprising unsigned math
issues. Just search GTK's whole git log from inception
for "unsigned" if you want to find any number of commits
fixing signed/unsigned bugs.
https://bugzilla.gnome.org/show_bug.cgi?id=629387
When writing the original code I erroneously assumed that the current
point of the cairo context would be saved by cairo_save/restore(), but
of course the current point is part of the path and therefor isn't
saved.
Also do a cairo_new_path() before rendering any text so that we are sure
the text ends up at the right spot.
gtk_widget_set_window() does not add a reference to the
owned window... this is an exception to most gtk_foo_set_bar()
functions where as it acts as if it were named gtk_widget_take_window().
Adding note to the docs to avoid people giving the window to the
widget and naturally proceeding to unref the window.
Fixed issues in my previous patch for bug 626939 removing GtkRequisition
cache: these widgets monitor the previous requested size and decide whether
to queue a resize when the content changes based on it's prior request.
Now that we have a private data installed directly on
the GtkWidget instance it makes no sense to cache the size
requests on widget qdata. This change will generally make
GTK+ memory less fragmented as well as significantly speed
up the size request process.
