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.
