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
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.
Most code in gtkrc.c has been turned into a no-op, but that one
reverting in public API (gtk_rc_scanner_new() and such). GtStyle
is also more shallow, now fully relies in the backing
GtkStyleContext and all connection to gtkrc.c has been removed.
GtkBinding has been also affected, there is no replacement yet
for custom keybindings in style files, so that piece of code that
hooked into gtkrc has been replaced by a FIXME so in the future
it may be added back.
In the process of removing all sealed members from headers.
At the same time, add a gtkwindowprivate.h header and move
all internal functions from gtkwindow.h there.
The old functions to get core pointer and devices list are gone as
well. This slice is entirely replaced internally by multidevice
handling and may just go.
This allows us to add a check before executing
->get_preferred_height_for_width() to ensure we always
request for at least the minimum required size (and lets
us remove the warning in gtkcontainer.c telling implementors
to do this check manually from thier container implementations).
This object backs up gtk_widget_override_* operations. This object
is not meant to be public because any intention to modify widgets'
style in a themeable way should involve using regions/classes, so
they're modifiable through CSS. As such, the API is really
short-scoped.
Things like font settings depend on the screen, and widgets
like GtkTextView trigger queries on widgets without screen
when the parent window is being destroyed.
gtk_widget_override_*() deprecates gtk_widget_modify_*(). There are
only functions to modify fg/bg/font/symbolic color, If anything more
fancy/complex is needed. There is the possibility of adding a
GtkStyleProvider yourself.
gtk_widget_(set|unset|get)_state_flags() has been added, using GtkStateFlags
to represent the widget state. GtkStateType API has been implemented on top
of the new one.
This is now used throughout in order to have the full path for a given widget,
including intermediate named regions, the default implementation just returns
the GtkContainer's path copy, no intermediate regions between.
Some unparented widgets like to ask style details, so now the style is
constructed regardless of the parent being present or not, and then
reconstructed if the parent changes.
There will be one GtkStyleContext per widget, at the moment its
lifetime is tied to the widget's, but it could be narrowed down
to GTK_WIDGET_REALIZED.
Now gtk_widget_size_allocate() unsets the resize_needed flags
before returning, essentially this means that any widget that
has a queued resize and is allocated before resize time, including
queued resizes from inside a size_allocate() method will be
cancelled.
alignment/margin vfuncs adjust_size_request/allocation
Now get_height_for_width() will internally update the for_width
before passing it to the real height_for_width() vfunc, allowing
margins and extra space for alignments to be stripped, thus requesting
sufficient height for greater than natural widths (and also accounting
for margins properly). Test case adjusted in testadjustsize to ensure
proper behavior.
The GtkScrollable interface provides "hadjustment" and "vadjustment"
properties that are used by GtkScrolledWindow. It replaces
the ::set_scroll_adjustment signal. The scrollable interface
also has ::min-display-width/height properties that can be
used to control the minimally visible part inside a scrolled window.
- add slots for damage-event, move-focus and keynav-failed
- reorder signals a bit so related stuff is grouped together
- some indentation fixes in the GtkWidgetClass
- remove the move-focus compat hack from GtkTextView
- turn the move-focus compat hack in GtkWindow into properly
implementing GtkWidget::move-focus()
The gtkprivate.h header contains GtkWidget-specific private symbols that
are not useful except in a handful of cases. Basically everything
includes gtkprivate.h for the GTK_PARAM_* macros.
https://bugzilla.gnome.org/show_bug.cgi?id=632539
This path would only do anything where widget->window was not located at
widget->allocation.x/y but at a different position. This should never
happen in the real world. But if it does, GTK3 will break for you.
Better fix your widget.
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
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
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.
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.
