We may get a NULL region passed to the backend, which means
'nothing is opaque'. In that case, don't crash, but pass
the information on to the compositor.
http://bugzilla.gnome.org/show_bug.cgi?id=709854
Rework how accels are handled on GtkApplicationWindow.
Instead of having GtkApplication fill the GtkAccelMap which is then used
by GtkApplicationWindow to create a GtkAccelGroup filled with closures
that is then associated with the window, do it directly.
GtkApplication now keeps a list of accels and their actions.
Accelerators on a GtkApplicationWindow ask GtkApplication to execute the
appropriate action.
This saves a fair bit of complexity and memory use (due to not having to
create all those closures and accelmap entries). The new approach also
supports multiple accels per action (although there is not yet a public
API for it).
This patch (and the ones before) Reviewed and ACK'd by Matthias Clasen.
Add support for pulling the primary accel out of the GtkActionMuxer.
With this change, it is no longer necessary to have the accel=''
attribute hardcoded onto each menu item (and, in fact, it should be left
off if you intend to have support for dynamic accelerator changing).
Specifying accel='' is a good way to force an accelerator not to be
displayed on a menu item.
Store "action and target" format inside each GtkMenuTrackerItem. This
makes action invocation more efficient (no hash table lookups or
allocations) and slightly simplifies handling of action namespace.
More importantly, this will be used when we start to get accels from
GtkActionMuxer.
Reuse the existing infrastructure in GtkActionMuxer for propagation of
accelerator information: in particular, what accel label ought to appear
on menu items for a particular action and target.
This is a good idea because we want accels to travel along with the
actions that they're tied to and reusing GtkActionMuxer will allow us to
do that without creating another hierarchy of a different class for the
sole purpose of filling in accel labels on menu items.
Doing it this ways also allows those who copy/paste GtkActionMuxer to
insert the accels for themselves.
Add a new method on the GtkActionObserver interface to report changes.
This patch introduces a new concept: "action and target" notation for
actions. This format looks like so:
"'target'|app.action"
or for non-targeted actions:
"|app.action"
and it is used over a number of possible alternative formats for some
good reasons:
- it's very easy to get a nul-terminated action name out of this format
when we need it, by using strrchr('|') + 1
- we can also get the target out of it using g_variant_parse() because
this function takes a pointer to a 'limit' character that is not
parsed past: we use the '|' for this
- it's extremely easy to hash on this format (just use a normal string
hash) vs. attempting to hash on a string plus a GVariant
A close contender was to use detailed action strings here, but these are
not used for two reasons:
- it's not possible to easily get the action name or target out of the
strings without more work than the "action and target" format
requires
- we still intend to use detailed action strings on API (since they are
a lot nicer to look at) but detailed action strings can be given in
non-canonical forms (eg: 'foo::bar' and 'foo("bar")' are equivalent)
so we'd have to go through a normalisation step anyway. Since we're
doing that already, we may as well convert to a more convenient
internal format.
This new "action and target" format is going to start appearing in a lot
more places as action descriptions are introduced.
I suspect that nobody is using '|' in their action names, but in case I
am proven wrong, we can always switch to using something more exotic as
a separator character (such as '\x01' or '\xff' or the like).
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.
With the stock system being deprecated now, we should provide
meaningful accessible names for buttons that are constructed
from icon names or GIcons. This commit reuses the existing
translations.
It is possible that some common icon names are not covered
here because they were not present as stock items. These can
be added to the table later.
Discovered via a crash because b's (dest's) toplevel was NULL;
ensuring that the dest is actually a GdkWindow or setting b to NULL
prevents that path from being taken.
Spinners are essentially animated symbolic icons. We don't really
want them being rendered to arbitrary sizes. Also the current
technique for rendering the activity is not suitable for larger
sizes. Until we have a better technique we should limit the size
to the MENU icon size or exactly twice that size.
The 'direction' parameter to gtk_widget_keynav_failed() is based on
gtk_list_box_move_cursor()'s 'count' parameter. However if the passed
in movement is GTK_MOVEMENT_DISPLAY_LINES, 'count' is modified by
the keynav handling and will always be 0. To avoid messing up the
'direction' parameter, use a local variable for keynav handling and
leave 'count' untouched.
https://bugzilla.gnome.org/show_bug.cgi?id=709687
Previous commit wrongly identified "active" as containing the new
value. Instead, applications must determine the new value to
update the model with manually based on the value currently in the
model.
Clarify that applications are expected to handle updating the model
from the 'active' property, like GtkCellRendererText does for the
'edited' property.
This test demonstrates that various deprecated ways
to construct buttons and menuitems still work as they
are supposed to, including always-show-image functionality.
If a range goes all the way to the edge of the screen then we don't
have any way to activate autoscrolling. By adding a small region
at the ends of the range we can handle this case. This is the same
approach used in treeviews.
If we're going to run off the end due to an invalid message,
we're going to run off the end. We'll protect this by doing
proper bounds checking in the future, but the malloc gives
us nothing for now.
