The parent SlidingControl had an onOverviewShowing, but we had
overridden it with the same code in both subclasses. Just move it
back to SlidingControl.
When we create a result actor, cache it, so it can be used for
subsearches of the same initial. For now, to keep memory usage
and the stage graph relatively clean, don't persist the actors
across searches, but maybe we should do this in the future.
This also means that we don't query getResultMetas for items
that we've seen in the same initial search.
https://bugzilla.gnome.org/show_bug.cgi?id=704912
The existing provider system is split between a confusing mess of
RemoteSearch, SearchSystem, SearchDisplay, and ViewSelector, partly
because of the vestigal in-shell search system. Move most of the
logic to search.js so it's easier to read.
We fetch and store the list of providers from the search system when we
construct SearchResults, but we never update this list when providers are
changed at runtime, causing various bugs making the search not seem as
snappy as it should be. Make sure to always fetch the list of providers
from the search system.
While the existing comment is correct in that a source's notifications
will be destroyed first, the code takes a shortcut which prevents the
Source::count-updated signal from being emitted. Given that the purpose
of the signal is to keep notification counters up-to-date which is
pointless when the source is about to be destroyed, the shortcut makes
sense; just save notifications explicitly in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=710596
search.js used to do a lot more, but now that most of the
functionality has been moved to the remote search system,
it doesn't do a lot. Merge searchDisplay.js into it.
It's been broken for quite a bit since we removed Panel.Animation,
and hasn't really ever worked with our new search results. It's also
the only non-remote provider left.
Maybe we'll add it back as a remote provider later, but for now, just
ditch it.
The new API is designed to support features like persistence and uses
the new org.freedesktop.Application specification for activating
actions on notifications. While we won't add support for persistence
yet, implement the new notification spec with parity of the old one.
https://bugzilla.gnome.org/show_bug.cgi?id=710137
Some consumers may want to construct their buttons specially, so allow them
to do that by adding a new API that takes a button instead of a label.
https://bugzilla.gnome.org/show_bug.cgi?id=710137
Their use blocks activation of the default button by keyboard, which
is important for accessibility. Use a Clutter.ClickAction instead,
which doesn't have this problem as it only considers mouse events.
https://bugzilla.gnome.org/show_bug.cgi?id=710144
Otherwise, when closing the tray, we'll try to focus an actor, which will
focus the stage window, which will drop the focus from whatever window we
already had focused.
https://bugzilla.gnome.org/show_bug.cgi?id=710347
The application picker will always open with the view that was last
selected during the session, but the selection is reset on each
restart. This results in some annoyance for users that use the
ALL view exclusively, as they have to toggle views once each
session - the same would apply to exclusive FREQUENT view users
were the defaults to be changed, so the best solution is to simply
make the selected view persistent by storing it in GSettings.
https://bugzilla.gnome.org/show_bug.cgi?id=710042
If we pushNotification the same notification multiple times, we
won't append it to the array again, but we will attach multiple
handlers needlessly.
https://bugzilla.gnome.org/show_bug.cgi?id=710115
oVirt is software for managing medium-to-large scale deployments of
virtual machine guests across multiple hosts. It supports a feature
where users can authenticate with a central server and get
transparently connected to a guest system and then automatically get logged
into that guest to an associated user session.
Guests using old versions of GDM support this single-sign-on capability
by means of a greeter plugin, using the old greeter's extension
API.
This commit adds similar support to the gnome-shell based login screen.
How it works:
* The OVirtCredentialsManager singleton listens for
'org.ovirt.vdsm.Credentials.UserAuthenticated'
D-Bus signal on the system bus from the
'org.ovirt.vdsm.Credentials'
bus name. The service that provides that bus name is called
the oVirt guest agent. It is also responsible for interacting
with the the central server to get user credentials.
* This UserAuthenticated signal passes, as a parameter, the a token
which needs to be passed through to the PAM service that is specifically
set up to integrate with the oVirt authentication architecture.
The singleton object keeps the token internally so it can be queried
later on.
* The OVirtCredentialsManager emits a signal 'user-authenticated' on
it's object once the dbus signal is triggered
* When the 'user-authenticated' signal is emitted, the login screen
tells GDM to start user verification using the PAM service. The
authentication stack of the service includes a PAM module
provided by oVirt that securely retrieves user credentials
from the oVirt guest agent. The PAM module then forwards those
credentials on to other modules in the stack so, e.g.,
the user's gnome keyring can be automatically unlocked.
* In case of the screen shield being visible, it also will react on that
'user-authenticated' signal and lift the shield.
In that case the login screen will check on construction time if
the signal has already been triggered, and a token is available.
If a token is available it will immediately trigger the functionality
as described above.
Signed-off-by: Vinzenz Feenstra <evilissimo@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=702162
Allow the prefix 'special:' applied to result IDs to mark results
that should be always shown, even when they would overflow the
maximum results cap. This will be used by epiphany for the special
"Search the Web" result.
https://bugzilla.gnome.org/show_bug.cgi?id=707055
NotificationDaemon doesn't pass a gicon to the Notification constructor,
because it calls .update() immediately after, so messageTray.js
calls into Source.createIcon(), which returns null and crashes.
Instead, shortcut the Notification constructor by skipping
.update() completely.
https://bugzilla.gnome.org/show_bug.cgi?id=709998
The _background hack was added because the old way the zooming animation
worked, it set the allocation of the workspaces view and thumbnails box
to the final position and used animations to smoothly animate.
During the 3.6 cycle when we added the new search view, Cosimo changed the
way the zoom animation works so that rather than set the final allocation
and animate, we actually do adjust the allocation of the workspaces view
and thumbnails box.
So, as the hack is no longer necessary, we can drop it.
https://bugzilla.gnome.org/show_bug.cgi?id=694881
In order for the workspace thumbnails box to have the correct size,
we need to constrain the width of the thumbnails box to the height we're
given, instead of assuming an unlimited height.
https://bugzilla.gnome.org/show_bug.cgi?id=694881
We cannot wait for the queued update region to fire when
xdnd is being used because a wrong input shape can result
into a xdnd leave event when the user moves the pointer fast.
https://bugzilla.gnome.org/show_bug.cgi?id=708887
Since the agregate menu does 120% of font-size, make this
for all dropdown arrows in gnome-shell and rename the css
class to make clear that it is used in overall gnome-shell
https://bugzilla.gnome.org/show_bug.cgi?id=709564
According to the designs, the notifications switch was supposed
to move from the user menu to the new message tray menu. However
so far the new system status implementation only removed the old
switch, so add it back in its new place now.
https://bugzilla.gnome.org/show_bug.cgi?id=707073
Because of the animation and collision with relayout, the title of windows in overview may not appear, mainly
the first time we enter in overview
With an animation delay of 0.1s, you'll not see the difference
https://bugzilla.gnome.org/show_bug.cgi?id=709392
Show "Hardware Disabled" when disabled by HW switch, and
generically "Disabled" when airplane mode is active, as
indicated by v4 mockups.
Note that bluetooth is not affected by NM handling of airplane
mode (and generally the firmware makes the USB bluetooth
adapter disappear when rfkilled), so this is in NMDeviceModem
instead of NMConnectionDevice.
https://bugzilla.gnome.org/show_bug.cgi?id=709043
Since commit 1242a16265, we will use a fake prompt which
cancels alls requests without dialog when the keyring component
is disabled. However this does only apply to new requests, dialogs
that are already active when the session mode changes are kept
open. This is not quite as expected, so cancel the prompt in that
case.
https://bugzilla.gnome.org/show_bug.cgi?id=708910
The property is on the NMClient, not NMDevice. Also, make sure
we disconnect the signal when the item is destroyed.
Also, connect to wireless-hardware-enabled, which we'll use soon.
https://bugzilla.gnome.org/show_bug.cgi?id=709635
Destroying the notification will make the key focus be reset to NULL, which
means that gnome-shell will try to focus the MRU window, thinking the user is
done interacting and wants to go back to whatever they were doing.
Unfortunately, since we focus two windows at the same time, they will have
the same timestamp, meaning that the window that actually gets focused will
be a race as to whoever responds to their WM_TAKE_FOCUS event last.
If we explicitly set the focus beforehand, then gnome-shell will believe it
got key focus taken away from it, and won't try to focus the MRU when the
key focus drops to NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=703265
We must reduce the forWidth in the call to get_preferred_height()
with the border width, otherwise we might request a smaller height
that we actually need and overflow.
https://bugzilla.gnome.org/show_bug.cgi?id=696564
If the active connection for the device is not the primary or
activating globally, it won't have the _connection and _primaryDevice
expando properties, so grab them from the settings object.
https://bugzilla.gnome.org/show_bug.cgi?id=709043
The patch fixes the following warning, and along with it, the proper
destruction of the NMConnectionSection is performed so that items get
correctly removed from the menu.
(gnome-shell:24528): Gjs-WARNING **: JS ERROR: TypeError:
this.statusItem is undefined
NMConnectionSection<.destroy@/home/aleksander/gnome/install/share/gnome-shell/js/ui/status/network.js:173
wrapper@/home/aleksander/gnome/install/share/gjs-1.0/lang.js:213
_parent@/home/aleksander/gnome/install/share/gjs-1.0/lang.js:175
NMConnectionDevice<.destroy@/home/aleksander/gnome/install/share/gnome-shell/js/ui/status/network.js:292
wrapper@/home/aleksander/gnome/install/share/gjs-1.0/lang.js:213
_parent@/home/aleksander/gnome/install/share/gjs-1.0/lang.js:175
NMDeviceModem<.destroy@/home/aleksander/gnome/install/share/gnome-shell/js/ui/status/network.js:448
wrapper@/home/aleksander/gnome/install/share/gjs-1.0/lang.js:213
NMApplet<._removeDeviceWrapper@/home/aleksander/gnome/install/share/gnome-shell/js/ui/status/network.js:1421
wrapper@/home/aleksander/gnome/install/share/gjs-1.0/lang.js:213
NMApplet<._deviceRemoved@/home/aleksander/gnome/install/share/gnome-shell/js/ui/status/network.js:1416
wrapper@/home/aleksander/gnome/install/share/gjs-1.0/lang.js:213
https://bugzilla.gnome.org/show_bug.cgi?id=709248
Don't assume that this._bgManagers.push() (i.e adding to the end) is always
correct.
On startup we call _createPrimaryBackground which passes in the primary index
which may not be 0.
We connect to the changed signal in _init() but never actually disconnect from
it. The callback has a reference to "this" which results into the background
object not getting garbage collected.
Fix that leaks by disconnecting in _destroy()
https://bugzilla.gnome.org/show_bug.cgi?id=709263
The cover pane is used to block events during transitions, but as
workspaces don't share the same container as other overview elements,
they are currently excempt from the event blocking.
Move the cover pane to the top-level overview container instead.
https://bugzilla.gnome.org/show_bug.cgi?id=709034
Moving the mouse fast enough during xdnd will trigger a xdnd-leave event
because the input shape is not updated until after the animation is done.
So simply ignore the leave events while the animation is in progress.
https://bugzilla.gnome.org/show_bug.cgi?id=708887
This reverts commit e31693bbee.
This doesn't properly adjust the allocation, leading to an unbalanced
overview where things aren't centered properly. Just revert for now,
and we'll rethink this next cycle.
