This is the same as the previous commit, but for StEntry.
We don't have any need to explicitly destroy this actor in our dispose
implementation, and doing so breaks the assumption that we can access
the clutter_text from within destroy.
https://bugzilla.gnome.org/show_bug.cgi?id=783483
There's no need to explicitly destroy the ClutterText actor inside the
label; doing so is actually harmful, as it will break the normal
reference cycle between container and children.
As StLabel doesn't hold any extra reference to the ClutterText actor and
just uses clutter_actor_add_actor() to add it to itself, let the normal
container dispose cycle run to dispose of the reference.
https://bugzilla.gnome.org/show_bug.cgi?id=783483
Gjs-Message: JS WARNING: [resource:///org/gnome/shell/portalHelper/main.js 360]: reference to undefined property top.uri
is caused by the URI variable actually being called "url".
https://bugzilla.gnome.org/show_bug.cgi?id=783286
When using an SSH tunnel (through a SOCKS proxy) to funnel all
the outgoing traffic, we need the captive portal to not go through that
proxy, otherwise we can't go through the proxy because we're not
connected to the Internet and we can't go through the portal because
we're not connected through the proxy.
This fixes a blank captive portal window and no error reporting in that
particular configuration.
https://bugzilla.gnome.org/show_bug.cgi?id=769692
The script currently assumes that srcdir is relative to builddir,
which is not the case for build directories outside the source tree
like the one used by jhbuild.
While we could get fancy and prepend the builddir if srcdir is relative,
there's nothing wrong with a relative path as we cd into the builddir
before evaluating srcdir.
https://bugzilla.gnome.org/show_bug.cgi?id=783206
The static library was split out to avoid duplicate compilation
of mutter-independent libgnome-shell sources when we had a
wayland/non-wayland split. With the separate libmutter-wayland
library long gone, there's no reason to make the build more
complicated than it needs to be, so fold libgnome-shell-base
back into the regular libgnome-shell.
https://bugzilla.gnome.org/show_bug.cgi?id=783206
GTK+ switched from ruby-based sass to c-based sassc for performance
reasons. It makes sense to follow suit, if not to not require two
tools for the same job ...
https://bugzilla.gnome.org/show_bug.cgi?id=783210
The .solid style isn't supposed to apply for modes that don't support
windows, but for this to work we have to update the style on session
mode changes.
https://bugzilla.gnome.org/show_bug.cgi?id=783202
Commit b929320d4 added a toolbar item to force garbage collection,
however it won't be visible for most users, as it uses a non-standard
legacy icon name (the default icon theme dropped it as far back as 2009).
https://bugzilla.gnome.org/show_bug.cgi?id=782982
The fullscreen animation code is now generic enough to handle any
size change animations, so stop limiting it to (un)fullscreen to
get animations on (un)maximize as well.
https://bugzilla.gnome.org/show_bug.cgi?id=766685
Currently, the translation values are set with the assumption that
one of the actors represents a fullscreen window. In order to
generalize it for any size change transition, we can simply swap
the monitor rect with the source or target rect as appropriate,
and translate the actor from the target to the source position by
subtracting the former and adding the latter.
https://bugzilla.gnome.org/show_bug.cgi?id=766685
Since there is already targetRect that represents where the
window is going to move, rename oldRect to sourceRect to
represent from where the window is moving.
https://bugzilla.gnome.org/show_bug.cgi?id=766685
If the popup happens to be mapped beneath the pointer, mutter will now
emit an implicit enter notify event (i.e. not caused by pointer motion).
In this case the switcherPopup still goes and selects the item, which
results in too sensitive alt-tab menus if the pointer happens to be in
the wrong place.
Make highlighting rely on motion events instead, so it always involves
user interaction when triggered by the pointer.
https://bugzilla.gnome.org/show_bug.cgi?id=755164
Most of the libsecret API was declared stable in 0.18 and the stable API
now provides everything we need, so switch from libsecret-unstable to
libsecret-1.
https://bugzilla.gnome.org/show_bug.cgi?id=782637
The solid black top bar we currently use works well for maximized
or tiled windows, as it puts focus on the application content by
blending into the monitor bezel. However it also visually reduces
the screen space, which is particularly noticeable when no window
is located nearby. Having the top bar blend with the background is
a better option in that case, so track window positions and add
some transparency when the top bar is free-floating.
https://bugzilla.gnome.org/show_bug.cgi?id=747163
And merge with the "internal" show/hide() ones. Those functions don't
proxy dbus method calls anymore, so it makes no sense to expose these.
Also, the timestamp is no longer needed as there is a single source for
these events.
https://bugzilla.gnome.org/show_bug.cgi?id=777342
The caribou daemon only gives us focus tracking, which is almost 1:1 with
our own FocusCaretTracker implementation. This means we can entirely
replace the Caribou daemon inside gnome-shell, reducing the Caribou
dependency to just libcaribou, and more specifically the
CaribouKeyboardModel we pull the keyboard models from.
As we still need underneath a CaribouDisplayAdapter to drive the keyboard,
reuse the wayland one, which has been renamed to make it look generic, plus
it will use the virtual input device API from mutter/clutter.
https://bugzilla.gnome.org/show_bug.cgi?id=777342
Some search providers such as GNOME Characters want to copy search
results to clipboard. However, on Wayland, clipboards are only
accessible from applications that have a visible surface on display.
This patch allows a search provider to request the shell to copy a
search result to clipboard when 'clipboardText' is included in the meta
of the result.
https://bugzilla.gnome.org/show_bug.cgi?id=775099
We are moving the icon to be added before the text instead of after,
which is consistent with other menu items in other popup menus, such
as the ones in the system indicator's popup menu.
https://bugzilla.gnome.org/show_bug.cgi?id=782166
This allows passing an optional icon parameter to addAction()
so that a PopupImageMenuItem instance is created instead of a
PopupMenuItem if an icon is specified.
https://bugzilla.gnome.org/show_bug.cgi?id=782166
Add an extra check to setIcon() so that either a GIcon or an string
with the icon's name is handlded, so that we can create menu items
in different ways (e.g. by passing a GIcon created from a resource).
https://bugzilla.gnome.org/show_bug.cgi?id=782166
The usual expectation when selecting large fonts is for content to
be bigger, not that less content is displayed. While not always
possible, there's no reason not to scale modal dialogues with the
font size.
https://bugzilla.gnome.org/show_bug.cgi?id=782000
Commit ffe4eaf00d broke the handler by fetching the instance private
from the wrong actor - as we don't use the ::primary-icon-clicked signal,
and the ::secondary-icon-clicked signal still works by accident, nobody
noticed until now ...
https://bugzilla.gnome.org/show_bug.cgi?id=782190
