Commit Graph

123 Commits

Author SHA1 Message Date
Owen W. Taylor
a6b4d49454 Use Mutter fullscreen window tracking for hiding chrome and auto-minimize
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
2013-03-18 14:44:10 -04:00
Jasper St. Pierre
b328fd7aed layout: Move window_group visibility to the layout
This ensures that windows are hidden in the screen shield and in gdm.

https://bugzilla.gnome.org/show_bug.cgi?id=695747
2013-03-18 03:57:36 -04:00
Jasper St. Pierre
6c0f48ce25 layout: Only emit fullscreen-changed if things actually changed
This prevents the message tray from doing a lot of work that
it doesn't need to.
2013-03-16 16:50:30 -04:00
Owen W. Taylor
6119b44746 Improve tracking of fullscreen windows
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
2013-03-14 08:06:08 -04:00
Jasper St. Pierre
725a36e37a messageTray: Use the bottom monitor's fullscreen state for rate limiting
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
2013-03-12 11:58:51 -04:00
Jasper St. Pierre
29152d3022 layout: Disable the overview hotcorner when we have a full-screen window open
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
2013-03-10 12:00:09 -04:00
Jasper St. Pierre
73fa4b1cbd messageTray: Don't open by pressure when we have a full-screen window open
When we have a full-screen window open, we expect the app to get all of
the chrome, so we should disable the bottom barrier as well.

https://bugzilla.gnome.org/show_bug.cgi?id=694997
2013-03-10 12:00:09 -04:00
Jasper St. Pierre
e2463cb501 layout: Move showing the stage and the startup-prepared signal
Waiting until we're idle means nothing if we're constructing
complex actors.

https://bugzilla.gnome.org/show_bug.cgi?id=694321
2013-03-07 16:35:36 -05:00
Tim Lunn
6c36856499 layout: fix errors in fallback HotCorner function 2013-03-05 17:53:59 +11:00
Jasper St. Pierre
26966b2bf3 layout: Port the hot corner to pressure barriers
If the X server supports the new barrier features, we should
trigger the overview hot corner with a pressure barrier as well.

https://bugzilla.gnome.org/show_bug.cgi?id=663661
2013-03-04 17:47:48 -05:00
Jasper St. Pierre
36a7429aa0 overview: Try to do the right thing related to XDnD
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
2013-03-04 17:47:47 -05:00
Jasper St. Pierre
7be1fe09f1 layout: Don't use the corner's position for positioning ripples
The corner may not be there in the future.

https://bugzilla.gnome.org/show_bug.cgi?id=663661
2013-03-04 17:03:24 -05:00
Jasper St. Pierre
62bf08d323 layout: Put two barriers near every single hot corner
This will make the hot corner easier to hit on multi-monitor
scenarios, and also gives us a convenient set of barriers to
key pressure off of.

https://bugzilla.gnome.org/show_bug.cgi?id=663661
2013-03-04 17:03:24 -05:00
Jasper St. Pierre
a90401454a layout: Pass the X/Y coordinates when constructing the corner
There's no guarantee that hot corners will have an actor in
the future -- they may be powered entirely by a barrier.

https://bugzilla.gnome.org/show_bug.cgi?id=663661
2013-03-04 15:50:45 -05:00
Jasper St. Pierre
5679e6b3a9 layout: Construct the primary monitors's hot corner, too
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
2013-03-04 15:50:45 -05:00
Jasper St. Pierre
194574bb0e layout: Allow multiple barriers to contribute to a PressureBarrier
For the HotCorner case, we want to have to barriers both contribute
to the hot corner pressure, so we can't simply wrap the pressure
barrier.
2013-03-04 15:50:44 -05:00
Jasper St. Pierre
337d2da38a layout: Move tray-specific event filtration to the user of PressureBarrier
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.
2013-03-04 15:50:44 -05:00
Jasper St. Pierre
df848aa084 layout: Move the keybinding mode to the user of PressureBarrier
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.
2013-03-04 15:50:44 -05:00
Jasper St. Pierre
0cc1615252 layout: Debounce triggering barriers
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.
2013-03-04 15:50:44 -05:00
Jasper St. Pierre
d4259fa8aa layout: Prevent going into negatives with the pressure
We capped each event to 15px of travel, but we didn't do the same
cap when subtracting events that were too old.
2013-03-04 15:50:43 -05:00
Ray Strode
cd37e2908f main: don't hook up overview keybinding until after startup
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
2013-03-04 11:58:39 -05:00
Ray Strode
1cbb8b9851 layout: tweak startup animation
Following designer feedback, this commit makes the startup
animation a little more subtle.

https://bugzilla.gnome.org/show_bug.cgi?id=694326
2013-03-02 17:44:26 -05:00
Ray Strode
570fc68cb1 main: put noise texture below startup animation, not still frames
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
2013-03-02 17:44:26 -05:00
Giovanni Campagna
b6bf8d5b2d Layout: don't minimize fullscreen windows that are focused
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
2013-03-01 18:07:47 +01:00
Jasper St. Pierre
804ff8b5a5 layout: Mark the correct monitor as fullscreen 2013-02-28 13:34:05 -05:00
Jasper St. Pierre
41f14e0e89 layout: Trigger the tray if one event passes the threshold
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
2013-02-27 14:01:42 -05:00
Jasper St. Pierre
01bd10f485 layout: Cap each event to 15px of motion
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
2013-02-27 14:01:42 -05:00
Jasper St. Pierre
476eacd5ca layout: Adjust the pressure barrier threshold values
After a day of experimentation with Cosimo and Jon McCann, we
found that this was the best way to do this.

