Commit Graph

3568 Commits

Author SHA1 Message Date
Jasper St. Pierre
8301acd4d6 grabHelper: Use a round trip for focusing the default window
We may release the focus grab at any time, so it's not guaranteed
we'll be in event processing. In particular, hovering over and out
of a notification will cause this to happen, as the notification
is hidden on a timeout.

https://bugzilla.gnome.org/show_bug.cgi?id=695659
2013-03-12 11:58:50 -04:00
Jasper St. Pierre
209014b083 screenShield: Forward key presses to tne entry when raising the shield
https://bugzilla.gnome.org/show_bug.cgi?id=686740
2013-03-11 15:08:21 -04:00
Jasper St. Pierre
127f10e7a8 screenShield: Don't wait until the dialog is loaded before opening it
If we wait asynchronously, key presses while the shield is opening
will be dropped in the void.

https://bugzilla.gnome.org/show_bug.cgi?id=686740
2013-03-11 15:08:21 -04:00
Jasper St. Pierre
67615a0cbc screenShield: Remove bump on key press
Any key press of a character-emitting key will now raise the shell.
Note that the key press will not be forwarded to the entry yet.

https://bugzilla.gnome.org/show_bug.cgi?id=686740
2013-03-11 15:08:20 -04:00
Jasper St. Pierre
dde20f0c76 screenShield: Move opening of screen shield to key press
This makes the screen shield much more responsive.

https://bugzilla.gnome.org/show_bug.cgi?id=686740
2013-03-11 15:08:20 -04:00
Adel Gadllah
96239e95ec userMenu: Add translation comments
Seems like "console" vs. "remote" in the "other users" dialog  confuses some
translators so add a comments to clarify their meaning.

https://bugzilla.gnome.org/show_bug.cgi?id=695601
2013-03-11 10:35:42 +01: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
Giovanni Campagna
7766a91e8c Wanda: so long GNOME 2, and thanks for all the fish.
gnome-panel is going away in 3.8, so we can't rely on it to provide our
friendly and reliable companion. But no regret, because we can ship it
ourselves, and at the same time remove some unnecessary configuration.

https://bugzilla.gnome.org/show_bug.cgi?id=695526
2013-03-10 15:54:40 +01:00
Giovanni Campagna
5af09a60e9 Main: close the looking glass when we don't have a run dialog
No run dialog means no looking glass either.

https://bugzilla.gnome.org/show_bug.cgi?id=695458
2013-03-08 23:18:31 +01:00
Cosimo Cecchi
ce5faba185 osdWindow: bump down the OSD window size a bit
Matches what this commit did for g-s-d:
https://git.gnome.org/browse/gnome-settings-daemon/commit/plugins/media-keys?id=fbf3c5aa366ef7212f209e123d4aae315a1a2a8e

https://bugzilla.gnome.org/show_bug.cgi?id=695409
2013-03-07 17:02:41 -05:00
Jasper St. Pierre
40d9ed535b runDialog: Remove the use of file monitors for file completion
Launching the run dialog to open the looking glass or something
like that shouldn't install a bunch of file monitors that monitor
every IO change to the home and system directories.

Instead, simply scan all the paths when trying to complete.

https://bugzilla.gnome.org/show_bug.cgi?id=695338
2013-03-07 16:35:37 -05:00
Jasper St. Pierre
d5675765f3 runDialog: Remove tab-completion preloading
This is iffy anyway, since we don't wait for the correct signal.
Just make the user press tab again, like they would do anyway.

https://bugzilla.gnome.org/show_bug.cgi?id=695338
2013-03-07 16:35:37 -05:00
Jasper St. Pierre
65067c24cc main: Show the greeter dialog when we're prepared
If we don't wait until the stage is mapped, pushing a modal
will fail with an X error.

https://bugzilla.gnome.org/show_bug.cgi?id=694321
2013-03-07 16:35:37 -05: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
Jasper St. Pierre
de2f2d7ef1 main: Remove leftover hunk connection to sessionUpdated
We shouldn't connect to sessionUpdated twice.

