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
We currently replay events that should start a search to the search
entry, which is fairly dodgy. Synthesize a new event with the correct
source actor instead, which is a bit less evil.
If an active grab on pointer events happens during multi-touch operations,
all non-pointer-emulating touches will be muted. This may leave the
Clutter.ClickAction incomplete if triggered by one of those sequences,
just to have a gesture take over and trigger a compositor grab, which would
leave the capture-event handler stuck eating events.
So listen for grab-op-begin from the display, and ensure the action is
released if such grab begins.
and the capture event handler stuck.
When returning to the desktop from overview we always show the
workspaceDisplay, given that is which have the windows clones to allow
animations.
The problem becomes when previous that we were at some other
page, like Search or AppDisplay. The problem is that when showing the
workspaceDisplay the windows are repositioned. That's wanted except
when returning from overview, since that causes unwanted animations
of the windows.
To avoid that just not reposition the windows if leaving the overview.
We don't normally hit the code in scripting.js to print metrics
because shell-perf-tool bypasses it, but there was a left-over
in the code that no longer works. Also add in the units to the
output.
https://bugzilla.gnome.org/show_bug.cgi?id=732349
If reusing an existing separate builddir, the generation of dependencies
for the JS resource file would fail because it couldn't find misc/config.js,
resulting in the resource file not being regenerated.
https://bugzilla.gnome.org/show_bug.cgi?id=732348
Listen to changes in connectivity, and ask our helper to authenticate
when needed.
We don't have a URL to connect to yet (we will have when
the new NM API lands), so we use the default of trying
www.gnome.org (which is also more reliable because we can
recognize when the login is done)
https://bugzilla.gnome.org/show_bug.cgi?id=704416
Add a small DBus-activated GtkApplication that embeds a WebKitWebView
and implements some minimal logic to see if the login succeeds.
It will try to connect to a custom NM-provided url (the portal login
page), if one exists, or to www.gnome.org in the normal case of
a portal doing redirect.
https://bugzilla.gnome.org/show_bug.cgi?id=704416
Icons inside the menu are updated only for device state change,
but for the main device they also depend on connectivity (which
is a global property).
Add a public method to force an update of the icon, and call it
when connectivity changes.
https://bugzilla.gnome.org/show_bug.cgi?id=726401
They are different properties, they deserve different syncs.
Especially because a full allocation cycle sets both anyway, so
we should save some cycles this way.
https://bugzilla.gnome.org/show_bug.cgi?id=729823
We already have the width and height information cached in JS,
let's avoid going through gjs-gobject-clutter to retrieve them
again. As a plus, with normal properties the optimizer should
be able to generate better code.
https://bugzilla.gnome.org/show_bug.cgi?id=729823
We must remove the old image from the cache, not the new one.
This was causing a leak of old (and expensive) background
images, and was causing errors at the end of animations, trying
to destroy the animated background.
We translate 'On' to available accuracy level but if available accuracy
level later changes, we don't update available accuracy level accordingly
and hence limit the accuracy of apps.
E.g if available accuracy level is 'city' and geolocation is enabled,
the max accuracy level would be 'city' and apps can't get higher than
that. Now if user plugs in GPS, the available accuracy level will change
to 'exact' but without this patch max accuracy level will remain to be
'city' and apps will not be able to use the GPS.
https://bugzilla.gnome.org/show_bug.cgi?id=731882