https://bugzilla.gnome.org/show_bug.cgi?id=694467
2013-02-27 14:01:42 -05:00
Adel Gadllah
a361180745 layout: Handle _NET_WM_FULLSCREEN_MONITORS
Mark all monitors that fullscreen when window is using
the _NET_WM_FULLSCREEN_MONITORS to be fullscreen on multiple monitors.

https://bugzilla.gnome.org/show_bug.cgi?id=646861
2013-02-25 22:06:45 +01:00
Adel Gadllah
627a2412d2 ui: Don't use Clutter.Group
It is deprecated use Clutter.Actor instead.

https://bugzilla.gnome.org/show_bug.cgi?id=694441
2013-02-22 14:28:58 +01:00
Ray Strode
c562245c16 main: don't show stage until still frames are loaded
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
2013-02-21 15:01:39 -05:00
Jasper St. Pierre
b4678a1cee layout: Clean up consoleBackgroundGroup
We shouldn't leave a reference to a destroyed actor just hanging
around.

https://bugzilla.gnome.org/show_bug.cgi?id=694227
2013-02-20 11:36:19 -05:00
Jasper St. Pierre
5d3c90197c layout: Rebuild struts and the input region when the Shell starts up
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
2013-02-20 11:36:19 -05:00
Jasper St. Pierre
d5d517748c layout: Remove freezeUpdateRegions/thawUpdateRegions
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
2013-02-20 11:36:19 -05:00
Jasper St. Pierre
de3d3c15a5 layout: Don't bother updating the regions in the greeter
The greeter is always full-screen, so this should never matter.

https://bugzilla.gnome.org/show_bug.cgi?id=694227
2013-02-20 11:36:18 -05:00
Jasper St. Pierre
e801647083 layout: Fix some indentation 2013-02-19 21:00:46 -05:00
Jasper St. Pierre
1188b1be36 layout: Hide the message tray and OSK during the startup animation
https://bugzilla.gnome.org/show_bug.cgi?id=694227
2013-02-19 20:57:21 -05:00
Ray Strode
905c4932d1 layout: invert isGreeter check
I somehow lost an exclamation point.

https://bugzilla.gnome.org/show_bug.cgi?id=694227
2013-02-19 20:57:21 -05:00
Ray Strode
6484da26f0 layout: add back startingUp state variable
I dropped it on accident during last minute refactoring

https://bugzilla.gnome.org/show_bug.cgi?id=694227
2013-02-19 20:57:21 -05:00
Giovanni Campagna
079041cf1f BackgroundMenu: fix regression from new background handling
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
2013-02-19 20:57:21 -05:00
Giovanni Campagna
e4af954a95 LayoutManager: add missing constant
https://bugzilla.gnome.org/show_bug.cgi?id=694227
2013-02-20 02:25:36 +01:00
Ray Strode
ba4780cbd3 layout: don't bother hiding window group
Right now we hide the window group if we're a greeter.
We did this to avoid showing the background. These days
we don't add the background in the first place, so we
can drop this code.

https://bugzilla.gnome.org/show_bug.cgi?id=682429
2013-02-19 18:39:54 -05:00
Ray Strode
3c8325f1f3 layout: rework background handling
This commit updates the code to use mutter's new background
api, and changes the shell's startup animation to be closer
to the mockups.

Based on initial work by Giovanni Campagna

https://bugzilla.gnome.org/show_bug.cgi?id=682429
2013-02-19 18:39:54 -05:00
Jasper St. Pierre
1950a67e15 Run the startup animation when we don't have much going on
Starting the startup animation when we don't have that much IO
makes it a lot more visible.

Based on a patch by Giovanni Campagna <gcampagna@src.gnome.org>

https://bugzilla.gnome.org/show_bug.cgi?id=682429
2013-02-18 15:37:59 -05:00
Cosimo Cecchi
eab4c7bce9 Don't call beginItemDrag() for XDND
The dragged actors are not overview items.

https://bugzilla.gnome.org/show_bug.cgi?id=686984
2013-02-18 14:54:53 -05:00
Adel Gadllah
049695b914 Minimize fullscreen windows when they end up in the background
Alt-Tab away from a monitor sized on the primary monitor results into the top
panel being displayed on top of the window which looks very bad.

So just hide those windows by minimizing them.

The icon geometry animation does not really make sense for fullscreen windows
so just fade them out.

https://bugzilla.gnome.org/show_bug.cgi?id=693991
2013-02-18 19:30:56 +01:00
Jasper St. Pierre
7b1aab3759 layout: Fix tray barrier never getting destroyed
Due to a typo, we accidentally set trayPressure to null,
making the next branch always fail.

https://bugzilla.gnome.org/show_bug.cgi?id=694070
2013-02-18 13:25:12 -05:00
Adel Gadllah
d9770dcffb layout: Fix regressions
Commit 6b4f524620 removed the layer checks
_updateFullscreen ... this causes corruption when alt-tabbing out
of a fullscreen window so restore the check.

The commit also removed the screen sized check so we are no longer
setting all monitors to fullscreen. Fix that as well by using
window.is_screen_sized() to perform the check.

https://bugzilla.gnome.org/show_bug.cgi?id=694079
2013-02-18 14:13:37 +01:00
Jasper St. Pierre
641794d458 layout: Reword a comment
I don't even know what this was trying to say before...
2013-02-18 04:31:45 -05:00
Adel Gadllah
ae93d258a5 layout: Call meta_window_* on the meta_window rather then on the actor 2013-02-17 21:50:23 +01:00