The window clones in the central part of the overview are showing modal
dialogs now, and this creates an inconsistency if the thumbnail doesn't too.
Code is intentionally similar in the two places.
https://bugzilla.gnome.org/show_bug.cgi?id=650843
Windows in the overview should be like they appear in the workspace,
including modal dialogs that are attached above them.
In addition, hiding the dialogs in the overview causes a flash as
dialog appears at the end of the transition.
Based on a patch by Maxim Ermilov <zaspire@rambler.ru>
https://bugzilla.gnome.org/show_bug.cgi?id=650843
Curently it is possible to copy the content of password entries,
and paste it elsewhere in clear text. This is undesirable, so
follow GTK+'s behavior and disable the copy action for password
entries.
https://bugzilla.gnome.org/show_bug.cgi?id=695104
We always leave the workspace switcher zoomed out when we can assume
that the user is actually making use of workspaces. For the default
dynamic workspace behavior, we make this assumption when more than
two workspaces are in use (e.g. at least two workspaces contain windows
plus an empty one at the end). However this test does not make sense
when using static workspaces - in that case, not using workspaces
would be indicated by a workspace number of 1 (in which case the
entire switcher is hidden completely), so add a check for dynamic
workspaces to the condition.
https://bugzilla.gnome.org/show_bug.cgi?id=695126
Currently both the app switcher and the thumbnail list divide items
first into two groups (based on whether the item is located on the
current workspace or not), and then sort each group individually
by MRU.
The resulting behavior is often confusing, e.g. when using alt-tab
a second time does not switch back to the original window when the first
invocation involved a workspace switch and the workspace contains
windows of more than one application.
Instead, make the behavior more predictable by sorting both lists
strictly by MRU.
https://bugzilla.gnome.org/show_bug.cgi?id=661156
Shell modal dialogs can take their action on a certain key's
key-release-event. For example on <enter> the affirmative action is
usually run.
Make sure that the key was also pressed on the dialog and we're not
seeing a spurious key-release-event from a key that was pressed before
the dialog was displayed.
https://bugzilla.gnome.org/show_bug.cgi?id=692937
It is possible that a session survives after closing, if any processes
(usually PulseAudio and GConf) are still alive at the end. In that case,
ignore it, as the user is already logged out and there is nothing to lose.
https://bugzilla.gnome.org/show_bug.cgi?id=695002
Implement a basic OSD popup that shows an icon and optionally a label
and a fill level. It is based on the existing OSD implementation in
gnome-settings-daemon, which it will replace.
https://bugzilla.gnome.org/show_bug.cgi?id=613543
Right now we take a still frame of the desktop before showing the
start up animation. This gives us an animation over what was
there before startup.
That's not actually desirable when restarting the shell. We don't
want to animate over undecorated windows, we really want to animate
over the noise texture.
This commit drops the still frames in favor of the noise texture.
https://bugzilla.gnome.org/show_bug.cgi?id=694326
Previously, the overview BoxLayout was sized and positioned explicitly
using the primary monitor coordinates, as its parent was at 0,0 and
with a fixed layout manager. Now we use a bin layout, so we need to
position and size the stack actor, and set the overview boxlayout to
expand.
Take also the occasion to use a MonitorConstraint instead of handling
position and size manually.
https://bugzilla.gnome.org/show_bug.cgi?id=694969
We used to clip the overview group to prevent the dash from sliding into
neighbor monitors, but now it moved to the groupStack, so we must move
the clip too.
https://bugzilla.gnome.org/show_bug.cgi?id=694970
This filters out resident and transient notifications in the normal
case, but just returns the number of unread messages for the Telepathy
implementation.
https://bugzilla.gnome.org/show_bug.cgi?id=687787
We generally want view content centered, in particular where the
view itself is symmetrical. So move the dash to a separate layer
and use a placeholder to account for its size when showing the
window picker, which is the only view where it doesn't make sense
to center the content.
https://bugzilla.gnome.org/show_bug.cgi?id=694261
Commit 43ed66cf26 changed the toplevel overview actor, so it
makes sense to change the show/hide transitions to use that instead
of the existing group, to avoid elements layered on top of the
group being excluded from the transitions.
Windows can sometimes be focused, or appear to be focused, without being
at the exact top of the stack, for example in the case of override-redirect
windows, or with attached modal dialogs. In that case, we should not
try to minimize them (as it creates a loop that makes it impossible to restore
the window)
https://bugzilla.gnome.org/show_bug.cgi?id=694905
Mutter now makes session registration an explicit required
step. This is so we can tell the session manager when
we're ready to move on to the next phase.
This commit calls the new Meta.register_with_session() api after we're
initialized.
https://bugzilla.gnome.org/show_bug.cgi?id=694876
"description" is documented as a valid field for search result metas,
and ListSearchResults implements it, so pass it down to be used.
Also, don't wrap the description in quotes, so that the search provider
can decide if it is an excerpt from the searched text or something else.
And to that extent, set use_markup to true, so that terms can be
highlighted.
https://bugzilla.gnome.org/show_bug.cgi?id=694906
This can happen if you open two or three terminal windows, and then
open the overview -- they're not centered. The issue is that because
of the WINDOW_CLONE_MAXIMUM_SCALE clamping, the scale that is being
laid out is different from the scale that the layout was calculated
for.
Implement and document a hack-ish solution which simply keeps the
scale for the layout as originally calculated, but centers the
windows inside the cell.
https://bugzilla.gnome.org/show_bug.cgi?id=694902
Multiplication is linear, so we can split this out as a separate
component. This will make it easier to think of it as an additional
per-window scaling factor, rather than tweaking the scale a bit,
which is more correct to the model.
https://bugzilla.gnome.org/show_bug.cgi?id=694902
While we won't tear down the entire strategy infrastructure, we want to
rework some layout code in the future, so just tear this piece out for
now.
https://bugzilla.gnome.org/show_bug.cgi?id=694902
gnome-shell-extension-prefs supports opening a specific extension's
preferences directly from the command line by passing the UUID.
However this broke when extension loading was changed to be processed
asynchronously, as no extension has been loaded when the command
line argument is processed. Fix by deferring opening the extension's
preferences until all extensions have been loaded.
https://bugzilla.gnome.org/show_bug.cgi?id=694858
Some of the conditions for showing the user list were not
properly inverted, causing the session list to be hidden
when it shouldn't be and shown when it shouldn't be.
https://bugzilla.gnome.org/show_bug.cgi?id=694784
As a special-case to the "cap event" rules, this allows a heavy swipe
from top to bottom to allow triggering the tray without having to push
into it.
https://bugzilla.gnome.org/show_bug.cgi?id=694467
When pressing against the bottom of the screen, we shouldn't
really take more than 15px from each event, to prevent spruious
mouse movements from opening the barrier.
https://bugzilla.gnome.org/show_bug.cgi?id=694467
gnome-settings-daemon will be changed to override the XSetting in
the case where we're on a remote display rather than overwriting a
user setting, so we need to look at the XSetting here.
https://bugzilla.gnome.org/show_bug.cgi?id=694320
