APIS: gtk_cell_view_get_desired_width_of_row &
gtk_cell_view_get_desired_height_for_width_of_row were introduced in
3.0 only for use from GtkComboBox and now the refactored cellview
does this transparently and just requests the right thing through
GtkWidget apis.
First iteration at implementing combo box using a delegate
treemenu, almost everything is working. Still need to finalize
sensitivity issues in GtkTreeMenu (and should go ahead and pass
through GtkComboBox code with a fine comb...).
- "fit-model" decides that the cellview should request space for
the entire treemodel, this ensures the cell view displayed on
a combo box will not spuriously change size when the selected
item changes.
- "draw-sensitive" forces cell area to render cells sensitive
even if they are insensitive in the model.
Added properties "wrap-width", "row-span-column" and "column-span-column"
to allow grid style menus from treemodels. Handling row data changes
appropriately.
Combo boxes expose an "add-tearoffs" feature to add a tearoff item to the root of the combo menu, added this feature to GtkTreeMenu to achieve this (and updated the testcase).
Now the GtkTreeMenu properly updates its hierarchy when the underlying
model data changes (row inserted/deleted or reordered). Also some unneeded
hackery was removed, all size calculations are delegated to the cellviews.
When the "row-changed" signal on the model is trapped, if the row which
changed is the displayed row then the context is flushed and sizes are
recalculated for every area in the same context.
GtkComboBox needs treemenus to allow selection of all leafs including
rows which may have children, this allows the combobox or combobox user
to decide which row that has children can also be selectable as a header
leaf of the submenu. Test case testtreemenu updated to reflect this.
GtkTreeMenu needs to only populate it's submenus when set_root()
is called, we were populating it when the model is set which cause
the tree to be infinitely populated as the root is NULL by default.
Also call gtk_menu_set_reserve_toggle_thingy (FALSE) to not reserve
space for the toggle size.
Added GtkTreeMenu class to automatically render
a GtkTreeModel into a GtkMenu hierarchy (will be
used by GtkComboBox for its dropdown menus). Included
an accompanying testcase tests/testtreemenu
This is needed by GtkTreeMenu to ensure that child menu items
reserve space for the submenu indicator even if they dont have
submenus... in this way we ensure the same size of all cell
areas in the menu items at allocation/request time.
Added construct GtkCellArea and GtkCellAreaContext properties,
the context property allows putting multiple cellviews into the
same size request context.
The show_submenu_indicator flag was explicitly set in various
places from GtkMenu/GtkMenuBar at request times, since the
GtkMenuItem already checks the parent type for GTK_IS_MENU_BAR()
in various places, removed this flag in favor of just checking
the parent type (only in the interest of better readable code).
In bug 635207, it was pointed out that it is a bad idea to
rename these tools purely in the name of parallel-installability,
since it forces dependencies to make a choice between running
gtk-update-icon-cache and gtk-update-icon-cache-3.0 (or both ?!).
So, we rename these utilities back to their un-suffixed names
and rely on distributors to resolve the conflict between GTK+ 2.x
and GTK+ 3.0 packages, which can be done e.g. by dropping the
utilities from the gtk3 packages and add a gtk3 -> gtk2 dependency.
GtkWindow was only releasing the application in finalize, causing
problems for language bindings. Now we release it already in destroy
(and then again in finalize for good measure).
https://bugzilla.gnome.org/show_bug.cgi?id=638580
When commenting out a binary, also comment out the related variables.
Don't include Makefile.decl in gtk-doc Makefile.am's as they disagree
on assigning to EXTRA_DIST.
I neither know how to trigger this code nor what would be
the suggested replacement API. BUt it's the last thing stopping
me to compile GTK3 for win32.
Although gtk.symbols seems to be unused on Unix now it still
must not contain unprotected Unix only functions, because they
can not be exported on win32.
Since "->adjust_size_request()" was added, it became important for GtkBin's
generic height-for-width implementation to further check the requests
using this vfunc.
of limiting it to it's minimum size.
This fixes height-for-width labels inside a GtkCheckButton, for some
reason GtkCheckButton was limiting the child allocation to the child's
minimum request, probably for the sake of virtual left-alignment of
the child label to be beside the checkmark. This should be done by
other means if nescesarry.
For "padding" cases, it would be ok to fallback on GtkBin class
implementation of height-for-width. However in cases where the
user set's an xscale/yscale the GtkAlignment needs to take care
of properly adjusting the for_size when querying it's child.
Checks were in place to ensure that widgets never request taller
or wider than screen size. This was there to test a theory about
scrolled window children functioning correctly with dynamic content
however it breaks GtkViewport children which can generally return a
value taller than screen height intentionally, GtkViewport uses this
value to update the adjustments.
The functions to set frames on windows stopped being interesting
when the linux framebuffer port was dropped, many years ago.
Similar functionality may come back with client-side decorations
in the future.
Usually pango_layout_get_pixel_extents() is used, which uses
PANGO_PIXELS_CEIL on the rectangle's width. This commit makes the new
function gtk_cell_renderer_text_get_preferred_width() consistent with
this.
This fixes rounding errors on Mac OS X, where we were seeing tree views
with a double height for a single line of text, while the usual single
row height would have been sufficient.
This was claimed to cause problems for Chromium, see bug 599130.
Also work around apparent rounding errors in XIWarpDevice by
setting the 'small step' for keynav dnd to 2 instead of 1 - I notice
that a warp seems to sometimes warp a little less than I tell it to,
and if I tell it to only move by 1 pixel then moving less means
that you are stuck.
For normal toplevels, visible is tightly bound to mapped, but for
something like a toplevel that exists within a Clutter stage we
may want to make mapping dependenton external factors, so we shouldn't
actually checked that !mapped toplevels are !visible.
Pointed out by Owen Taylor,
https://bugzilla.gnome.org/show_bug.cgi?id=637834
Always returning NULL (no match) from gtk_rc_get_style_by_paths()
means that looking up colors and style properties based on the
GtkStyle will give default values instead of themed values. We can
do better by returning a GtkStyle based on a GtkWidgetPath that we
figure out from the values passed in to get_style_by_paths().
https://bugzilla.gnome.org/show_bug.cgi?id=637520
Move everything dealing with compound text to be X11 specific
Only gdk_text_property_to_utf8_list and gdk_utf8_to_string_target
are kept across backends, so add vfuncs for these.
Also, remove the non-multihead-safe variants of all these.
These functions were trivial g_spawn wrappers in all backends
except for X11, and they can be easily replaced by
g_app_info_create_for_commandline + GdkAppLaunchContext.
This commit does a number of things:
- remove some dead wchar configury from configure.ac and gdkconfig.h
- repurpose gdkconfig.h as header that contains GDK_WINDOWING_foo
macros for each included backend, include it in gdk.h and install
it in $includedir instead of below $libdir
- drop the backend from the library names
- build libgdk-3.0.la as a convenience lib and include it in libgtk-3.0.la
It does not yet enable building multiple backends at the same time.
Now a cell can either have a "fixed" size or it can have
an "aligned" starting point or both. "fixed" size cells take
no space when they are invisible.
Added _gtk_cell_area_set_cell_data_func_with_proxy() to be called by
gtk_cell_layout_set_cell_data_func() when the layouting object itself
is not the underlying cell area.
After the window removal a while ago, the calendar main window
was not properly moved in size_allocate. Also, we ought to hide/show
the windows in map/unmap, not keep them visible at all times.
Bug 634657
Previously, for performance reasons we would sometimes
skip invoking the unmap signal (and associated vfunc)
in favor of simply unrealizing. However, widgets then
had no way to clean stuff up when they were hidden
(but still inside a parent which was shown).
This patch also removes _gtk_tooltip_hide() which
was done in both unmap and unrealize in gtkwidget.c,
now can only be in unmap.
There are probably lots of things cleaned up in
unrealize that would now be better to move to unmap.
https://bugzilla.gnome.org/show_bug.cgi?id=629923
Requires fixes to GtkContainer and GtkWindow to unmap their
children, rather than just withdrawing or hiding the container
window.
Requires fix to GtkHandleBox to chain up to GtkContainer unmap.
Historically we avoided these unmaps for efficiency reasons,
but these days it's a bigger problem that there's no way
for child widgets to know that one of their ancestors has
become unmapped.
These checks are a bit expensive so require --enable-debug=yes.
gtk_widget_verify_invariants() checks invariants mentioned
in docs/widget_system.txt in particular, and can verify
others in the future.
Some of the invariants in docs/widget_system.txt don't
in fact hold right now, so those are #if 0'd in this
patch pending someone fixing either the docs or the code.
