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).
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.
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.
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()
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
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.
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.
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.
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.
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().
This recovers 10 bits, since state and saved_state as uint8 both
wasted 5 bits. Now we can add 10 more flags.
Also, a possible future patch could just do 1-bit bitfields
for the private flags instead of using manual bit twiddling.
https://bugzilla.gnome.org/show_bug.cgi?id=628884
Currently the only users of the GTK_HAS_FOCUS flag are setting it
before sending a focus change event. This is normally needed by
GtkWindow, but there are widgets that require controlling the focus
of widgets that are semantically their children even though they are
parented to another top-level. Case in point: the quick search entry
for GtkTreeView.
Over the years people have been hacking the focus change out of
gtkwindow.c and gtktreeview.c, thus leaking the direct access of the
GTK_HAS_FOCUS flag.
The simplest way to avoid that is to add a function that sends the
focus change event and controls the setting of the flag, thus removing
the need for external widgets to do the same.
https://bugzilla.gnome.org/show_bug.cgi?id=593671
Fixed GtkExtendedLayout to interact with sizegroups, "size-requsts"
and caching the values all in the same code segment.
Migrated the cache code to be internal to gtkextendedlayout.c
This commit changes gtk_extended_layout_get_desired_size() for
per dimension variants. Furthermore this commit reverts the actions
done in size-groups for now as it needs a different approach.
The natural width/height parameters added to aux_info have been changed
for a per width cache for heights and a per height cache for widths.
gtk-demo is still working, currently sizegroups are not taken
into account as mentioned above - size groups need to be alerted both
when the widths and heights are updated independantly and then that
information needs to repropagate also to other extended layout implementors.
Deprecate widget flag macros GTK_WIDGET_STATE, GTK_WIDGET_SAVED_STATE,
GTK_WIDGET_FLAGS, GTK_WIDGET_TOPLEVEL, GTK_WIDGET_NO_WINDOW and
GTK_WIDGET_COMPOSITE_CHILD.
Also deprecate the type macros GTK_WIDGET_TYPE, GTK_OBJECT_TYPE_NAME and
GTK_OBJECT_TYPE which have become redundant.
Instances of GTK_WIDGET_TOPLEVEL are replaced with gtk_widget_is_toplevel,
GTK_WIDGET_TYPE is replaced with G_OBJECT_TYPE, GTK_WIDGET_COMPOSITE_CHILD
is replaced with use of the "composite-child" property and uses of
GTK_WIDGET_NO_WINDOW are adjusted to use gtk_widget_get_has_window.
Uses of GTK_WIDGET_SAVED_STATE and GTK_WIDGET_FLAGS inside GtkWidget are
changed to direct flag usage.
Documentation is updated to refer to gtk_widget_set_has_window and
gtk_widget_get_has_window.
Gail and tests are updated as well.
Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=69872
