I thought that cancelDrag was called for completed drags as well,
but it's not. Move the updateHoverId source removal to dragComplete.
This fixes "this._dragActor is undefined" warnings after completed
drags.
https://bugzilla.gnome.org/show_bug.cgi?id=707935
For extremely silly reasons with how the class framework works, the wrapper
method requires "this" to be bound in order for it to work, or else we'll
emit errors in strict mode.
https://bugzilla.gnome.org/show_bug.cgi?id=707892
It is expected that the primary and secondary icons in entries
change places in RTL locales. When doing so, the edit-clear
icon must be replaced by an rtl variant too.
http://bugzilla.gnome.org/show_bug.cgi?id=705779
The Mutter plugin manager has now been changed so that it itself will
pass on the events through Clutter so there is no need to do this in
Gnome Shell anymore.
https://bugzilla.gnome.org/show_bug.cgi?id=707467
Before, separators naively checked whether their siblings were visible
using actor visibility. However, if section actors are visible but have
no visible children, this will fail. Special-case separators when doing
visiblity checks.
https://bugzilla.gnome.org/show_bug.cgi?id=707801
When we show(), we need to make sure that the hiding animation
doesn't reach the end, otherwise we would hide the actor but
still have _visible = true.
We were relying on tweener overwriting to do this, but it
doesn't quite work, so better be explicit and do it ourselves.
https://bugzilla.gnome.org/show_bug.cgi?id=707814
In the commit 9a8bf3b was changed the background opacity of overview
icons. That cause that the shadow of the checked state of icons
was too hard, so it seems to be cut off.
Change the opacity of the shadow to solve this.
shell_app_compare() (which is only used as sort function for
shell_app_system_get_running() nowadays) currently takes the
visibility of an app's windows into account, e.g. applications
with visible windows (non-minimized windows on current workspace)
sort earlier than applications without.
This translate traditional window-switcher behavior to applications,
but we stopped sorting by workspace in the app-switcher a while ago,
and with the new auto-minimization behavior of fullscreen windows
it is more confusing than helpful - in fact, since mutter commit
7e61ef09369a we no longer do this for the window list, so it
makes sense to apply the same to application sorting.
https://bugzilla.gnome.org/show_bug.cgi?id=707663
Just as we do in AllView, we set the offset of FolderViews' fade
effect so that no icon is faded when a full page is visible.
This works fine in AllView, however in the FolderView case where
the popup's offsets eat away from the available fade height, the
effect ends up being barely noticeable at all.
While it is not ideal to apply the fade to the edge of a "full page",
it looks less ugly than the current state, so pick the lesser evil ...
https://bugzilla.gnome.org/show_bug.cgi?id=707662
If a folder view is scrolled, its scrollbar ends up too close to the
content (even partially overlapping it) with the current padding.
Making it much smaller fixes the issue without affecting the content
position - the removed padding will just move to IconGrid's dynamic
padding.
https://bugzilla.gnome.org/show_bug.cgi?id=707662
In specific cases, GTK+ does not have enough information to set a correct
opaque region, in which the recommended fix is to set your window as
app-paintable. In the tray icon case, the socket window was considered
opaque but GTK+ as it had a solid window background, but it cannot have an
opaque region set, as the plug isn't composited against the socket, but
instead punches through the socket window.
https://bugzilla.gnome.org/show_bug.cgi?id=707614
Since now if you focus the indicators, you can't scroll and
change pages in the app picker. That was reported as odd from
some users/developers.
So allow to scroll when the focus is in the indicators.
https://bugzilla.gnome.org/show_bug.cgi?id=707609
A11y users who use the magnifier may have trouble
focusing when they're typing or trying to keynav.
Implement a new system so that they can have the
magnifier track the caret and focus instead instead
of just the mouse.
Bug https://bugzilla.gnome.org/show_bug.cgi?id=647074
