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.
The incremental loading was broken by GtkIconHelper - queuing a
redraw is no longer sufficient to cause GtkImage to redraw with
the new pixbuf contents.
Pointed out by Jasper St. Pierre.
The keynav dialog is transient to the example window; since the
example window is now modal, we need to make the keynav dialog
modal as well, so it can receive input.
Problem pointed out by Jasper St. Pierre.
This property is TRUE by default, when a popover is modal, it
will automatically set a GTK+ grab on the popover, and grab
the keyboard focus into the popover.
The GtkBuilder window containing the complex popover UI was left
dangling, and with a dangling pointer to its former child, causing
crashes on gtk_grab_notify() after the popover was destroyed.
Two changes that sneaked in during the GtkApplication port
made it so that the window would not let you shrink it again
after you've made it larger. This also yielded very surprising
results when unmaximizing the window: it would come back to
have a minimum width slightly larger than the screen, making
maximization fail from then on.
This demo condenses the essentials of advanced management of
input events. Depending on the information available in input events,
this demo will try to represent as much information as possible for
those.
https://bugzilla.gnome.org/show_bug.cgi?id=719987
* 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.
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>
Emit the "changed" signal after 150 msecs, so that searching
through big lists, or doing online searches feels more responsive.
This is something already done in various applications to make
search-as-you type more responsive (gnome-shell, gnome-documents,
gnome-control-center, etc.). The 150 msecs is the value currently
used by gnome-shell, so keep it (invisibly) consistent.
https://bugzilla.gnome.org/show_bug.cgi?id=700229
In commit 4e41577b, we are using g_content_type_is_a() to determine how
to display the demo resources in the right pane of the gtk3-demo program.
Use g_content_type_get_mime_type(), so that we can obtain the mime
type of the demo resources on all platforms, as g_content_type_guess()
returns a platform-specific string, as
https://developer.gnome.org/gio/2.35/gio-GContentType.html states.
As .ui files and .css files are normally registered with a different mime
type string on Windows, check for those strings as well.
This will ensure the demo resources can be properly displayed on Windows
as well.
This is so we can prepare these buffers without them being set on the
widgets yet and only gtk_text_view_set_buffer() them afterwards. And
this in turn gets rid of all the a11y events we were needlessly
emitting.
https://bugzilla.gnome.org/show_bug.cgi?id=694406
