We will soon allow to insert a new workspace by other means than
DND in between workspace thumbnails, so move the relevant code
to a new windowManager method.
https://bugzilla.gnome.org/show_bug.cgi?id=665764
Input method preedit text needs to be disabled on password entries
for security and usability reasons.
IBus 1.5.7 provides the signal set-content-type so that panel UIs can
handle these special purpose input entries:
https://github.com/ibus/ibus/commit/6ca5ddb302c9
Unfortunately IBus versions older than 1.5.10 have a bug which causes
spurious set-content-type emissions when switching input focus that
temporarily lose purpose and hints defeating its intended semantics
and confusing users. We thus don't use it in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=730628
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
