We've recently a number of classes wholly. For these cases,
move the headers and sources to gtk/deprecated/ and adjust
Makefiles and includes accordingly.
Affected classes:
GtkAction
GtkActionGroup
GtkActivatable
GtkIconFactory
GtkImageMenuItem
GtkRadioAction
GtkRecentAction
GtkStock
GtkToggleAction
GtkUIManager
Historically the following states propagated to children:
GTK_STATE_FLAG_ACTIVE
GTK_STATE_FLAG_PRELIGHT
GTK_STATE_FLAG_SELECTED
GTK_STATE_FLAG_INSENSITIVE
GTK_STATE_FLAG_INCONSISTENT
GTK_STATE_FLAG_BACKDROP
However, several of these are problematic on containers like GtkListBox.
For instance, if a row is ACTIVE or SELECTED then all children (like e.g
a button) inside the row will *also* look active/selected. This is almost
never right. The right way to theme this is to catch e.g. SELECTED on the
container itself and set e.g. the color and let the children inherit
the color instead of the flag.
We now propagate only these flags:
GTK_STATE_FLAG_INSENSITIVE
GTK_STATE_FLAG_BACKDROP
Which make sense to be recursive as they really affect every widget
inside the container.
However, this is a CSS theme break, and while most things continue working
as-is some themes may need minor tweaks.
Rename our internal GActionMuxer, GActionObserver and GActionObservable
classes and interfaces to have names in our own namespace.
These classes were originally intended for GIO but turned out to be too
special-purpose to be useful there, so we never made them public API but
have just been copying them around (without bothering to properly rename
them). Now that other people will be copying them out of Gtk, it's even
more important to prevent this namespace abuse from spreading further.
This makes iterating over the children a lot faster, as we're
not doing lots of intra-library calls and type checks. We're still
in some sence O(n^2) since we iterate over each child window for each
widget, but the profiles look much better.
Since widgets now cache drawn state we allow them to override
queue_draw_region to detect when some region of the widget
should be redrawn. For instance, if a widget draws the
background color in a pixel cache we will need to invalidate
that when the style context changes which queues a repaint.
We do the save/restore when emitting ::draw rather than in a custom
marshaller, as this saves an extra stack frame, which is helpfull now
that we do painting fully recursive. This is also likely to save a few
cycles.
We now consider non-native windows non-opaque, which means any invalid
area in a subwindow will also be invalid all the way up to the nearest
native windows. We take advantage of this by ignoring all expose events
on non-native windows (which typically means just the toplevel) and instead
propagating down the draw() calls to children directly via
gtk_container_propagate_draw.
This is nice as it means we always draw widgets the same way, and it
will let us do some interesting ways in the future.
We also clean up the GtkWidget opacity handling as we can now always
rely on the draing happening via cairo.
We can't really just draw by walking down the widget hierarchy, as
this doesn't get the clipping right (so e.g. widgets doing cairo_paint
may draw outside the expected gdkwindow subarea) nor does it let
us paint window backgrounds.
So, we now do multiple draws for each widget, once for each GdkWindow,
although we still do it on the same base cairo_t that we get for the
toplevel native window. The difference is only the clipping, the rendering
order, and which other widgets we propagate into.
We also collect all the windows of a widget so we can expose them inside
the same opacity group if needed.
NOTE: This change neuters gtk_widget_set_double_buffered for
widgets without native windows. Its impossible to disable
the double buffering in this model.
Pointed out in https://bugzilla.gnome.org/show_bug.cgi?id=699016
The fix here is slightly different. We make
_gtk_builder_parser_translate return a const char * instead of
a dup'ed string, and fix up the callers.
If a subclass (say a child of GtkButton) overrides the non-baseline
size request methods we need to call these, rather than the new
get_height_and_baseline_for_width method.
In order to handle this we make the default for this method to be
NULL, and instead check at runtime which method to call. If any
non-baseline vfunc has changed in a class but the baseline one
hasn't, then we can't use the baseline one.
This modifies the size machinery in order to allow baseline support.
We add a new widget vfunc get_preferred_height_and_baseline_for_width
which queries the normal height_for_width (or non-for-width if width
is -1) and additionally returns optional (-1 means "no baseline")
baselines for the minimal and natural heights.
We also add a new gtk_widget_size_allocate_with_baseline() which
baseline-aware containers can use to allocate children with a specific
baseline, either one inherited from the parent, or one introduced due
to requested baseline alignment in the container
itself. size_allocate_with_baseline() works just like a normal size
allocation, except the baseline gets recorded so that the child can
access it via gtk_widget_get_allocated_baseline() when it aligns
itself.
There are also adjust_baseline_request/allocation similar to the
allocation adjustment, and we extend the size request cache to also
store the baselines.
Setting this means baseline aware containers should align the widget
according to the baseline. For other containers this behaves like
FILL.
In order to not suprise old code with a new enum value we always
return _FILL for _BASELINE unless you specifically request it via
gtk_widget_get_valign_with_baseline().
This commit implements the needed machinery for GtkWidget
to build it's composite content from GtkBuilder XML and
adds the following API:
o gtk_widget_init_template()
An api to be called in instance initializers of any
GtkWidget subclass that uses template XML to build it's components.
o gtk_widget_class_set_template()
API to associate GtkBuilder XML to a given GtkWidget subclass
o gtk_widget_class_automate_child()
API to declare an object built by GtkBuilder to be associated
with an instance structure offset and automatically set.
o gtk_widget_get_automated_child()
API for bindings to fetch a child declared to be automated by
gtk_widget_class_automate_child(), for the case where bindings
do not generate GObjects under the hood and cannot use structure
offsets to resolve composite object pointers.
o gtk_widget_class_declare_callback[s]()
Declare static functions to be used in signal callbacks from
a given class's template XML
o gtk_widget_class_set_connect_func()
API for bindings to override the signal connection machinery
for a given GtkWidget derived class.
Deprecate gtk_widget_push_composite_child, gtk_widget_pop_composite_child,
gtk_widget_set_composite_name, gtk_widget_get_composite_name.
This API is just bloat and was never useful, this patch deprecates
it and removes all internal calls to the composite child APIs
Some functions in gtkstyle.h were overlooked when we added the
GDK_DEPRECATED macros.
Also add IGNORE_DEPRECATIONS to the few remaining callers of those
functions.
If the style changes before we're realized we will delay the
style-updated signal until realize. However, we then lose
the changes bitmap. This means that gtk_widget_real_style_updated()
must treat a NULL change as "everything changed" and queue a resize.
Both of them started to make use of round(), a C99 function. So, include
fallback-c89.c to provide a fallback implementation for round() for
compilers that don't have round()
https://bugzilla.gnome.org/show_bug.cgi?id=694339
The last change fixed the windowed widget case but broke
opacity group handling for windowed child widgets. This fixes
up the code by making sure we norender_children in when there
is an opacity group.
This also cleans up the comments about how this works to something
that is hopefully more understandable.
Add an API to start or stop continually updating the frame clock.
This is a slight convenience for applcations and avoids the problem
of getting one more frame run after an animation stops, but the
primary motivation for this is because it looks like we might have
to use timeBeginPeriod()/timeEndPeriod() on Windows to get reasonably
accurate timing, and for that we'll need to know if there is an
animation running.
https://bugzilla.gnome.org/show_bug.cgi?id=693934
We clear GtkTickCallbackInfo on creation to ensure all fields start
as 0. Before we sometimes ended up with destroyed being 1
so the tick was never called.
We need to disconnect the frame clock when we unrealize (at which
point the old clock is still alive) not in destroy(). Since there
is no common unrealize for containers, trigger this from GtkWidget.
Add a very simple GtkWidget function for an "tick" callback, which
is connected to the ::update signal of GdkFrameClock.
Remove:
- GtkTimeline. The consensus is that it is too complex.
- GdkPaintClockTarget. In the rare cases where tick callbacks
aren't sufficient, it's possible to track the
paint clock with ::realize/::unrealize/::hierarchy-changed.
GtkTimeline is kept using ::update directly to allow using a GtkTimeline
with a paint clock but no widget.
Switch GtkStyleContext to using GdkFrameClock. To do this, add a new
UPDATE phase to GdkFrameClock.
Add a GdkFrameClockTarget interface with a single set_clock() method,
and use this to deal with the fact that GtkWidget only has a frame
clock when realized.
https://bugzilla.gnome.org/show_bug.cgi?id=685460
Instead of having gdk_frame_clock_request_frame() have
gdk_frame_clock_request_phase() where we can say what phase we need.
This allows us to know if we get a frame-request during layout whether
it's just a request for drawing from the layout, or whether another
layout phase is needed.
https://bugzilla.gnome.org/show_bug.cgi?id=685460
This adds a way to get the gtk_widget_set_opacity liike behaviour
of retargeting GdkWindows and exposing every child in ::draw, without
actually having an alpha. This is needed if you're doing more complex things
such as cross fading of widgets.
We do this as a hack by using opacity values that round to 255 yet not
really 1.0 in order to avoid having some magical API call for this
mainly internal call.
https://bugzilla.gnome.org/show_bug.cgi?id=687842
This adds gtk_widget_get/set_opacity, as well as a GtkWidget.opacity
property. Additionally it deprectates gtk_window_get/set_opacity and
removes the GtkWindow.opacity property (in preference for the new
identical inherited property from GtkWidget, which should be ABI/API
compat).
The implementation is using the new gdk_window_set_opacity child
window support for windowed widgets, and cairo_push/pop_group()
bracketing in gtk_widget_draw() for non-window widgets.
https://bugzilla.gnome.org/show_bug.cgi?id=687842
This replaces the previously hardcoded calls to gdk_window_set_user_data,
and also lets us track which windows are a part of a widget. Old code
should continue working as is, but new features that require the
windows may not work perfectly.
We need this for the transparent widget support to work, as we need
to specially mark the windows of child widgets.
https://bugzilla.gnome.org/show_bug.cgi?id=687842
This is a quickfix to keep things working.
It turns out GtkWindow assumes it can do sizing operations while not
being visible, or while in the process of show()ing/hide()ing itself.
And commit b495ce54 broke these operations.
Figuring this properly requires some more thinking and restructuring on
my part, so for now we relax the requirement of visiblility enough for
these things to start working again.
GtkWidget::visible is required for the widget to:
- have a preferred size other than 0/0
- have a size allocated
- return other values than { -1, -1, 1, 1 } from get_allocation()
This is an experimental patch aiming to make concepts and behaviors
inside GTK more concreate. GtkWidget::visible is now essentially what
CSS does for "display: none".
Note that if you want the effect of CSS's "visibility: hidden", you'll
have to use a GtkNotebook with an empty page as the concept of reserving
space but not drawing anything isn't supported natively in GTK.
Previously, with STATE_FLAGS_REPLACE we would unset _all_ the state
flags on children, not just the ones that do propagate. This caused the
RTL/LTR flags to get lost.
Now that Pango tracks changes to the context automatically there is
no need to do it manually in e.g. style-updated or direction-changed,
in fact the only case we have to care about is when we re-create
the PangoContext due to a screen change, so we only have to clear
the layouts in GtkLabel in screen-changed.
This means we're not clearing all the layouts whenever the state changes,
which happens to every widget when the window is unfocused, which helps
performance a lot.
https://bugzilla.gnome.org/show_bug.cgi?id=340066
queue_resize basically tells the parent widget that it may need
to pick a different size/layout. However, for a hidden child widget
that should never be needed. It may be that the widget is in a
sizegroup that has ignore_hidden == FALSE though, so it may
affect the size group calculations.
However, if a widget is not visible and not in a size group then
its safe to avoid the resize, as the widget will be resized on
becoming visible anyway.
This avoids a lot of size allocation for hidden things like menus
and tooltips.
Resizes are queued via
gtk_widget_propagate_state()
=> gtk_style_context_set_state()
=> gtk_style_context_queue_invalidate()
=> gtk_style_context_validate()
=> _gtk_widget_style_context_invalidated()
so there's no need to queue an extra one.
This way we don't need a marker on GtkWidgetParivate that needs to be
unset later, so we have all our data in the same place and can avoid
problems with reentrancy and shenanigans like that.
But the main reason I wrote that is cleaner code.
With this function now available, we can do size computation in 2
ways:
(1) Compute size with size groups
(2) Compute size without size groups
And have (1) use (2) instead of setting flags on widgets. This patch
does exactly that.
It seems we missed updating this since GTK+3, widgets cannot be
allocated less than the size they requested in thier request
phase, and explicit sizes are used only to grow the size request.
Otherwise the evil widgets that don't chain up their map and unmap
vfuncs will not get updated style contexts. This is in particular true
for GtkWindow and the CSS Theming / animated backgrounds demo in
gtk-demo.
This change is necessary because the old code did not accound for corner
cases (like translucent child windows), which could stop
gtk_widget_queue_resize() to not trigger redraws.
This is a helper object to allow text widgets to implement
text selection on touch devices. It allows for both cursor
placement and text selection, displaying draggable handles
on/around the cursor and selection bound positions.
Currently, this is private to GTK+, and only available to
GtkEntry and GtkTextView.
gtk_widget_insert_action_group (widget, "foo", NULL) is valid, but
g_action_muxer_insert (muxer, "foo", NULL) is not. Use
g_action_muxer_remove() for that case.
This allows adding a GActionGroup with a given name at an arbitrary
point in the widget tree.
This patch also adds an internal _get_action_muxer() API. Calling this
will create a GActionMuxer associated with the widget. The parent of
the muxer will be the muxer of the widget's conceptual parent. For
non-menus, that is the normal parent. For menus, it is the attach
widget.
In this way, we end up with a hierarchy of GActionMuxer that largely
reflects the hierarchy of GtkWidget, but only in places that the action
context has been requested. These muxers are the ones on which the
inserted actions groups are installed.
A following patch will add a user of this API.
When a widget is app_paintable, its background should not be drawn by
the theme, thus we should not try to override its background again when
style-updated is fired.
This is a bit of a hack, but it fixes gray surfaces observed for DnD
windows with recent GTK+.
Add an internal API that allows GtkStyleContext to create a widget path
for the widget and with that bypassing gtk_widget_get_path() and that
function caching the path.
Deprecate public API where appropriate and make it no-ops.
Remove all calls to it.
Get rid of the 'transition' css property.
For now, this means spinners don't animate anymore.
... and actually set the widget on the style context. Note that this
function does not take a reference on the widget, which is a very good
reason to keep it private.
va_copy() is not universally available, and we already have a G_VA_COPY
macro that emulates the behaviour of va_copy() when it's not available, or
simply calls va_copy() if it's there
This patch adds a capture phase to GTK+'s event propagation
model. Events are first propagated from the toplevel (or the
grab widget, if a grab is in place) down to the target widget
and then back up. The second phase is using the existing
::event signal, the new capture phase is using a private
API instead of a public signal for now.
This mechanism can be used in many places where we currently
have to prevent child widgets from getting events by putting
an input-only window over them. It will also be used to implement
kinetic scrolling in subsequent patches.
http://bugzilla.gnome.org/show_bug.cgi?id=641836
We automatically request more motion events in behalf of
the original widget if it listens to motion hints. So
the capturing widget doesn't need to handle such
implementation details.
We are not making event capture part of the public API for 3.4,
which is why there is no ::captured-event signal.
We don't want to fallback for 'random' touch sequences, since
that could lead to all kinds of pairedness and other violations.
Since the X server already tells us what touch events it would
have used for emulating pointer events, we just use that information
here.
gtk_window_get/set_attached_to() is a new API that allows for windows to
be attached to a GtkWidget.
The attachment is a logical binding between the toplevel window and the
widget that generated it; this kind of information is currently used to
propagate style information from the widget to the window, but is also
useful e.g. for accessibility.
https://bugzilla.gnome.org/show_bug.cgi?id=666103
'window-unfocused' is too long and mentions "focus" which is historically
loaded with the meaning "input focus".
'backdrop' isn't generally used in GUI speak and still conveys the state the
widgets in an unfocused or background toplevel window are in.
Move internal accel map API there and update all users.
Also, add an internal function to create an accel path for
an action and parameter, and use it in gtkapplication.c and
gtkmodelmenuitem.c instead of duplicating that code.
Even if we can't change our sensitivity because the parent is insensitive we
should still flip the sensitive flag. Otherwise, with and insensitive parent,
child.set_sensitive(True)
...
parent.set_sensitive(True)
would result in child still being insensitive.
https://bugzilla.gnome.org/show_bug.cgi?id=666392
In many cases we used to set focus_child to NULL all the way up
to the top and then to the right value, even if there was
a common ancestor, meaning these see a temporary NULL value for
focus_child. Only when the new focus widgets direct parent was
in the previous ancestor list did we stop early.
This fixes that by always stopping propagation when reaching
the common ancestor.
This function returns the accessible if it already exists. This way we
can call functions on the accessible from the widget itself instead of
having to rely on signals.
This is kind of a hack to get rid of infinite loops that occur when
child accessibles try to set their parent upon creation but the parent
accessible creates its children in the initialize vfunc. Because in that
case, the parent will not have an accessible set when the child tries to
access it, because it is still initializing itself. Which will cause a
new accessible to be created.
https://bugzilla.gnome.org/show_bug.cgi?id=660687
Add enum GdkModifierIntent which identifies use cases for modifier masks
and GdkKeyMap::get_modifier_mask(). Add a default implementation which returns
what is currently hardcoded all over GTK+, and an implementation in the
quartz backend. Also add gtk_widget_get_modifier_mask() which simplifies
things by doing widget->display->keymap->get_modifier_mask().
This commit introduces a new setting, gtk-visible-focus, backed
by the Gtk/VisibleFocus X setting. Its three values control how
focus rectangles are displayed.
'always' is equivalent to the traditional GTK+ behaviour of always
rendering focus rectangles.
'never' does what it says, and is intended for keyboardless
situations, e.g. tablets.
'automatic' hides focus rectangles initially, until the user
interacts with the keyboard, at which point focus rectangles
become visible.
https://bugzilla.gnome.org/show_bug.cgi?id=649567
We want the role to be kept in the accessible object. Using
gtk_widget_class_set_accessible_role() is only meant as a quick
workaround to requiring subclassing of the accessibles in the quite
common case where a subclass does not change the accessible
implementation at all and only has a different role.
The function is supposed to bypass the ATK registry. For 2 reasons:
1) We get rid of a lot of boilerplate madness.
2) The registry allows creating multiple accessibles per widget and we
don't.
The old code for registries is still there.
Doing it unconditionally is not useful when the subclasses actually
using them can only ever do it in the style_updated signal. So do it in
the style_updated handler instead.
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).
This is a variant of gtk_widget_child_notify() that takes an
explicit container, instead of relying on widget->parent to
be the correct container to use.
Also print the parent widget. As the parent's size_allocate
implementation is usually the culprit for this warning happening, it
makes sense to print it.
Mnemonics for characters that go beyond the baseline (q, y, g) were not
being shown, because they are drawn outside of the label's allocated
size.
This patch just disables the clip-to-size for labels, so that the label
can draw outsize of its allocation. In most cases, that works around
this bug.
https://bugzilla.gnome.org/show_bug.cgi?id=648570
Instead rely on state_flags & GTK_STATE_FLAG_INSENSITIVE to tell us if a
widget is sensitive.
This has the huge benefit that the way the widget is actually rendered
corresponds to the return value of gtk_widget_is_sensitive().
As a side effect, we do not ever allow unsetting the
GTK_STATE_FLAG_INSENSITIVE for a widget the is set to not be sensitive
(via gtk_widget_set_sensitive()). This way we stop propagation of making
stuff sensitive at insensitive widgets.
https://bugzilla.gnome.org/show_bug.cgi?id=642918
This commit makes GTK_ALIGN_START/_END pay attention to
the text direction when used in horizontal context.
This is how similar parameters in GtkMisc and GtkAlignment work,
and is generally expected of GTK+ positioning parameters. And this
is new GTK+ 3 api, so it is basically still unused at this point.
If explicit right/left turn out to be needed at some point, we
can expand the enumeration with new values.
This ensures that widgets that aren't ported and rely on the style-set
signal being emitted work as well as before. They should not rely on
style-set being emitted however.
Note that this function is a no-op if the initial style has been set
already and is very cheap if it has not been set yet. It only becomes
relevant if the resulting style actually gets used.
https://bugzilla.gnome.org/show_bug.cgi?id=639584
The intention of this patch is to make the code clearer, shorter and
most of all to avoid recreating the widget path and setting it path
twice on the style context when the style context was recreated.
This patch optimizes window resizes by assuming that if a widget
has the same height at a width of 50 as with a width of 150, the
height for width 100 will also be the same.
The patch also further optimizes the cache allocator, now there
are 2 pointer arrays of up to a maximum of 5 requests, the arrays
will only be allocated if a request is ever made in that orientation
and the array will be sparse until each request is made (i.e. if a
label can only wrap to 3 lines, there will only be 3 out of a
possible 5 SizeRequest structures allocated to cache it).
This patch makes contextual height-for-width request caching
optional (the contextual cache is not allocated for widgets that
report GTK_SIZE_REQUEST_CONSTANT_SIZE).
The constant size request mode defines a request mode where
height-for-width geometry is unneeded, thus optimizing GTK+
by reducing the overall amount of requests that need to be
performed and cached while resizing an interface.
Fixes Bug 639584 - initial emission of GtkWidget:style-set is
not happening.
GtkWidget was filtering out ::style-updated (and ::style-set)
emissions until the widget was realized in order to avoid often
useless updates during widget construction and placing.
This is now done instead until the widget has a parent/screen,
which ensures the initial emission happen prior to the first
size negociation, while still filtering out all early emissions
during construction.
Writing onto the passed-in GtkStateData could cause changes that would
propagate to siblings, as the data was not reset again.
By copying the data structure, this is avoided and the proper values are
passed to sibling widgets.
GtkWidget now parses custom attributes like
<style>
<class name="dark-label"/>
<class name="big-heading"/>
</style>
to add style classes to widgets.
https://bugzilla.gnome.org/show_bug.cgi?id=643347
Sensitivity changes were not properly propagated down the
hierarchy. There were two issues here:
a) correctly identifying when a state change request affects
sensitivity
b) not filtering out sensitivity in gtk_widget_propagate_state(),
since gtk_widget_set_sensitivity() uses that to do its work
https://bugzilla.gnome.org/show_bug.cgi?id=641431
Optimized GtkSizeGroup code that is invoked for every queued resize
and every request that is not previously cached by trading qdata on
widgets for 3 extra bitfields on the GtkWidgetPrivate structure.
It is used to get the default providers, without them
the style context can't do much. A check for NULL screen
is done before any sensitive call to
gtk_style_context_set_screen(), in the hope that any widget
will open the display before doing anything related to
styling. Fixes bug #641429, reported by Bastien Nocera.
This management is better done per-widget rather than per-screen,
as windows being destroyed won't trigger a leave notify for the
devices on top of it, and this information is too transitive
to keep weak refs and such.
This fixes the critical warning seen in gtk/tests/testing.
Instead of checking if klass->get_request_mode is != NULL from
the gtk_widget_get_request_mode() api, this allows classes to
trust that there is a default implementation and chain up (specifically
added this for gtkmm wrapper objects).
GtkStateType was generally used as an index in GtkStyle color arrays, so
bigger values will cause invalid memory accesses in widgets that are still
doing that. this was seen in focused GtkIconViews for example
together with commit 8903615a34, this finally fixes bug #640282.
Insensitivity is handled separatedly in _gtk_widget_update_state_flags(),
but the insensitive flag is mistakenly unset afterwards if clear is TRUE
in gtk_widget_set_state_flags().
There is only one widget supposed to have the focused flag at a given time,
so avoid propagating the state down the hierarchy, the focused flag is now
also set in _gtk_widget_set_has_focus().
This function is a more convenient variant than
gtk_widget_set_device_events(), as it will
1) perform changes down a widget hierarchy, to
all windows.
1) use the same event mask than gdk_window_get_events()
This function takes a region ID and cancels all animations
on or beneath that region (as in push/pop_animatable_region).
First user of this is GtkWidget itself, so unmapped widgets
have looping animations cancelled. Fixes bug #638119, reported
by Jesse van den Kieboom.
Now GtkWindow takes some measures when setting toplevelness:
- When a window becomes toplevel after being embedded it saves
the visibility state and reshow's itself so that the window
re-realizes and presents itself again automatically
- When emitting hierarchy-changed, synthetically mark the toplevel
as not anchored, this allows the hierarchy changed propagation to
recurse properly.
GtkWidget also takes care to unset the parent window *after* unparenting
the widget and after emitting the heirarhcy changed that leaves a NULL
toplevel.
That means there are now 2 cycles of "hierarchy-changed" when removing
an embedded toplevel from a parent, first one that makes the new toplevel
a NULL one (since the toplevel flag is not yet restored), the second cycle
makes the removed window toplevel again when setting the parent window
to NULL.
GtkFileChooserDefault watches the toplevel and montitors "set-focus"
signal on it... however the connection needs to be remade when the
GtkFileChooserDialog is in an embedded toplevel.
Measure's taken: GtkWindow propagates hierarchy changes when
_gtk_window_set_is_toplevel() is called, gtk_widget_unparent()
unsets the widget's parent window earlier in the function so that
the possible hierarchy change is still able to properly access the hierarchy.
GtkFileChooserDefault checks if the "new" toplevel is indeed
gtk_widget_is_toplevel() but not the old one, GtkRange has been
updated to use gtk_widget_is_toplevel() inside it's hierarhcy_changed
vfunc, other classes already do this properly.
This patch makes gtk_widget_set_parent_window() undo the toplevelness
of a GtkWindow, GtkWindow then realizes itself as a normal child widget
and behaves like a normal GtkBin by checking gtk_widget_is_toplevel() in
several places (show/hide/map/unmap/draw/size_allocate/check_resize/configure_event).
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.
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.
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.
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).
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.
Replace gtk_widget_shape_combine_region() with
gtk_widget_shape_combine_mask() and
gtk_widget_input_shape_combine_region() with
gtk_widget_input_shape_combine_mask().
As GdkBitmap is going away, and the region equivalents already exist,
this seems like pretty much the default step to take.
Includes code to fix up the users.
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.
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
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
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.
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.
The keysyms create a lot of potential namespace conflicts for
C, and are especially problematic for introspection, where we take
constants into the namespace, so GDK_Display conflicts with GdkDisplay.
For C application compatiblity, add gdkkeysyms-compat.h which uses
the old names.
Just one user in GTK+ continues to use gdkkeysyms-compat.h, which is
the gtkimcontextsimple.c, since porting that requires porting more
custom Perl code.
Preferrably should be made just into a local variable for libgtk like
_gdk_debug_flags for libgdk. But for now used by
gtk/tests/textbuffer.c and modules/printbackends/cups/gtkprintbackendcups.c.
Since we have a new mechanism for requesting sizes: GtkSizeRequestIface;
it makes no sense to maintain this cache on the GtkWidget structure...
removing the requisition cache however does not break the old "size-request"
signal which is there for backwards compatability reasons.
In any case widget->requisition should not have been accessed,
gtk_widget_get_child_requisition() would have been the correct way
to consult the cache.
This commit also deprecates the newly added gtk_widget_get_requisition()
API and makes it fallback on gtk_size_request_get_size().
These members of GtkWidgetAuxData can no longer be set after
the removal of deprecated gtk_widget_set_uposition(), now removed
these members completely and removed the access to them from
gtk_widget_size_allocate().
Allow windows to be dragged by clicking on empty areas in menubars
and toolbars. This is under theme control, via the GtkWidget::window-dragging
style property. The idea is that it makes sense to turn this on if a
theme makes the window frame and the menubar/toolbar appear visually
contiguous.
The main patch was written by Cody Russell, with a contribution by
Ayan George. See bug 611313.
Includes fixing all callers to use the cairo region API instead. This is
usually just replacing the function names, the only difference is
gdk_region_get_rectangles() being replaced by
cairo_region_num_rectangles() and cairo_region_get_rectangle() which
required a bit more work.
https://bugzilla.gnome.org/show_bug.cgi?id=613284
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
