In preperation for composite objects, for better encapsulation
the following APIs are added to allow handling of signals declared
in the XML with callbacks declared statically.
o gtk_builder_add_callback_symbol[s]()
Adds a symbol to the internal symbol hash
o gtk_builder_lookup_symbol()
Looks up a symbol, exposed in case added symbols are used
in conjunction with gtk_builder_connect_signals_full()
The default implementation of gtk_builder_connect_signals() now
does not have a strong requirement on GModule (or a strong requirement
on symbols being declared in the global namespace). Instead GModule
is used as a fallback in the case that symbols are not declared
explicitly.
It's more logical to have the GtkTextAttributes and GtkTextAppearance
structs together. And it creates a separation between gtk_text_tag and
gtk_text_attributes functions.
https://bugzilla.gnome.org/show_bug.cgi?id=697048
Themes may want to render handles differently depending on whether
the widget is in selection mode (2 handles enclosing a selection) or
cursor mode (one handle pointing out the insertion cursor).
Make the main (and only) entry-point to gtkmodelmenu.c the now-public
gtk_menu_shell_bind_model().
Move the convenience constructors (gtk_menu_new_from_model() and
gtk_menu_bar_new_from_model()) to their proper files.
Remove the private header file.
Simplify the code a bit by making the initial populate part of the
bind() call.
https://bugzilla.gnome.org/show_bug.cgi?id=682831
This is a helper object to allow text widgets to implement
text selection on touch devices. It allows for both cursor
placement and text selection, displaying draggable handles
on/around the cursor and selection bound positions.
Currently, this is private to GTK+, and only available to
GtkEntry and GtkTextView.
It's too close to the release so we'll keep _set_menu() around, but
deprecate it, pointing to the new API. It will be removed (and the name
reused) before the 3.6.0 release.
https://bugzilla.gnome.org/show_bug.cgi?id=682235
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.
