Turns out that the destination is the last parameter, not the first one.
This fixes the flickering in the first page of the widget-factory when
using the expander on page 2.
The fact that it doesn’t reuse the existing GtkLabel if present is not
immediately obvious to users (or is it just me?), so clarify that the
pre-existing :label-widget, if any, is always removed and replaced.
It does weird clipping that
(a) nobody likes
(b) is hard to support in the new rendering world.
So we take the easy way out.
The actual frame is now drawn by the frame node around the label.
Add a new ::measure vfunc similar to GtkCssGadget's that widget
implementations have to override instead of the old get_preferred_width,
get_preferred_height, get_preferred_width_for_height,
get_preferred_height_for_width and
get_preferred_height_and_baseline_for_width.
We were adding the border gadget size and the label widget size in any
case, but when calculating the width, we want the maximum of those two,
not the sum.
https://bugzilla.gnome.org/show_bug.cgi?id=760482
Setting label-yalign should affect the border gadget, but we need to
compensate for its position by moving the child down or up, depending on
the border gadget's position, so the child never moves.
https://bugzilla.gnome.org/show_bug.cgi?id=762123
As part of this conversion, remove the hardcoded padding around
the label.
Unfortunately, we cannot use the main gadget for drawing the frame
decoration, since we want to draw a custom border instead of the
stock css border that gadgets insist on drawing for us. Therefore,
add an extra gadget with name border and use it just for rendering
the frame.
Lots of applications often use GtkFrame as a giant toplevel container,
and that means that they get size allocated often. When frames get size
allocated, they invalidate their entire widget tree, even if they
haven't changed size or anything like that happens at all. This is
because the shadow / label needs to be redrawn if the child changes
size. We can optimize this out and only mark ourselves for a redraw if
the child has actually changed its size.
This avoids an evil trap when doing MAX (..., ... - 2 * border_width)
and the expression on the right gets promoted to unsigned, instead
of going negative as you would expect.
https://bugzilla.gnome.org/show_bug.cgi?id=699633
It already paints the css border, so let's make it also honor css
background. This is needed to have a box of a different color around
some widgets (e.g. latest gnome-clocks design)
The casting used to calculate the child allocation is confusing MAX().
As a result, width and height end up with negative values, which makes no sense.
https://bugzilla.gnome.org/show_bug.cgi?id=666109
Similar to GtkNotebook, GtkFrame was only allocating space for the
padding width, and not the border.
This could be seen by just running tests/testframe. With a theme that
renders frame borders, setting xthickness = 0 in the test draws the
button border over the frame border, which is wrong.
https://bugzilla.gnome.org/show_bug.cgi?id=664342
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).
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".
Also like the GtkExpander, the label widget is allocated the minimum
height for its allocated width and the remaining space is given to
the child, test case included.
This commit makes a few massive changes to the extended layout
code:
a.) gtkextendedlayout.c --> gtksizerequest.c
b.) _is_height_for_width --> get_request_mode()
c.) get_desired_size(), get_desired_width(), get_desired_height() -->
get_size(), get_width(), get_height()
This is the first partial commit and only effects portions
of the tree that have already been merged in master (in order to
easily cherry pick this commit).
Conflicts:
gtk/Makefile.am
gtk/gtk.h
gtk/gtk.symbols
gtk/gtkextendedlayout.h
This commit was created using a script that searched for all docstrings
containing a parameter and the string 'or %NULL'.
Gdk backends and demos excluded as they are not part of a public API
https://bugzilla.gnome.org/show_bug.cgi?id=610474
The Gtk-custom.c file in gir-repository contained a number of
introspection annotations. Merge those into the GTK source files.
Some documentation was moved from the tmpl/ files to accomodate
the addition of annotations.
2008-08-12 Michael Natterer <mitch@imendio.com>
* gtk/*.c: consistently chain up using
GTK_FOO_CLASS(parent_class)->bar(instance) instead of
(*GTK_FOO_CLASS(parent_class))->bar(instance).
svn path=/trunk/; revision=21085
2008-06-30 Cody Russell <bratsche@gnome.org>
* Practically everything changed.
Change all references of GIMP Toolkit (and variations of it)
to GTK+ Toolkit, showing no mercy at all to our beloved
ancestry. (#540529)
svn path=/trunk/; revision=20709
