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.
When coming back from search or apps, the workspace thumbnails and dash
don't slide in but "pop in". This is because of bad timing: when slideIn
is called, we immediately start the translation animation, and it
completes before by the time we fade the new page in.
Fix this by calling slideIn and slideOut at two different times: we now
slide out when the old page with our controls is fading out, and slide in
when the new page with our controls is fading in.
https://bugzilla.gnome.org/show_bug.cgi?id=708340
Activating the GDM login screen switches VT and causes X to freeze
event processing (because it lost the drm master), so must make
sure to have painted the lock screen at least once before proceeding,
or the user can go back and see the unlocked desktop.
https://bugzilla.gnome.org/show_bug.cgi?id=708051
gnome-keyring provides a fallback in case our builtin prompt fails
to register, so keyring dialogs may still pop up even when they
are supposed to be disabled.
Instead, keep the prompt registered but cancel requests immediately
while disabled.
https://bugzilla.gnome.org/show_bug.cgi?id=708187
Have AT-SPI calls time out after 250ms, to mitigate the effect of a
deadlock when querying another application that is trying to query
gnome-shell.
https://bugzilla.gnome.org/show_bug.cgi?id=708387
We don't want password entries to grow when entering more characters
that fit the available width; as labels' ClutterText ellipsizes by
default, the password labels allow entries to grow by shrinking.
Setting the appropriate ellipsize mode fixes this.
https://bugzilla.gnome.org/show_bug.cgi?id=708324
We don't want the password entry to grow when entering more characters
that fit the available width; as labels' ClutterText ellipsizes by
default, the password label allows the entry to grow by shrinking.
Setting the appropriate ellipsize mode fixes this.
https://bugzilla.gnome.org/show_bug.cgi?id=708324
We don't make use of any functionality StTable provides over
ClutterTableLayout, so port all users to the Clutter layout
in order to remove our own copy of the code.
https://bugzilla.gnome.org/show_bug.cgi?id=703833
We don't make use of any functionality StTable provides over
ClutterTableLayout, so port all users to the Clutter layout
in order to remove our own copy of the code.
https://bugzilla.gnome.org/show_bug.cgi?id=703833
We already do this for looking glass, but it makes even less sense
for the normal run dialog - if a mode sets runDialog to false, the
intention is to not allow executing aribitrary commands.
https://bugzilla.gnome.org/show_bug.cgi?id=708218
Previously the animation was not entirely according to the mockup.
Now we are closer to the mockup.
The padding for the indicators are decremented, since we need that
to make the animation not too quick. As a drawback, maybe visually
is not as good as before, or the area to click dots is too much little.
Just make that change for now and test it widely, and we can change
that after.
https://bugzilla.gnome.org/show_bug.cgi?id=707565
The original position was calculated with the stage and the
transformed position of the indicator when mapped. The values
were wrong on some situations, so lets calculate the position
based on the dots width.
https://bugzilla.gnome.org/show_bug.cgi?id=707580
