Currently we have been using the vp8 codec because it was the best unencumbered codec at that time. With vp9 we now have a successor that leads to smaller
files at at the same video quality and has been supported by current browsers
for a while.
With the raise of hidpi and 4K displays we need a better codec that handles
those resolutions better, so switch to vp9.
https://bugzilla.gnome.org/show_bug.cgi?id=742744
We check for (metasNeeded.length == 0) at the beginning of the function,
which is only ever called when when a non-zero number of results is
received back from the provider. Effectively, this means that
(metas.length != metasNeeded.length) will also catch (metas.length == 0)
and print a nicer message to the log.
The updateSearch() function is called in SearchResults every time new
search hits are available from a search provider; SearchResults will
wait for updateSearch() to complete in a callaback, to update the
overall progress of the search operation.
updateSearch() will call _ensureResultActors(), which will in turn call
getResultMetas() on the search provider, which is an operation that can
fail arbitrarily or return inconsistent data, as it's entirely in the
hands of the search provider.
In case _ensureResultActors() returns a failure, updateSearch() is
currently failing to notify the passed-in callback, which might leave
SearchResults in an inconsistent state: make sure the asynchronous flow
always ends up with a notification to the updateSearch() callback.
So that we'll recreate it the next time we want to show it. Otherwise,
we'll try to call things on a half-destroyed ResizePopup and end up
causing errors instead of showing the user their resize popup.
The lookup table used by get_app_from_window_pid contained only pids of
apps launched by gnome-shell itself, but not pids of apps running before
gnome-shell was (re-)started. Also the pids in that table might not even
be the pid of the process that is actually showing the window if wrapper
scripts are used.
Instead use shell_window_tracker_get_app_from_pid which uses the pids
from the windows themselves.
This removes the only use of launched_pid_to_app which will be removed
in the following commit.
This fixes: https://bugzilla.gnome.org/show_bug.cgi?id=736527
This will allow g-s-d to handle actions differently based on the
current mode - namely, allow the power button when locked, but
make sure to never show any dialogs in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=711682
Adding new parameters to the signal currently will break keybindings
until gnome-settings-daemon is updated to the new API as well.
Put additional parameters into a dictionary instead to make future
extensions easier.
https://bugzilla.gnome.org/show_bug.cgi?id=711682
When animating workspace switches, windows on the old and new workspaces
are temporarily reparented. If windows are restacked, those windows will
thus be ignored by mutter until meta_switch_workspace_completed() resyncs
the stacking at the end of the animation.
As a result, activating a window on another workspace that is not on top
of the stack is very noticeably a two-step operation of switching workspace
and raising the window. There is a technical reason for that order[0], but
we can avoid the visible disruption by manually syncing the stack during
the switch operation.
[0] https://git.gnome.org/browse/mutter/tree/src/core/workspace.c#n590https://bugzilla.gnome.org/show_bug.cgi?id=741680
Just like keybindings and the message tray pointer barrier, gestures
don't always make sense - for instance, swiping up the screen shield
should not trigger the message tray just as the SelectArea action around
the left edge should not open the overview.
To avoid this, restrict gestures based on the current keybinding mode.
https://bugzilla.gnome.org/show_bug.cgi?id=740237
Frequently banner messages are longer than can reasonable
fit in a one column view, which leads to a smooshed layout.
This commit changes the layout to a two column view, with the
banner on the left and the prompt on the right, if the banner
message is long enough that it can't fit well above the prompt.
If there isn't enough space for two columns then we keep the
one column layout but add scrollbars.
https://bugzilla.gnome.org/show_bug.cgi?id=703972
The login screen supports showing a banner message which admins
can use to mention login rules or disclaimers.
This message only shows up currently if the user list is enabled.
Most people who want to show a banner message also want to disable
the user list.
This commit moves the banner message to display when the user is
prompted for login credentials instead of when showing the user
list. It also adds a scrollbar if the message is too long.
https://bugzilla.gnome.org/show_bug.cgi?id=703972
The login screen is pretty custom full screen container and the standard
layout managers aren't really a good fit for the kind of layout that's
happening. This will be even more problematic with upcoming changes
to login banners, so we need to switch techniques.
This commit moves login dialog over to using a custom allocate handler
that has specific domain knowledge of the parts of the login screen
and where they go.
https://bugzilla.gnome.org/show_bug.cgi?id=703972
In certain cases the timeout for starting the calendar helper can
be reached but the calendar helper still loads fine. If so, just
ignore the timeout and wait until we get a notification from
dbus of the successful start.
https://bugzilla.gnome.org/show_bug.cgi?id=735308
g_dbus_proxy_new() (and library calls that wrap it) has an hardcoded
timeout of 25 seconds, which is insufficient for starting up e-s-r
in certain setups. Avoid a timeout error by starting the service
manually with a longer timeout before hand.
Also demote the error to a warning + exit failure instead of
a crash, to avoid triggering abrt reports.
https://bugzilla.gnome.org/show_bug.cgi?id=735308
Themes - namely the HighContrast one - may now request symbolic
icons rather than fullcolor ones. In order to have recoloring
work as expected in that case, we will need a theme node to pick
up colors from - using an StIcon instead of manually loading a
texture from the cache gives us that for free, so do that.
https://bugzilla.gnome.org/show_bug.cgi?id=740447
GTK+ added support for a -gtk-icon-style property in themes to
enforce a particular icon style. Do the same for shell themes
with an -st-icon-style property, with the same set of possible
values as the GTK+ variant:
'requested' - use symbolic or fullcolor icon depending on the
icon name (default)
'regular' - enforce fullcolor icons
'symbolic' - enforce symbolic icons
https://bugzilla.gnome.org/show_bug.cgi?id=740447
The split between st_texture_cache_load_gicon() and load_gicon_with_colors()
no longer makes any sense, so just move the code into the public method.
https://bugzilla.gnome.org/show_bug.cgi?id=740447
While the default Shell style is fairly decent with regard to
accessibility requirements, having the ability to tweak certain
aspects where the regular style works less well is still useful.
For this purpose, try to load a -high-contrast theme variant of
the default stylesheet when a high-contrast theme is requested
(as determined by the GTK+ theme name).
https://bugzilla.gnome.org/show_bug.cgi?id=740447
_hideDone checks _shown to determine if anything has shown the overview
while we hid it, and if so, shows the overview forward just in case.
In a local patch that called _hideDone immediately inside _hide for
testing, this broke. While we don't actually depend on this anywhere,
it doesn't hurt so that the next person to hack this up (perhaps me!)
doesn't get stuck debugging it for 20 minutes.
Since moving to a GFile based API in commit 642bf2b778,
setThemeStylesheet() no longer accepts %null to revert to
the default theme. We should have some way to revert to the
default and the least intrusive option is to return to the
old behavior, so do that.
