We assume that applications that export a 'new-window' action can open
a new window, so we add an appropriate entry to the context menu.
However this duplicates functionality if the application already
exposes the action via the desktop file - don't add our own entry
in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=744446
This DBus API is intended to be used by gnome-control-center's
displays panel to show monitor labels.
Each output (i.e. hardware monitor) identified by its
org.gnome.Mutter.DisplayConfig API ID has at most one label. On
mirrored setups, all the labels for outputs corresponding to the same
logical monitor (i.e. showing the same contents in the same mode) are
shown together.
At most, only one DBus client at a time is allowed to show labels.
https://bugzilla.gnome.org/show_bug.cgi?id=743744
Because there's nothing (in single-monitor setups) that could
take the drop in this case.
* js/ui/appDisplay.js:
AllView._loadApps(), FrequentView._loadApps(): Pass
an isDraggable parameter when creating the AppIcons,
depending on whether the favorite-apps key is locked.
AppIcon._init(): Check for isDraggable in the params and
do not create _draggable if it was specified, to prevent a
drag from starting.
AppIcon.popupMenu(): Check _draggable before trying to call
fakeRelease on it.
* js/ui/dash.js: Dash._createAppItem(): Check AppIcon._draggable
before trying to connect to its signals.
https://bugzilla.gnome.org/show_bug.cgi?id=741325
In a lockdown scenario, where the favorite-apps GSettings key is not
writable, hide the menu items for adding and removing favorites from the
dash menu. Additionally, reject drops to the dash for DND.
https://bugzilla.gnome.org/show_bug.cgi?id=741325
After the login banner is shown and hidden, the first user
in the user list becomes non-reactive. This is because the
banner is given an opacity of 0, but still allocated.
This commit fixes that by hiding the banner explicitly.
https://bugzilla.gnome.org/show_bug.cgi?id=743370
Normally when a user uses the login screen to log in, the
login screen gets killed and the user session takes over
the display.
This doesn't happen for wayland sessions, though. Instead,
the login screen gets reset, and the wayland session is started
on another VT.
The greeter proxy object needs to be recreated after this reset,
since it's associated with state no longer coupled to the login
screen after the reset.
This commit moves greeter proxy creation to happen at reset time.
https://bugzilla.gnome.org/show_bug.cgi?id=743371
The code described by the comment was moved away in commit eda27d51,
so it is not misleading at best. It wasn't too useful to begin with,
so kill it off rather than moving it to the correct place ...
When using dynamic workspaces, a new workspace will be appended
when moving a window down to the last (empty) workspace. It makes
sense to extend the behavior in the opposite direction, and prepend
a new workspace when moving a window up from the first workspace.
https://bugzilla.gnome.org/show_bug.cgi?id=665764
New workspaces are inserted by shifting all windows on workspaces
below the insertion position down. As a result, when the new
workspace is inserted before the active one, we end up with
the illusion of a workspace switch. Instead, activate the workspace
on which the windows from the active one ended up.
https://bugzilla.gnome.org/show_bug.cgi?id=665764
We are not supposed to mess around with OR windows, so don't try
to shift them to a different workspace. This fixes a warning with
newer versions of mutter.
https://bugzilla.gnome.org/show_bug.cgi?id=665764
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
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.
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
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.
Correctly computing the ISO week number is tricky and we already
have code in the platform to do it, so just refer its computation
to GDateTime rather than doing it ourselves.
https://bugzilla.gnome.org/show_bug.cgi?id=736722
Using a separate property to show when the application is busy rather
than cramming it into the state property makes the code clearer. In most
places we only care if an app is running or not, not whether it is
actually busy.
https://bugzilla.gnome.org/show_bug.cgi?id=736492
If the user list is disabled and the user clicks cancel quickly enough
after typing their username, they can get in a state where the
auth prompt gets stuck in the insensitive state.
This is because the login dialog code makes the prompt insensitive
while while pam is processing the provided username, but the prompt
only makes itself sensitive again when it is hidden.
This commit makes it sensitive right before asking for a username again.
https://bugzilla.gnome.org/show_bug.cgi?id=740141
Once verification has succeeded, the train's already
left the building and we shouldn't allow canceling.
This commit renders the cancel button non-reactive
and makes the cancel function be a noop after
verification succeeds.
https://bugzilla.gnome.org/show_bug.cgi?id=740141
Due to a typo we were always removing the first (index 0) connection
from the global list of connections instead of the correct one.
This resulted in some connections remaining in the shell's connection
list long after they were removed. In particular, this resulted in
multiple copies of a bluetooth connection appearing after suspend/resume
(when the device was readded and the cached connection list was
rescanned).
https://bugzilla.gnome.org/show_bug.cgi?id=740227
I was going to add another DBus property to signal when the shell was
done loading and was idle, and while implementing that I noticed we
aren't emitting PropertyChanged for, well, any property. Let's fix
OverviewActive.
It's unfortunate it's so tedious to correctly implement a DBus
property =/
https://bugzilla.gnome.org/show_bug.cgi?id=704163
Currently, shellDBus only uses the passed in monitor index if it's
strictly > 0. A zero-index monitor is a valid one though, so don't
restrict this to strictly positive indices.
https://bugzilla.gnome.org/show_bug.cgi?id=740074
