Currently lookingGlass relies on some odd BoxLayout behavior, which
allows children to use fixed positioning without affecting the parent's
size request. As this behavior is scheduled for removal, add the
looking glass dialog directly to Main.uiGroup.
https://bugzilla.gnome.org/show_bug.cgi?id=703808
Moving from fixed width to horizontal padding for the app view control
buttons broke the focus style, in that buttons may change size on
keyboard focus changes. Fix this by using the correct horizontal padding
when focused.
https://bugzilla.gnome.org/show_bug.cgi?id=703807
commit ea02380c15 changed the login
dialog to not use ModalDialog anymore. There's still one lingering
setInitialKeyFocus method call in the source, which will cause an
exception to be thrown when users have their user list disabled.
This commit fixes that.
https://bugzilla.gnome.org/show_bug.cgi?id=703874
Currently the box-shadow is rendering is done like this :
The first time we want to render a node that requires a box-shadow, St
creates an cogl offscreen surface of the size of the allocation and
renders the box into this offscreen buffer using modulation on the
alpha channel, this buffer is then blurred according to the CSS
parameters.
The problem with this method is that every time an StWidget is
resized, its box-shadow offscreen buffer has to be resized and
therefore rendered and blurred.
This patches propose an optimization for this use case by rendering
the box-shadow only once but at a size that is independent of the
StWidget's size. Then every time we need to paint this box-shadow, we
just render this offscreen buffer using a 9-slices.
This method only works when the allocation of the widget is bigger
than the minimum shadow size on which we can apply a 9-slices, that is
given my the radius of the corners. If the allocation is smaller than
this minimum size, we then fallback to the fully render/blur the
shadow (like before this patch).
https://bugzilla.gnome.org/show_bug.cgi?id=689858
The duality of the Clutter's key focus and mutter's window focus has long been
a problem for us in lots of case, and caused us to create large and complicated
hacks to get around the issue, including GrabHelper's focus grab model.
Instead of doing this, tie basic focus management into the core of gnome-shell,
instead of requiring complex "application-level" management to get it done
right.
Do this by making sure that only one of an actor or window can be focused at
the same time, and apply the appropriate logic to drop one or the other,
reactively.
Modals are considered a special case, as we grab all keyboard events, but at
the X level, the client window still has focus. Make sure to not do any input
synchronization when we have a modal.
At the same time, remove the FOCUSED input mode, as it's no longer necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=700735
We can easily implement much of the same behavior ourselves by
keeping track of Clutter's focus events. Reintroduce heavily
modified FocusGrabber to do the work for us.
This will temporarily break when the user selects a window until
we can make gnome-shell automatically set the stage focus.
This also removes our only use of focus grabs, so remove those
as well.
https://bugzilla.gnome.org/show_bug.cgi?id=700735
We can't assume "isActive implies isModal", so there is a risk
of pushing a modal that nothing else will ever pop, because we
take the early return and don't activate the user active watch.
https://bugzilla.gnome.org/show_bug.cgi?id=700901
_updateIcon should not attempt to sync any active connections, as the
icon-changed signal can be emitted in response to something done during
_syncActiveConnection. In the case of VPN, removeActiveConnection would
cause an icon-changed signal to be emitted immediately, but the state
would not be updated, causing us to call removeActiveConnection over and
over.
Explicitly sync all active connections when we know it needs to be done,
and simply make _updateIcon synchronize with the current device's icon.
https://bugzilla.gnome.org/show_bug.cgi?id=703565
This fixes a blue background being drawn when switching the monitors
configuration using hardware keys
(clone/multimonitor/external/internal).
The problem is that the shell gather all background loading requests
under the same meta_background_load_file_async call using one
GCancellable (the first one to come). So when the shell receives a
batch of 12 or so XRandr events, it creates 12 new background managers
which end up trying to load 12 times the same background picture. All
of these requests are batched into the same
meta_background_load_file_async using the first GCancellable received
on the first request. Unfortunately, when the first request is
cancelled by the following event indicating a new monitor setup, all
of the background picture requests are dropped on the floor, and
nothing gets loaded (hence the blue screen background).
https://bugzilla.gnome.org/show_bug.cgi?id=703001
It turns out that picking a 3200x1200 scene on notebook chipsets
every time the mouse is moved isn't exactly the fastest thing. Defer
picking to an idle to ensure that it won't get in the way of keeping
up with mouse events.
https://bugzilla.gnome.org/show_bug.cgi?id=703443
This causes a debug SpiderMonkey build to fail when it throws an
exception for the missing symbol, but doesn't properly return FALSE
when executing the script.
https://bugzilla.gnome.org/show_bug.cgi?id=703442
The code that checks for various conditions is confusing and
undercommented. It appears one of the recent refactorings
inadvertedly inverted the sense of the 'hidden mountpoint'
check, and caused autorun to not work for anything that does
not have a 'native root' - which is pretty much all volumes
implemented by gvfs.
https://bugzilla.gnome.org/show_bug.cgi?id=703418
Commit d6cace32 introduced a typo in the left/right arrow side
calculation code that causes in most scenarios (where the monitor
width is greater then the height) to not flip the box when it doesn't
fit inside the monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=703403
If the drag action ends after something else has put the screen shield
into a different state we can end up in an inconsistent screen shield
state where the whole thing is empty.
https://bugzilla.gnome.org/show_bug.cgi?id=703126
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.
