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.
Use $(AM_V_GEN) for generating man pages, and set some parameters
for the XSL stylesheets. Among other things, don't generate AUTHORS
and COPYRIGHT sections.
This program launches an application specified by its desktop name
optinally taking list of URIs which are passed as arguments.
Uses GdkAppLaunchContext to get proper startup notification and
display handling for graphical apps.
https://bugzilla.gnome.org/show_bug.cgi?id=679342
This gets the current cell area of a particular item. Its similar
to gtk_tree_view_get_cell_area().
The code is extracted from gtk_icon_view_set_tooltip_cell which now
just calls the old code.
https://bugzilla.gnome.org/show_bug.cgi?id=678418
As used in Totem and gnome-contacts. The widget
takes either a GtkMenu or a GMenuModel to construct
its menu, and can be given a parent widget to use to
position the drop-down (as used in GtkMenuToolButton).
https://bugzilla.gnome.org/show_bug.cgi?id=668013
See inline comments for what it does. Its main use is figuring out if
something has been caused by GTK's caching of CSS properties or if it's
a different problem.
Kinetic scrolling is only done on touch devices, since it is
sort of meaningless on pointer devices, besides it implies
a different input event handling on child widgets that is
unnecessary there.
If the scrolling doesn't start after a long press, the scrolling is
cancelled and events are handled by child widgets normally.
When clicked again close to the previous button press location
(assuming it had ~0 movement), the scrolled window will allow
the child to handle the events immediately.
This is so the user doesn't have to wait to the press-and-hold
timeout in order to operate on the scrolledwindow child.
The innermost scrolled window always gets to capture the events, all
scrolled windows above it just let the event go through. Ideally
reaching a limit on the innermost scrolled window would propagate
the dragging up the hierarchy in order to keep following the touch
coords, although that'd involve rather evil hacks just to cater
for broken UIs.
