Gdk uses Xwayland, so it only sees the events we forward to X11
clients. Instead, we can use the abstraction API provided by
mutter and get the right value automatically.
Also, we need to use MetaCursorTracker to handle the cursor
visibility too.
https://bugzilla.gnome.org/show_bug.cgi?id=707467
We need to call into MetaScreen to set the cursor, but we can't
do that from libst, so add a hook that libgnome-shell can fill,
and remove more ClutterX11 usage.
https://bugzilla.gnome.org/show_bug.cgi?id=707467
When running as a wayland compositor, the clutter stage doesn't
have an usable window for IPC, so just create another one.
Also, disable freezing the keyboard when running on wayland, as
we can't do it really.
https://bugzilla.gnome.org/show_bug.cgi?id=707467
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
