For barriers like the hot corner which are made up of multiple axis
barriers, make sure that all the barriers have been left before
resetting the barrier.
NVIDIA drivers don't preserve FBO contents across suspend / resume
cycles which results in broken backgrounds. We can work around that by
forcing a refresh when coming out of suspend.
https://bugzilla.gnome.org/show_bug.cgi?id=739178
Since commit e189a34, the trayBox uses a Contraint to cover the primary
monitor's work area. This allows banners to be clipped so they don't
leak into monitors above the primary one during animations. However even
without being reactive, the trayBox now interferes with operations like
Looking Glass' object picker and overview DND.
With the trayBox no longer being positioned manually, there's no strong
reason to keep it in LayoutManager, and handling it in MessageTray allows
to hide the actor while no banner is showing, which helps with the issue
outlined above.
https://bugzilla.gnome.org/show_bug.cgi?id=744912
The panel is not visible when in fullscreen, but critical notifications
may still be shown - having them pop out from where the panel would be
looks unpolished, so adjust the trayBox accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=744850
It was removed as actors that should not affect the input
region can simply be added to the uiGroup instead. However
the property is useful to add non-reactive chrome, but then
use trackChrome() to add a child to the input region.
This reverts commit e62d22a50e.
https://bugzilla.gnome.org/show_bug.cgi?id=744850
Occasionally it makes sense to constrain to a monitor's work-area
rather than the entire monitor, so implement that behavior and add
a property to turn it on.
https://bugzilla.gnome.org/show_bug.cgi?id=744850
Don't assume struts are on the primary monitor while computing
the strut side. Instead, find the first monitor that overlaps the
strut and compute the strut side using it.
https://bugzilla.gnome.org/show_bug.cgi?id=744183
Since the background rework, SystemBackground is no longer a transparent
actor that you have to stack on top of a solid background, it is an
opaque actor. Fix the color of the background actor, and remove places
where we were setting the background color underneath the system background
and expecting blending - in particular, we can always set no_clear_hint
on the stage.
https://bugzilla.gnome.org/show_bug.cgi?id=738652
When monitors change, the previous index might not mean the same
physical monitor anymore, in fact, it might become invalid. In the
latter case, we'll actually get a JS error when accessing
this.keyboardMonitor in _updateKeyboardBox() . To avoid this, let's
just always reset the OSK to the primary monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=738536
If we have a modal, the stage's input region doesn't really matter --
all events go to us anyway. To avoid doing extra work doing animations
when we have a modal, like menus, the overview, and the message tray,
just fizzle out all updates.
To make sure we catch updates, update the input region whenever we end a
modal.
https://bugzilla.gnome.org/show_bug.cgi?id=737001
The rewrite of Mutter's background code (see bug 735637) requires
corresponding changes here - we no longer need to layer multiple
MetaBackgroundActors together.
The general strategy is that a BackgroundSource object is created
per GSettings schema, and keeps either one Background/MetaBackground pair,
or, for animation, a Background/Metabackground pair for each monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=735638
Support was added to Mutter to allow it to trigger a restart
to allow for restarts when switching in or out of stereo mode.
Hook up to the new signals on MetaDisplay to show the restart
message and reexec. Meta.is_restart() is used to suppress
the startup animation.
This also allows us to do 'Alt-F2 r' restarts more cleanly
without a visual flash and animation.
https://bugzilla.gnome.org/show_bug.cgi?id=733026
NetWM struts are defined in terms of screen edges (rather than monitor
edges), which works poorly with vertical monitor layouts (as it renders
entire monitors unusable). Don't extend struts in those cases.
https://bugzilla.gnome.org/show_bug.cgi?id=663690
This code may have worked when written in 2009, but later gjs commit
b5e467d89aea43a8e32a1138d232c8a32e6b0785 removed the priority
parameter from idle_add.
Now, when running a constantly-updating client (es2gears) on an
embedded platform, _updateRegions() does not get called and I see
unresponsive window decorations.
Update the code to use meta_later_add() like other parts of the
shell, which is actually slightly better in this case anyway.
Solves the unresponsiveness problem.
https://bugzilla.gnome.org/show_bug.cgi?id=585500
If an actor is destroyed, calling get_transformed_size()/position()
can return bogus values and trigger JS exceptions.
This can happen if a tracked actor comes from an extension
(such as classic mode's window-list) and that extension is
deactivated.
https://bugzilla.gnome.org/show_bug.cgi?id=723661
Right now we have three "dummy cursor" widgets between the background
menu, the message tray menu, and the IBus candidate popup. Consolidate
these into one "dummy cursor" widget which is tracked in the layout
manager.
If monitor-changed fires at startup, it will destroy all of the
backgrounds, but since this._isStartup is true, won't recreate any
of them. Additionally, since _bgManagers is indexed by monitor index,
if the primary index is not 0, it could become a sparse array (e.g.
[undefined, undefined, primaryBackground]), and our for loop will
crash trying to access properties of undefined.
Fix both of these issues by always creating background managers for
every monitor, hiding them on startup but only showing them after
the startup animation is complete.
One thing we need to watch out for is that while LayoutManager is
constructing, Main.uiGroup / Main.layoutManager will be undefined,
so addBackgroundMenu will fail. Fix this by passing down the uiGroup
to the background menu code.
https://bugzilla.gnome.org/show_bug.cgi?id=709313
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
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.
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
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
In order to make sure that the struts and regions are initialized,
we need to make sure that we do with the conditions that nothing
is transformed, like the uiGroup, and that everything is visible.
These invariants broke during a fix to hide the UI until the
system background texture could be loaded. Now, reorder things so
that the system background is loaded, and then the UI is properly
loaded, and so on.
https://bugzilla.gnome.org/show_bug.cgi?id=696159
Instead of using the input mode, when the overview is not modal
it should use a Chrome-tracked actor, that is added to the input
region. Because the overview always takes pointer input when
visible, the actor is added at startup, and it is shown and hidden
as needed.
https://bugzilla.gnome.org/show_bug.cgi?id=700735
Since we now have global.screen::in-fullscreen-changed, remove the
duplicate signal. To prevent ordering problems in connecting to
this signal, make inFullscreen a property-function of a new Monitor
object rather than a data property we tack on to a Rectangle object.
https://bugzilla.gnome.org/show_bug.cgi?id=649748
This ensures that when we have windows that are already visible,
like desktop icons, they don't fly across the screen from what
seems to be hyperspace to get into view.
https://bugzilla.gnome.org/show_bug.cgi?id=696323
In the (no barriers) fallback case handleDragOver has somehow
ended up being turned into a nop and thus breaking xdnd
overview opening.
Fix that by calling _toggleOverview() when a xdnd source triggers
it.
https://bugzilla.gnome.org/show_bug.cgi?id=696447
Getting fullscreen window tracking right in GNOME Shell turned out to
be very hard, because it depended on details both how Mutter handled
fullscreen windows and the exact timing of that. Fullscreen tracking
and auto-minimization of fullscreen windows that lose their fullscreen
status has thus been implemented in Mutter: use that.
https://bugzilla.gnome.org/show_bug.cgi?id=649748
It's possible in some corner cases for the status of the topwindow
to change and make it not fullscreen without ::restacked being
changed. One way that it could happen with the old code was if the
layer of the top window changed from NORMAL to FULLSCREEN.
Change the logic not to look at the layer, which is a function of
Mutter's *intended* stacking, rather than the *actual* stacking,
which is what ::restacked gives you. Instead, look at the top
portion of the stack, down to the first non-override-redirect
window, and see if their are any monitor-sized windows there.
Connect to changes on the top portion of the stack, so we know
if conditions change.
https://bugzilla.gnome.org/show_bug.cgi?id=649748
It makes more sense to use the monitor the tray is on, rather than the
primary monitor. This also matches us with whether we can open the tray
from a barrier/dwell or not.
https://bugzilla.gnome.org/show_bug.cgi?id=695659
For the same reasons that we disable the tray barrier, we should
disable hot corners as well -- when users have a full-screen game
open, we shouldn't allow overview activation by the hotcorner.
https://bugzilla.gnome.org/show_bug.cgi?id=694997
Rather than expose a dizzying array of methods related to managing
state that require infecting every user of the overview methods, try
to do the sensible and smart thing internally. Now, the overview
itself tracks when XDND drags start, and simply calling show, hide or
toggle while an XDnD drag is in effect will show the overview, and
will only take the grab until after the XDND drag ends.
https://bugzilla.gnome.org/show_bug.cgi?id=663661
This cleans up the code considerably, and makes it so that
one path creates all hot corners for all monitors. Why this
wasn't done originally, I have no clue...
The one complication is debouncing if the button and hot corner
are triggered in rapid succession, so we just move this tracking
to the overview.
https://bugzilla.gnome.org/show_bug.cgi?id=663661
For the HotCorner, we want to have different logic for tossing out
specific events based on the grabbed state, etc. so make us have
to pass in an event filter callback.
For the hot corner case, we want to have the pressure apply both in
and outside of the overview, so we need to move this to the user. At
the same time, use keybinding mode math that's more like what's used
in filterKeybinding.
While it may seem like an abuse of the KeyBindingMode API, it may
become more reasonable if one thinks of the pressure barrier as a
binding of sorts, just applied to the mouse. If a ButtonBinding API
was added to mutter, I think we'd use the existing KeyBindingMode
infastructure there as well.
Ensure that the pointer leaves the barrier before we trigger again.
For the message tray case, this doesn't matter much, as the trigger
won't have any effect after the grab is taken, but in the overview
HotCorner case, this ensures that we don't trigger the overview
transition many times simply by holding pressure against the hot
corner, which is easy to do accidentally.
Toggling the overview during the startup animation reportedly
causes stuck grab and other odd behavior.
There's no reason to handle toggling the overview during this
time anyway.
This commit defers that handling until after startup.
https://bugzilla.gnome.org/show_bug.cgi?id=694837
Right now we take a still frame of the desktop before showing the
start up animation. This gives us an animation over what was
there before startup.
That's not actually desirable when restarting the shell. We don't
want to animate over undecorated windows, we really want to animate
over the noise texture.
This commit drops the still frames in favor of the noise texture.
https://bugzilla.gnome.org/show_bug.cgi?id=694326
Windows can sometimes be focused, or appear to be focused, without being
at the exact top of the stack, for example in the case of override-redirect
windows, or with attached modal dialogs. In that case, we should not
try to minimize them (as it creates a loop that makes it impossible to restore
the window)
https://bugzilla.gnome.org/show_bug.cgi?id=694905
As a special-case to the "cap event" rules, this allows a heavy swipe
from top to bottom to allow triggering the tray without having to push
into it.
https://bugzilla.gnome.org/show_bug.cgi?id=694467
When pressing against the bottom of the screen, we shouldn't
really take more than 15px from each event, to prevent spruious
mouse movements from opening the barrier.
https://bugzilla.gnome.org/show_bug.cgi?id=694467
We sometimes map the stage before we've loaded a background on it
because of a race asynchronously loading the session mode.
This manifests as the startup animating starting over a white
background.
This commit defers showing the stage until after the still frames
are loaded.
https://bugzilla.gnome.org/show_bug.cgi?id=694321
This means that windows will be positioned correctly with respect
to the panel when the shell starts up, and there won't be adjusting
after the session animation zooms in entirely.
https://bugzilla.gnome.org/show_bug.cgi?id=694227
Due to a bad rebase causing freezeUpdateCount to never get initialized,
these functions effectively did nothing. Since we're going to go to a
different mechanism for freezing region updates, let's just tear these
out now instead of fixing them before tearing them out.
https://bugzilla.gnome.org/show_bug.cgi?id=694227
BackgroundMenu must ensure the actor it attaches to is reactive, and
the layout manager must create a background menu for the first background
too.
https://bugzilla.gnome.org/show_bug.cgi?id=694227
