The top_window_group was introduced for popup windows that should
appear above system chrome, but as the group itself is just a child
of Main.uiGroup, chrome that is added after top_window_group will
still be stacked on top.
At least correct the stacking for actors added via addChrome().
https://bugzilla.gnome.org/show_bug.cgi?id=702338
The class is generally useful, so it only makes sense in panel.js
for historical reasons. Because other parts of the code are
using it, though, problems are cropping up that require a
workaround like:
placeSpinner: function(...) {
/* This is here because of recursive imports */
const Panel = imports.ui.panel;
Panel.AnimatedIcon(spinnerIcon, WORK_SPINNER_ICON_SIZE);
...
}
This commit moves AnimatedIcon to its own file so we can drop that
workaround.
https://bugzilla.gnome.org/show_bug.cgi?id=702818
When the osd window is hidden based on the timeout, it accidentally
left the timeout ID in place. When a subsequent switcher popup came
up, it thought the OSD window was scheduled to be hidden and tried
to re-hide the actor. This caused the tween to be run along with
an extra call to enable_unredirect_for_screen.
When the allocation of the workspacesView changes during the animation we override
the tween with one that does not animate causing the overview zoom animation
not to happen.
Fix that by ignoring the alloactionChanged notification during the overview
animation.
The code here before was trying to play hierarchy tricks to
figure out how to show / hide the events list, which broke
when we rearranged how the date menu was laid out. Simplify
the code here to not be so tricky, and update the CSS to
match the new designs.
https://bugzilla.gnome.org/show_bug.cgi?id=702849
The timestamp timeout specifies how long we should wait before
adding a timestamp to the notification. A timeout of one minute
ended up showing a lot of timestamps, so increase it to 3 minutes.
https://bugzilla.gnome.org/show_bug.cgi?id=687809
If we focus notifications before they're expanded, the body and action
area won't be visible, and the can_focus members like the text entry
will not be able to be focused.
Ensure that all of the all actors that would be in an expanded notification
are visible before we attempt to focus them.
https://bugzilla.gnome.org/show_bug.cgi?id=698778
Migration from old settings can result in a path instead of URI
there. This is technically invalid, but can easily recognize it
and avoid the crash.
Minor changes by Ray Strode
https://bugzilla.gnome.org/show_bug.cgi?id=702121
The status item will go away soon, so make sure the one-time
fire is given its own function. At the same time, only connect
to the signal when the situation actually matters.
https://bugzilla.gnome.org/show_bug.cgi?id=701954
No class in here has this.carrier as a property. Presumably, this was
meant to be this.device.carrier, but since this code is going to be
rewritten soon anyway, might as well just junk the never-working
code for now.
https://bugzilla.gnome.org/show_bug.cgi?id=701954
In order to have event descriptions on multiple lines, but still
maintain proper alignment with the day and time strings, refactor
the whole event list to be one big table. Headers are implemented
as spanning cells, and uneven spacing is a mix of row/column spacing
and cell padding.
https://bugzilla.gnome.org/show_bug.cgi?id=701231
In BlueZ 4, Authorize() was used to authorize both service
and JustWorks authorization requests. In BlueZ 5 these two
have been split into AuthorizeService() for services and
RequestAuthorization for JustWorks devices. Adapt the
Bluetooth code accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=700891
This can be more easily achieved by listening for changes to the
device's active-connection property. VPN will still need support to
track active connections, as it does not have an associated
device. But as VPN can track multiple active connections, the names
"set" and "clear" don't quite fit. Rename them to the more-standard
"add" and "remove".
https://bugzilla.gnome.org/show_bug.cgi?id=701954
The end session dialog was waiting a second before updating
its text to display the timer. It is nicer to show the correct
message from the start.
https://bugzilla.gnome.org/show_bug.cgi?id=702056
We currently monitor the shell's override schema for changes to
the 'dynamic-workspaces' key, which ends up being the wrong
schema in classic mode. With the new ability to use mode-specific
overides, we can finally fix this.
https://bugzilla.gnome.org/show_bug.cgi?id=701717
This will allow the use of mode-specific defaults. For classic mode
we currently implement this with mini-extensions, but this may result
in confusing behavior when settings change due to extensions being
disabled during screen locks (not to mention that those mini-extensions
are hardly an elegant approach).
https://bugzilla.gnome.org/show_bug.cgi?id=701717
We will allow to use mode-specific overrides; in preparation for that,
move the code so that we only override preferences after initializing
the session mode.
https://bugzilla.gnome.org/show_bug.cgi?id=701717
As multiple-connections for a Wi-Fi AP won't fit in the new design,
remove submenus right now. Simply make a simple item that connects
to the first known connection for the AP, which should be the common
case.
https://bugzilla.gnome.org/show_bug.cgi?id=698918
Currently we "only" grab the keyboard when starting a drag operation,
which does not impede keybindings to be processed. This is at best
not harmful (like workspace switching), but may have unintended effects
otherwise - for instance, the hot corner is disabled, so having the
corresponding keyboard shortcut still active is fairly odd (not to
mention that it leaves the system in a confused state).
Fix this by switching to pushModal()/popModal(), which will push a
dedicated keybinding mode for us.
https://bugzilla.gnome.org/show_bug.cgi?id=700877
Currently the clipboard's contents may leak to unauthorized parties by
pasting into the unlock dialog's password entry and unmasking the entry.
Prevent this from happening by clearing the clipboard on lock.
https://bugzilla.gnome.org/show_bug.cgi?id=698922