https://bugzilla.gnome.org/show_bug.cgi?id=694321
2013-03-07 16:35:36 -05:00
Jasper St. Pierre
7cdb75e7ce Defer initializing UI until after the global session has loaded
https://bugzilla.gnome.org/show_bug.cgi?id=694321
2013-03-07 16:35:36 -05:00
Ray Strode
1dceae97c6 Revert "Defer initializing UI until after the global session has loaded"
This reverts commit 0bef925b51.

Just for now.  Jasper has plans to clean up start up eventually.

https://bugzilla.gnome.org/show_bug.cgi?id=694321
2013-03-06 17:26:15 -05:00
Jasper St. Pierre
0bef925b51 Defer initializing UI until after the global session has loaded
https://bugzilla.gnome.org/show_bug.cgi?id=694321
2013-03-06 14:55:58 -05:00
Jasper St. Pierre
0ba1f29e40 main: Merge two different session-mode-updated handlers
https://bugzilla.gnome.org/show_bug.cgi?id=694321
2013-03-06 14:34:59 -05:00
Florian Müllner
3b1e536822 screenShield: Drop fallback implementation
With fallback mode gone, we can no longer rely on gnome-screensaver
being installed. Rather than handling three different cases (GDM,
gnome-screensaver, no lock), disable the lock functionality when
not running under GDM.

https://bugzilla.gnome.org/show_bug.cgi?id=693403
2013-03-06 16:22:07 +01:00
Florian Müllner
9a83662a18 loginManager: Move UnlockDialog.isSupported() here
With fallback mode dropped, we can no longer rely on gnome-screensaver
to be installed, so we'll have cases where we are unable to lock the
screen. The user menu should not show the "Lock" item in this case,
but as UnlockDialog includes UserMenu, we cannot use the existing check
without creating a circular dependency; move the function to a more
generic place to fix.

https://bugzilla.gnome.org/show_bug.cgi?id=693403
2013-03-06 16:22:07 +01:00
Ray Strode
020128b9ca background: don't use raise_top() since it's costly
We currently resync the stacking order of the two key frames
every iteration of the animation.  This is costly and unnecessary.

This commit ensures they're stacked properly up front and doesn't
touch them after that.

https://bugzilla.gnome.org/show_bug.cgi?id=694993
2013-03-05 16:03:12 -05:00
Jasper St. Pierre
1566a4e607 unlockDialog, loginDialog: Connect to the activate signal on the entry
This is the recommended way to connect to an entry's activation binding --
event bubbling is not guaranteed by ClutterText.

https://bugzilla.gnome.org/show_bug.cgi?id=695154
2013-03-05 15:25:11 -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
Ray Strode
260c082c4e main: defer session update until startup animation
We currently call the session updated handler as soon as
the session modes are read.  This handler sets up keybindings
for leaving the overview (if a user session) and shows the
login dialog (if a gdm session).

We can't do the latter until the stage is mapped because it
takes a grab, and we don't need to do the former until the
user goes into the overview.

This commit defers processing session updates until the
the layout manager says start up is prepared.

It fixes a race condition at login screen startup now that
we don't show the stage right away.

https://bugzilla.gnome.org/show_bug.cgi?id=694321
2013-03-04 16:45:32 -05:00
Ray Strode
5e0ff7fd56 main: don't explicitly hide the stage
It's hidden by default, so there's no point in hiding it explicitly.

https://bugzilla.gnome.org/show_bug.cgi?id=694321
2013-03-04 16:45:32 -05:00
Cosimo Cecchi
aac312ca34 overviewControls: only show chat icon in messages indicator for chats
Only show the chat icon in the new messages indicator when at least one
among the outstanding notifications is a chat.
2013-03-04 16:25:50 -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
Giovanni Campagna
ee50904147 Calendar: only show events when configured in Evolution
When no calendars are enabled, hide the events pane completely instead
of showing it empty.

