DND of windows has a lot of side effects, including the possibility of
current workspace disappering from under our feet. We need to account
for that when trying to activate it.
https://bugzilla.gnome.org/show_bug.cgi?id=685285
This happens in the case of Workspace/WorkspaceThumbnail: they call
meta_window_change_workspace_by_index(), which fires window-removed
on the old workspace, thus destroying the window clone.
https://bugzilla.gnome.org/show_bug.cgi?id=685285
Windows can be restacked at any time, including when the stackAbove
property of the window clone is being dragged, and thus parented to
the uiGroup. To do stacking properly, we need to skip it for the duration
of the drag, and sync it again at the end (which is already done by
mutter because of the workspace change)
https://bugzilla.gnome.org/show_bug.cgi?id=685285
ClutterBinLayout uses the maximum width/height of all children in
size requests and positions children according to the expand/align
properties. This means that the vertical position of folder popups
is not considered in size requests, so if the main view is smaller
than a folder popup's height and offset, the popup will be truncated
and/or mispositioned. Fix those cases by using a custom LayoutManager
that behaves like ClutterFixedLayout for height requests and like
ClutterBinLayout otherwise.
https://bugzilla.gnome.org/show_bug.cgi?id=694371
The login dialog has a maximum height set to prevent the user list
from growing indefinitively. However this approach fails if the
monitor height is smaller as said maximum, so add some additional
top/bottom padding to make sure there's some whitespace above/below
the user list in that case as well.
https://bugzilla.gnome.org/show_bug.cgi?id=685851
Commit 7b3a689aad changed the border-radius of the hover effect
to match the prelight effect, but not the focus indication, so
the focused item now changes corners on hover. Fix this by using
a consistent border-radius.
https://bugzilla.gnome.org/show_bug.cgi?id=691578
We need to look at the duration of the current step of the slideshow
to determine when to next queue an event, rather than the full slideshow
duration.
https://bugzilla.gnome.org/show_bug.cgi?id=695882
Due to weird and strange JS scoping semantics, if we are in a
callback, "i" won't be captured and when the callback is called,
we'll have the wrong index, causing addImage to be called instead
of updateImage.
https://bugzilla.gnome.org/show_bug.cgi?id=695882
The pattern is underneath, so we need to add one. It turns out
that ClutterGroup doesn't care about that, but we need to do this
to remove deprecations in mutter.
https://bugzilla.gnome.org/show_bug.cgi?id=695882
To make sure that the screen shield is shown before suspending, we
take a logind inhibitor and release it when the screen shield is
shown. As the screen shield is not only shown on suspend, we can end
up releasing the inhibitor independently from suspending (lock, idle),
in which case the screen might not be locked when we do suspend.
To fix, only release the inhibitor after showing the screen shield
when we are about to suspend.
https://bugzilla.gnome.org/show_bug.cgi?id=693708
Since commit 7cdb75e7ce, initializing UI is deferred until the session
mode has been loaded. However DBus is still initialized immediately,
which means that for DBus methods that access properties in Main, there
is now a window between the method being exposed on the bus and the
method being ready to be called. At least g-s-d grabbing global keybindings
is likely to fall in this window on session startup, and almost guaranteed
when regrabbing bindings after a shell restart.
To fix, defer initializing DBus as well.
https://bugzilla.gnome.org/show_bug.cgi?id=694321
When we switch into an invalid input source we hide the panel
indicator and return early but we were not hiding the previously
active source label and its menu item dot and thus when switching
again to a third input source we would end up showing 2 overlapping
labels in the panel and the menu would have 2 entries with a dot.
https://bugzilla.gnome.org/show_bug.cgi?id=695841
It's possible in some corner cases for the status of the topwindow
to change and make it not fullscreen without ::restacked being
changed. One way that it could happen with the old code was if the
layer of the top window changed from NORMAL to FULLSCREEN.
Change the logic not to look at the layer, which is a function of
Mutter's *intended* stacking, rather than the *actual* stacking,
which is what ::restacked gives you. Instead, look at the top
portion of the stack, down to the first non-override-redirect
window, and see if their are any monitor-sized windows there.
Connect to changes on the top portion of the stack, so we know
if conditions change.
https://bugzilla.gnome.org/show_bug.cgi?id=649748
We always add external DOCK windows to the ctrl-alt-tab switcher,
e.g. separate dock applications or nautilus' desktop windows.
Since commit 1f46a0dc26, all items in the switcher are expected
to set a proxy parameter, but the aforementioned code was not
updated accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=695395
* Prompters have state, and cancelling an already prompter will
cause prompts that are in progress to fail.
* In addition allow replacement of our shell prompter for debugging
purposes.
https://bugzilla.gnome.org/show_bug.cgi?id=695485
notify::* doesn't guarantee that the value has changed, only that it
may have been. We need to ensure that we track the old value to make sure
we don't do things like overwrite timeouts if they already exist.
https://bugzilla.gnome.org/show_bug.cgi?id=695659
Now that the tray is modal, the summary is tied to the tray,
and we don't need to have separate states for the tray and
summary. This also removes the nearly invisible opacity tween
on the summary items when opening the message tray.
https://bugzilla.gnome.org/show_bug.cgi?id=695659
The only way that locking happens is with when the summary box
pointer is active. As it can only happen if the summary state
is active, it's impossible for a notification to be expired,
or the summary to be hidden while it's showing.
https://bugzilla.gnome.org/show_bug.cgi?id=695659
It makes more sense to use the monitor the tray is on, rather than the
primary monitor. This also matches us with whether we can open the tray
from a barrier/dwell or not.
https://bugzilla.gnome.org/show_bug.cgi?id=695659
We may release the focus grab at any time, so it's not guaranteed
we'll be in event processing. In particular, hovering over and out
of a notification will cause this to happen, as the notification
is hidden on a timeout.
https://bugzilla.gnome.org/show_bug.cgi?id=695659
