There are some issues with the existing session menu. First, it looks
kinda bad. It seems like it's hanging around there, but it doesn't really know
what to do with itself.
Second, when it expands down it requires that the buttons below move
down with it. This kind of movement is awkward and looks a bit weird.
Third, its current position makes the "dialog" tall and unwieldy when
you add things like messages for fingerprint readers or authentication errors.
This commit moves the session list to a menu behind a button to address
the above problems.
Based on a patch by Jasper St. Pierre.
https://bugzilla.gnome.org/show_bug.cgi?id=702818
Commit 16fa186b63 attempted to fix the zoom animation problem
by throwing changes on the floor while the overview is animating. This has
the side effect that we might end up missing some positioning changes causes
windows to overlap the workspace thumbnails.
So revert those changes and fix it by simply by passing
WindowPositionFlags.ANIMATE during the overview animation.
This way the animation works as expected and we don't miss any position changes.
https://bugzilla.gnome.org/show_bug.cgi?id=703105
Right now, there's a weird flicker at start up where the
Not Listed? button shows up before the user list, which looks
pretty bad if you're watching for it.
This commit fixes that problem by hiding the Not Listed button
initially and showing it at the appropriate time.
https://bugzilla.gnome.org/show_bug.cgi?id=703132
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 login screen is no longer even remotely dialog-like, so
using ModalDialog is pretty weird. It also makes it difficult
to put the session list in the same place as the spinner.
This commit moves loginDialog away from using modal dialog.
https://bugzilla.gnome.org/show_bug.cgi?id=702818
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.
While it is obviously still an error to call get_theme_node() on a
widget that hasn't been added to the stage hierarchy yet, asserting
on it hasn't proven too successful in avoiding those errors - it's
likely the most frequent reason for crash reports. Just accept that
there'll always be code paths where we can hit this case and make
it non-fatal.
https://bugzilla.gnome.org/show_bug.cgi?id=610279
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