https://bugzilla.gnome.org/show_bug.cgi?id=680083
2013-03-04 18:59:30 +01:00
Giovanni Campagna
beb0fdf4b8 Calendar: clean up code by always having an event source
Instead of sometimes having an event source and sometimes not, use
the empty event source when the session mode says the calendar is
disabled. This way, the code can assume an event source object and
avoid checks.

https://bugzilla.gnome.org/show_bug.cgi?id=641383
2013-03-04 18:59:30 +01:00
Giovanni Campagna
443fe813c3 Calendar: freeze updates when the event source is loading
Check if the event source is currently doing an async call, and prevent
UI updates in that case. This avoids a flash of "No updates" when switching
months.

https://bugzilla.gnome.org/show_bug.cgi?id=641383
2013-03-04 18:59:30 +01:00
Giovanni Campagna
69cdc5a9b9 Calendar: force all months at the same height
Add one or two weeks from nearby months to avoid changing the menu height
when navigating it.

https://bugzilla.gnome.org/show_bug.cgi?id=641383
2013-03-04 18:59:30 +01:00
Rui Matos
e5ca53e56c status/keyboard: Don't allow the switcher in the message tray
SwitcherPopup relies on being able to pushModal(), setting the stage
input mode to FULLSCREEN, and then doing regular event processing on
the actor it adds to uiGroup. But MessageTray uses GrabHelper which
sets up a 'captured-event' handler on the stage and thus gets all
events itself.

This, of course, breaks the switcher if it's brought up in the message
tray so, for now, we'll just prevent it from being used there.

https://bugzilla.gnome.org/show_bug.cgi?id=693907
2013-03-04 18:32:49 +01: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
3368e49aa7 main: drop superfluous Lang.bind(this, ...)
Jasper noticed this and I forgot to clean it up before pushing,
then I just noticed it again when doing some other patches

https://bugzilla.gnome.org/show_bug.cgi?id=694326
2013-03-04 11:35:36 -05:00
Florian Müllner
9e31f05861 shellEntry: Disable copy action for password entries
Curently it is possible to copy the content of password entries,
and paste it elsewhere in clear text. This is undesirable, so
follow GTK+'s behavior and disable the copy action for password
entries.

https://bugzilla.gnome.org/show_bug.cgi?id=695104
2013-03-04 16:43:59 +01:00
Florian Müllner
6d011a3700 workspacesView: Always zoom out switcher when using static workspaces
We always leave the workspace switcher zoomed out when we can assume
that the user is actually making use of workspaces. For the default
dynamic workspace behavior, we make this assumption when more than
two workspaces are in use (e.g. at least two workspaces contain windows
plus an empty one at the end). However this test does not make sense
when using static workspaces - in that case, not using workspaces
would be indicated by a workspace number of 1 (in which case the
entire switcher is hidden completely), so add a check for dynamic
workspaces to the condition.

https://bugzilla.gnome.org/show_bug.cgi?id=695126
2013-03-04 15:51:25 +01:00
Florian Müllner
f9d9caf417 switcherPopup: Remove separator support
Since the alt-tab switcher stopped using separators, the functionality
is unused, remove it.

https://bugzilla.gnome.org/show_bug.cgi?id=661156
2013-03-04 15:28:38 +01:00
Florian Müllner
b50702dd52 altTab: Ignore workspaces in popups
Currently both the app switcher and the thumbnail list divide items
first into two groups (based on whether the item is located on the
current workspace or not), and then sort each group individually
by MRU.
The resulting behavior is often confusing, e.g. when using alt-tab
a second time does not switch back to the original window when the first
invocation involved a workspace switch and the workspace contains
windows of more than one application.
Instead, make the behavior more predictable by sorting both lists
strictly by MRU.

https://bugzilla.gnome.org/show_bug.cgi?id=661156
2013-03-04 15:28:37 +01:00