We now try to emulate cairo_t:
We keep a stack of nodes via push/pop and a transform matrix.
So whenever a new node is added to the snapshot, we transform it
by the current transform matrix and append it to the current node.
Before, we would immediately invalidate the GdkWindow of the widget, now
we call the parent's GtkWidgetClass.queue_draw_child() function.
This allows the parent to track redraw queueing of children.
By default GtkWidgetClass.queue_draw_child() will again chain up to its
parent while respecting the GdkWindow hierarchy for clipping.
GtkWindow is then the only widget actually invalidating the GdkWindow.
This essentially moves redraw queueing from GDK to GTK.
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 need a virtual function to retrieve the GskRenderNode for each
widget, which is supposed to attach its own children's GskRenderNodes.
Additionally, we want to maintain the existing GtkWidget::draw mechanism
for widgets that do not implement get_render_node() — as well as widgets
that have handlers connected to the ::draw signal.
And with it, gtk_widget_get_visual() and gtk_widget_set_visual() are
gone.
We now always use the RGBA visual (if available) and otherwise fall back
to the system visual.
* Cover letter
Having a single header file for all autocleanups definitions was a
reasonable stop-gap measure, but now GTK+ is starting to use G_DECLARE_*
macros. This means that every class using a G_DECLARE_* macro will need
to include "gtk.h" to avoid compiler warnings, which is not acceptable.
By moving the G_DEFINE_AUTO* use to the header that defines the type we
allow using the G_DECLARE_* macros without sacrificing the ability to
include only the needed files when deriving from a class.
* Commit
This commit changes all includes relative to GtkWindow to define their
own autocleanup macros.
There are currently three widget that implement such a property, and
there are other widgets for which the behavior can make sense. It
seems like a good time to add the property to GtkWidget itself so
subclasses can choose to respect it without adding their own property.
https://bugzilla.gnome.org/show_bug.cgi?id=757269
This is so widgets can queue a rerun of their allocation logic, but
without triggering resizes everywhere.
For now, it just calls gtk_widget_queue_resize().
This allows a widget to override global font_options, such as hinting and
subpixel order. The widget's PangoContext is updated when this is set.
Some update code from gtk_widget_update_pango_context was moved to
update_pango_context so that gtk_widget_update_pango_context runs it.
http://bugzilla.gnome.org/show_bug.cgi?id=751677
These functions, while added for use by the GTK inspector, are generally
useful to applications that need to resolve what action groups are
available to a particular GtkWidget.
https://bugzilla.gnome.org/show_bug.cgi?id=741386
And handle the fact that drawing bounds are now handled by this API and
the corresponding gtk_widget_get_clip().
Also add _gtk_widget_supports_clip() function to check if a widget has
been ported to the new world.
The propagation phase property/methods in GtkEventController are gone,
This is now set directly on the GtkWidget add/remove controller API,
which has been made private.
The only public bit now are the new functions gtk_gesture_attach() and
gtk_gesture_detach() that will use the private API underneath.
All callers have been updated.
Listen for notify::sequence-state-changed on the controller, so the
only way to manipulate a sequence state are gtk_gesture_set_sequence_state()
and gtk_gesture_set_state().
Also, make use of gesture groups, so the sequence state is set at once
on all gestures pertaining to a single group. Within a widget, if a sequence
is claimed on one group, it is made to be denied on every other group.
GtkEventController may be certainly useful to keep event
handling self-contained in other places than gestures, but
the current widget API is highly related to gestures, so
just using GtkGesture as the argument there will be quite
more convenient. The other places where GtkEventController
make sense as a base object will better provide their own
hooks.
A controller can be optionally hooked on the capture or the bubble
phase, so the controller will automatically receive and handle events
as they arrive without further interaction.
The root window is a fairly X-centric concept, and it
really has no place in the GtkWidget API. Plus, this
is a rarely-used one-line convenience function with
poor documentation.
Add margin-{start,end} and gtk_widget_{get,set}_margin_{start,end}
and drop margin-{left,right} and gtk_widget_{get,set}_margin_{left,right}.
margin-{start,end} handle right also in RTL.
https://bugzilla.gnome.org/show_bug.cgi?id=710238
We rename the gtk_widget_class_bind_template_child{_internal}
macros by appending a _private to their name. Otherwise, it
would be too magic to pass the 'public' names as arguments,
but affect a member of the Private struct. At the same time,
Add two new macros with the old names,
gtk_widget_class_bind_template_child{_internal} that operate
on members of the instance struct.
The macros and functions are inconsistently named, and are not tied to
the "template" concept - to the point that it seems plausible to use
them without setting the template.
The new naming scheme is as follows:
gtk_widget_class_bind_template_child_full
gtk_widget_class_bind_template_callback_full
With the convenience macros:
gtk_widget_class_bind_template_child
gtk_widget_class_bind_template_child_internal
gtk_widget_class_bind_template_callback
https://bugzilla.gnome.org/show_bug.cgi?id=700898https://bugzilla.gnome.org/show_bug.cgi?id=700896
Using an offset from the struct means you can have children in
both the public and private (via G_PRIVATE_OFFSET) parts of the
instance. It also matches the new private macros nicer.
https://bugzilla.gnome.org/show_bug.cgi?id=702563
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
gtk_widget_preferred_size() is only useful if you want to quickly port a
widget from GTK2 sizing code to GTK3 but does not properly work with
height-for-width as used in GTK. So we don't want to encourage people to
use it. In particular we want people to convert to height-for-width
before adding baseline support to their widgets.
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.
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
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
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 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 I added the versioned annotation, I accidentally backdated
it, so the Deprecated: tag in the docs said 3.4, but the annotation
said 3.0. Fix it so we say 3.4 in both places.
In particular gtksettings.h and gtkstylecontext.h needed to be included
in lots of places now.
Also, I order the includes alphabetically in a bunch of headers.
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.
This patch changes all uses of GDK_DEPRECATED(_FOR) in gtk headers
by the versioned variants, GDK_DEPRECATED_IN_3_x(_FOR). At the same
time, we add GDK_AVAILABLE_IN_3_x annotations for all API additions
in 3.2 and 3.4.
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
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.
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.
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()
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).
