If this is done on dispose(), the widget may be destroyed (and its
controllers list NULLified) within _gtk_widget_run_controllers(),
causing warnings/crashes when it just tried to hop on the next
controllers.
Freeing the controllers here should be a safety net for implementations,
so it also makes sense to do this late. The widgets that choose to
free their controllers on dispose can still do so, and get
_gtk_widget_remove_controller() called for these as an indirect result.
There is no good reason to assign the value directly.
Also, this fixes d23f3254b7
where widgets that chained up instead of calling
gtk_widget_set_allocation() would not draw becaues of empty clip.
(1) Get rid of supports_clip flag. All widgets (implicitly) support
clip.
(2) Don't reset the clip to { 0, 0, 0, 0 } before the "size-allocate"
signal.
(3) Make gtk_widget_set_allocation() set the clip (to the allocation).
This ensures that eveyr widget has a clip set.
Note: It overrides previous calls to gtk_widget_set_clip(), while in
3.14 this didn't happen.
(4) As the clip is set by gtk_widget_set_allocation() now, don't set
it after the "size-allocate" signal anymore.
This fixes calls to gtk_widget_queue_draw() from inside the
size_allocate vfunc.
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
Currently we only take into account the window GActionGroup for
activating the accels.
However, the application could have some custom GActionGroup in the
chain of focused widgets that could want to activate some action if
some accel is activated while that widget is focused.
To allow applications to set accels on widgets that use custom
GActionGroups, simply use the muxer of the focused widget, which
already contains the actions of the parents.
https://bugzilla.gnome.org/show_bug.cgi?id=740682
I checked Cairo source code (actually pixman, as Cairo just passes
through) to make sure that the behavior stays identical: negative values
cause an error message from pixman, zero is allowed. Both return an
empty region which gtk_widget_queue_draw_region() would then proceed to
ignore.
Under wayland, the compositor doesn't have a 'overall window alpha'
knob, we just need to add the alpha to the buffers we send.
Client-side alpha, if you want to call it that.
Implement this by reusing the existing alpha support for non-toplevel
widgets. As a side-effect of the implementation, windows with RGBA
visual under X will now also use per-pixel alpha, instead of
overall alpha.
This is a new function that gets called every time we're drawing
some area in the Gtk paint machinery. It is a no-op right now, but
it will be required later to keep track of what areas which
we previously rendered with GL was overwritten with cairo contents.
... just because there is no style context instantiated yet. Instead,
instantiate a style context during realize() and ask it.
Fixes problems with dim labels not being dimmed on first show.
Testcase included.
https://bugzilla.gnome.org/show_bug.cgi?id=735240
This is more for GTK developers to catch when they forgot to change
GTK_STATE_FLAGS_BITS after adding a new state flag than to prevent
widget developers from using the wrong flags.
gtk_widget_get_events() must indeed tell about events enabled purely through
a GtkEventController, those events will most surely trigger event handlers.
https://bugzilla.gnome.org/show_bug.cgi?id=734357
Make gtk_widget_path_append_for_widget() add the state flags of the
widget, too.
This enables the ability to select pseudoclasses on all elements in a
selector.
The template documentation is lacking inlined examples on how to use the
templates API, like binding children and callbacks. This makes looking
for best practices a bit harder than it ought to be, for a feature this
useful.
This reverts commit b875572f2a.
Apps like Abiword, gnumeric and gnome-chess, and toolkits like
ClutterGTK were all using this for various purposes, and this made them
break. Bring back this feature for now.
It still won't work under Wayland.
gtk_widget_set_double_buffered is now deprecated, and we don't support
non-double-buffered widgets. This means that under normal circumstances,
paints are never outside of a begin_paint / end_paint sequence, which
natively-double-buffered backends like Wayland can't possibly support.
A few properties here are special, and can't benefit from it:
those which are just shorthands, like ::margin and ::expand,
and those that have explicit -set properties, like::hexpand
and ::vexpand.
Widgets becoming insensitive won't receive further events, but there
could be chances the controllers don't get properly notified and reset
in those situations.
The touch_event handler was missing those when emulating pointer events
for the widgets that get GDK_TOUCH_MASK set, but have no specialized
touch handlers.
This code is a product of early stages in the gestures branch, where
capturing would have an effect outside grab boundaries. But this isn't
really the case, so every gesture outside the grab scope must be reset
to avoid keeping stale data.
Before this change, a sequence being claimed deep in the event propagation
chain would make the sequence go denied on every ancestor, regardless of
previous state.
To make things more consistent, only deny the sequence if it was previously
claimed, so the behavior is the same for gesture groups within the widget
than for those outside the widget.
The gestures testsuite has been updated to reflect this new behavior.
Previously, there would be globally just a capture and a bubble phase,
with the event just going down the hierarchy once, and the up once.
GTK_PHASE_TARGET actually meaning "run within event handlers", so in
a hierarchy of 3 widgets, emission would be:
Capture(C)
Capture(B)
Capture(A)
Target(A) (if event handlers allow)
Bubble(A)
Target(B) (if event handlers allow)
Bubble(B)
Target(C) (if event handlers allow)
Bubble(C)
This commit changes this behavior and uses GTK_PHASE_TARGET in a less
misleading way, running only on the widget that was meant to receive
the event. And GTK_PHASE_BUBBLE has taken over the execution place of
GTK_PHASE_TARGET, so the emission remains:
Capture(C)
Capture(B)
Capture(A)
Target(A)
Bubble(A) (if event handlers allow)
Bubble(B) (...)
Bubble(C) (...)
As it was, GTK_PHASE_BUBBLE was useful for running event controllers
paralelly to event handlers, without modifying a single line in those.
For those mixed scenarios, Any of the other phases will have to be
used at discretion, or the event handlers eventually changed to chain
up and let the default event handlers in GtkWidget to be run.
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.
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 "bubble" phase used to run before event handlers before GTK_PHASE_TARGET
was added, in order to keep phases in the expected order, move GTK_PHASE_BUBBLE
to be run (still invariably) after event handlers.
The only behavioral change should be wrt widgets wanting mixed event handler/
gesture handling, they could previously attach the gesture to the bubble phase
and check for gtk_gesture_is_active() in the event handler to bail out, they'll
have to use GTK_PHASE_CAPTURE for that purpose from now on.
Multiple calls are supposedly allowed to change the phase (although
unlikely to happen), so remove the g_return_if_fail() checking whether
the controller was already added.
Just call the controllers on that phase if the default widget handlers
are run.
For compatibility reasons, in the touch event handler, let the pointer
emulating touch be transformed to a pointer event as usual, in order to
have widget handlers a chance to run at all. If they have to be managed
by a controller in that phase, it'll have to be through the default pointer
event handlers.
This phase is meant to run in the default widget handlers, as opposed
to externally as in the bubble/capture phase. This will be most usually
the expected phase for every controller replacing code in event handlers
in GTK+, just so invocation and triggering order is kept unaltered.
We can end up with _gtk_widget_remove_controller getting called
while we are iterating over the list in _gtk_widget_run_controllers.
To avoid trouble, only mark the event controller as dead by
setting data->controller to NULL, and defer the actual freeing
and list manipulation to the loop in _gtk_widget_run_controllers.
Update other places that operate on controllers to handle
data->controller being NULL.
Make it really sure that the event is only emitted after every gesture
that consumed the button press is done with the sequence.
The event must only be emulated if a gesture in the capture phase happened
to consume the event, be cancelled, and
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.
Within a widget, if a gesture accepts a sequence, it would previously
cancel every other gesture that not in the same group. Change this to
only cancelling gestures that previously claimed the gesture, and let
gestures with state=NONE for that sequence remain like that.
This enables late recognition of gestures, even on the presence of
another gesture group that was more eager at claiming the gesture.
One usecase is user-defined panning gestures on scrolledwindows,
if ::capture-button-press is TRUE (eg. the default), the gesture is
claimed early in order to consume the button press, but that would
tipically make every other gesture group deny the sequence. With
this change, the pan gesture can keep state=NONE, and later claim
the sequence for itself if the panning gesture is recognized.
Also, do not propagate state=DENIED to every gesture in the widget,
that was unintended.
The utility of those signals is somewhat dubious now that there is
gtk_gesture_group(), so make that the only way to coordinate gestures.
The cooperation model offered by gtk_gesture_group() is flexible
enough,
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.
Gestures attached with this phase will expect callers to have it
receive events through gtk_event_controller_handle_event(), but
the gesture will still be notified of sequence state changes,
grabs, etc...
If the captured touch begin or button press event have been consumed
for the given sequence, propagate it upwards if the sequence goes from
claimed to denied, so the widgets on the way to the event widget receive
a coherent event stream now that they're going to receive events.
The policy of sequence states has been made tighter on GtkGesture,
so gestures can never return to a "none" state, nor get out of a
"denied" state, a "claimed" sequence can go "denied" though.
The helper API at the widget level will first emit
GtkWidget::sequence-state-changed on the called widget, and then
notify through the same signal to every other widget in the captured
event chain. So the effect of that signal is twofold, on one hand
it lets the original widget set the state on its attached controllers,
and on the other hand it lets the other widgets freely adapt to the
sequence state changing elsewhere in the event widget chain.
By default, that signal updates every controller on the first usecase,
and propagates the default gesture policy to every other widget in the
chain on the second. This means that, by default:
1) Sequences start out on the "none" state, and get propagated through
all the event widget chain.
2) If a widget in the chain denies the sequence, all other widgets are
unaffected.
3) If a widget in the chain claims the sequence, then:
3.1) Every widget below the claiming widget (ie. towards the event widget)
will get the sequence cancelled.
3.2) Every widget above the claiming widget that had the sequence as "none"
will remain as such, if it was claimed it will go denied, but that should
rarely happen.
This behavior can be tweaked through the GtkWidget::sequence-state-changed and
GtkGesture::event-handled vmethods, although this should be very rarely done.
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.
Make the relative_to widget the parent for a GtkPopover's
GtkActionGroup. This, for example, makes the menu model of a
GtkMenuButton find action groups attached to the button.
https://bugzilla.gnome.org/show_bug.cgi?id=729915
The documentation for the GtkWidget::size-allocate signal is missing the
description of the "allocation" parameter. Add the missing description
to the parameter.
https://bugzilla.gnome.org/show_bug.cgi?id=726179
Add gdk_device_get_last_event_window(), and use to implement the window
tracking we need for synthesizing crossing events for sensitivity changes
and gtk grabs, rather than keeping the information in qdata and updating
it based when GTK+ gets events.
https://bugzilla.gnome.org/show_bug.cgi?id=726187
Try to do a better job of keeping example content
from being too wide. It is often rendered as <pre>
text so the only time we can wrap it is in the source.
It is best to full break lines at all punctuation and
to try to keep the width under 70 chars or so.
The properties are declared read-write, but only the setter
was hooked up. This was leading to criticals in test apps using
the prop-editor.c code. Complete the implementation by adding the
getter side too.
Previously we did a semi-successful job at ignoring it. Unfortunately
this job was bad enough that we could lose the direction.
We still allow passing in the enum values, because we want code like
this to work:
set_state_flags (get_state_flags() | SOME_FLAGS)
10b5ec20 made sure not to set focus_child to NULL all the way up to the
top, but only up to the common ancestor. However, it would never set it
on the common ancestor itself, which would therefore remain with a
focus_child set when it shouldn't.
A manifestation of the bug: focus column headers of a treeview, press Tab.
Now pressing Shift+Tab will go to another widget and not the column
headers, and Tab will (appear to) do nothing, all because the treeview
still has a focus_child set to column headers after a grab_focus().
Signed-off-by: Olivier Brunel <jjk@jjacky.com>
https://bugzilla.gnome.org/show_bug.cgi?id=723402
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
_gtk_widget_draw_internal() was clipping by passing the subwindow
sizes as a path to cairo_clip(). This was breaking for windows
larger than 23 bits in width/height, due to cairo using fixed point
(24.8) for the path coordinates.
We fix this by pre-clipping the subwindow region to the existing
cairo clip region in the full 32bit gdkwindow precision. This fixes
the GooCanvas Large Items test.
https://bugzilla.gnome.org/show_bug.cgi?id=710958
For some widgets, like GtkTreeView, which setup a clock frame
update during realize, it was possible to call
gdk_frame_clock_begin_updating() twice, but only ever disconnecting
from it once. This happens because the realized flag is set at an
unpredictable time by the GtkWidget's realize implementation.
Keep the signal handler ID from us connecting to the "update" signal
to avoid connecting to it twice.
This fixes high wake-up count from any application using GtkTreeView,
even idle ones.
https://bugzilla.gnome.org/show_bug.cgi?id=710666
Previously, GtkWindow would add the "app" action group to its own
toplevel muxer.
Change the setup so that GtkApplication creates the toplevel muxer and
adds itself to it as "app". Use this muxer as the parent muxer of any
GtkWindow associated with the application.
This saves a small amount of memory and will allow for accels to be
propagated from the application through to all of the windows.
GtkWidget had a hack where if opacity is 0.999 we set up an opacity group when
rendering the widget. This is no longer needed in 3.10, and GtkStack doesn't
use it anymore.
GdStack is using it, so applications should be ported from GdStack to GtkStack
in 3.12.
https://bugzilla.gnome.org/show_bug.cgi?id=703603
Updated documentation to specify that '0' should be specified if
one does not need to automatically assign a bound child to a public
or private instance member (now that negative values are private
structure offsets).
* gtk/gtkwidget.c: drag-leave signal: Document that it is called before
drag-drop.
drag-data-received signal: Document that it is up to the application
to know why the data was requested (e.g. drag motion or drop).
* demos/gtk-demo/toolpalette.c: interactive_canvas_drag_drop():
Do not transform the drop_item created in the drag-motion handler.
Instead caused drag-data-received to be called, remembering why,
and create a new item there.
interactive_canvas_drag_leave(): Remove the idle-handler hack,
now that we do not need to keep the drag-motion drop_item alive until
the drop.
I noticed that this patch was sitting in bug #605611 from 2009
though it had been approved. I do not remember much about why I
created it.
This is the same behaviour as gtk_widget_get_valign, except
we have no gtk_wiget_get_halign_with_baseline, as baselines make
no sense for halign.
Without this some widgets (like e.g. GtkOverlay) crash if you accidentally
set a BASELINE halign.
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>
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.
