The window actor shouldn't have been picked since it has an empty
input shape, but bugs in mutter weren't properly interpreting that.
Since the Wayland restructure, the MetaWindowActor isn't actually
reactive anymore, it's the MetaSurfaceActorX11, so this code isn't
doing anything.
It's implemented similar to the padding property, but instead of taking
into account the margin values at drawing time in node-drawing, we set
the clutter actor margins in StWidget when the style is computed.
In the case that a CSS margin is not specified, we don't to set a value
of 0 to the clutter actor margin. In this manner it allows to use
Clutter margin values set in the code. However, the margins that are set
both in the code and in the CSS on the same side, the result is
unpredictable.
We avoid to set the clutter actor margin values to 0 if there's no CSS
margin values defined, so we still allow clutter actors to use margin
set in the code.
https://bugzilla.gnome.org/show_bug.cgi?id=728437
GTK+ added a new PolicyType which currently triggers compiler warnings
about unhandled values in switch statements. We also have a use case for
it already, so add support for the new policy type.
https://bugzilla.gnome.org/show_bug.cgi?id=739379
We commonly mark strftime format strings for translation to account
for date/time representations without an existing strftime shortcut
("Yesterday %H%p"). As those translations are looked up according to
the locale defined by LC_MESSAGES, while the conversion characters
themselves are resolved according to LC_TIME, the result can be
rather odd when mixing locales ("Den 27. January"). The correct
solution would be to install translations for format strings in
the LC_TIME catalogue and look them up with dcgettext(), but we
don't have the infrastructure to do that easily. Work around this
by adding a helper method that looks up a string in LC_MESSAGES
using the locale defined by LC_TIME and use that to translate
format strings, which has the same result.
https://bugzilla.gnome.org/show_bug.cgi?id=738640
The pointer to ->accessible was cleared too early in dispose, which
resulted in another accessible object being created when the actor
was removed from its parent in clutter_actor_dispose(). Use a
weak reference instead to clear the ->accessible pointer.
https://bugzilla.gnome.org/show_bug.cgi?id=738147
Wayland applications don't tend to have very useful WM Class properties,
as GTK+ isn't very good at picking an appropriate application ID. While
we should likely fix GTK+ to pick a better app ID, we do have the
existing gtk_shell for more accurate information. The only problem is
that the gtk_surface is set after the MetaWindow is constructed, and
we're not listening for changes on the GTK+ application ID.
Listen to changes on the GTK+ application ID to fix app tracking for
most GTK+ applications under Wayland.
We currently allow infinite number of screenshot requests to be active at
the same time, which can "dos" the system and cause OOM.
So fail subsequent requests for the same sender when a screenshot operation
is already running.
https://bugzilla.gnome.org/show_bug.cgi?id=737456
These keybindings are well-established on the CLI (e.g. "kill-line"
and "unix-line-discard" in readline(3)), and adding support for them
is cheap ...
https://bugzilla.gnome.org/show_bug.cgi?id=737346
All current code assumes that the list of window actors corresponds to the
list of windows; however as the list returned by meta_get_window_actors()
now includes actors during the destroy animation, that assumption breaks.
Eventually we should make everyone move to a more appropriate API, but
for now make it work again by returning a filtered list of "good"
window actors.
https://bugzilla.gnome.org/show_bug.cgi?id=735927
Performance testing was producing inconsistent values at different
times in the day since the GNOME default background is animated and
sometimes has a single layer, and sometimes two blended layers.
So we have consistent numbers, install a simple animated background
with GNOME Shell that has 40-year long transition ending in 2030,a
and set an environment variable in gnome-shell-perf-tool so that the
background is override with that background. (The background depends
on files installed by gnome-backgrounds; we assume that the person
running performance tests is doing so within the scope of a full
GNOME install.)
https://bugzilla.gnome.org/show_bug.cgi?id=734610
If the application reports itself as single window (through
an explicit indication in the desktop file or some heuristics),
not show a "New window" item that doesn't actually open a new window.
https://bugzilla.gnome.org/show_bug.cgi?id=722554
Add a --hwtest option to gnome-shell-perf-helper which runs the
tests in perf/hwtest.js with the appropriate environment, and then
logs the results using the 'gnome-hwtest-log' utility which is
available in the hardware testing environent.
(For development of hwtest.js in a normal environment, run the tests
as: gnome-shell-perf-tool --perf=hwtest --extra-filter=Gedit)
https://bugzilla.gnome.org/show_bug.cgi?id=732350
It's useful to know how long frames are taking to render on the GPU.
This is impossible to measure in the normal case because frames may
parallelize with previous frames, but by calling glFinish() at the
end of the frame, we can create a (somewhat artificial, but useful)
environment where we have a meaningful timestamp for the frame
finishing drawing.
https://bugzilla.gnome.org/show_bug.cgi?id=732350
Instead of always logging frame timestamps for every frame - which
was using >26 bytes of memory per frame, or 5MB per hour of continuous
redrawing - make frame timestamps something that defaults off and is
turned turned on using a new ShellGlobal::frame-timestamps property by
the perf scripts.
https://bugzilla.gnome.org/show_bug.cgi?id=732350
Add an option for windows created with Scripting.createTestWindow()
to continually redraw themselves; this is for testing performance
of application updates.
https://bugzilla.gnome.org/show_bug.cgi?id=732350
