We now rely on toplevels receiving and forwarding all the events
the windowing should be able to handle. Event masks are no longer a
way to determine whether an event is deliverable ot a widget.
Events will always be delivered in the three captured/target/bubbled
phases, widgets can now just attach GtkEventControllers and let those
handle the events.
gtk_snapshot_pop() => removed
gtk_snapshot_pop_and_append() => gtk_snapshot_pop()
So now there is no way to get a rendernode out of the snapshotting API
until you gtk_snapshot_finish().
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.
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.
The cursor was set using gdk_window_set_cursor() even in
gdk_window_new().
So instead of having yet another flag, just make the users of that flag
call gdk_window_set_cursor() directly after the window was created.
Clip children to their window's size. That way no overdraw happens for
these widgets. But don't clip the handle.
We might in the future consider not clipping un-shrinkable children.
https://bugzilla.gnome.org/show_bug.cgi?id=762021
The GtkGesturePan behavior of locking onto certain orientations may
come across as confusing, and is not strictly necessary for mice and
other pointing devices.
As GtkGesturePan is also a GtkGestureDrag, we just use the same
callbacks on both gestures.
https://bugzilla.gnome.org/show_bug.cgi?id=759670
This was causing problems in the case when only one of the paned
children is visible - we would use uninitialized memory, leading
to invalide clip regions. Concretely, the signal tab in the inspector
would sometimes not render at all.
Drop the margin misuse and use the border allocation of the
handle gadget. We use negative margins to make the border allocation
larger without pushing the paned children out.
Instead of having old and new style, now have a GtkCssStyleChange opaque
object that will compute the changes you are interested in for you.
This simplifies change signal handlers quite a bit and avoids lots of
repeated computation in every signal handler.
Use CHILD1/CHILD2 instead of 0 and 1, always use the same order and
don't check for child NULL-ness, because it will be done in
gtk_paned_set_child_visible anyways.
These days exposure happens only on the native windows (generally the
toplevel window) and is propagated down recursively. The expose event
is only useful for backwards compat, and in fact, for double buffered
widgets we totally ignore the event (and non-double buffering breaks
on wayland).
So, by not setting the mask we avoid emitting these events and then
later ignoring them.
We still keep it on eventbox, fixed and layout as these are used
in weird ways that want backwards compat.
This can be used by applications to indicate that a paned is expected
to be actively used by the users for configuring the UI, and needs
a prominent handle.
https://bugzilla.gnome.org/show_bug.cgi?id=738860
Event controllers now auto-attach, and the GtkCapturePhase only determines
when are events dispatched, but all controllers are managed by the widget wrt
grabs.
All callers have been updated.
GtkPaned may just capture pointer events because the child widget
doesn't happen to have GDK_TOUCH_MASK set, resort to checking the
device in that case.
Dragging is all handled by a GtkGesturePan now, matching the
paned orientation.
On touch events, a wider area is listened for, so touch events
don't need to be as accurate to initiate dragging, if no dragging
is truly initiated in this case, events are just forwarded for
child widgets to handle.
This should allow theme developers to use a very small width for
the resize handle, but still let users easily move the handle by
defining a wider resize area.
The additional resize area follows the "margin" style property.
https://bugzilla.gnome.org/show_bug.cgi?id=728073
Fixes:
(rhythmbox:22802): Gtk-CRITICAL **:
_gtk_widget_get_preferred_size_for_size: assertion 'size >= -1' failed
that is gtk_paned_get_preferred_size_for_opposite_orientation calls
_gtk_widget_get_preferred_size_for_size on child2 with a negative
size.
As gtkpaned size was (32), child1 minimum size was (55) then
for_child1 became (32) for an handle_size of (5). Thus for_child2
ended up as (-5).
https://bugzilla.gnome.org/show_bug.cgi?id=705624
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
Stop documenting the base class as just a base class for the
H and V specializations, copying the useful descriptions from
those H/V classes to the base class. Do not advise the use of
the H/V classes or refer to them unnecessarily.
Fixes sidebar in evince not showing up. This was caused by the
visiblility of the widget changing and the paned not fixing its child
window's visibility accordingly.
The previous code failed to account for all child visibility and paned
mapedness invariants which could cause stray GDK windows to appear.
Not good.
Credit goes to Xan for triggering it.
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".
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.
This commit adds constructors for GtkPaned, GtkBox, GtkButtonBox,
GtkRuler, GtkScale, GtkScrollbar and GtkSeparator and makes these
types instantiable.
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
