This will replace the indicator painted on the stage right now.
This unfortunately does not work for the recorder triggered by the
keybinding -- we'll simply replace the in-shell code with a keybinding
powered by gnome-settings-daemon.
We currently monitor the shell's override schema for changes to
the 'dynamic-workspaces' key, which ends up being the wrong
schema in classic mode. With the new ability to use mode-specific
overides, we can finally fix this.
https://bugzilla.gnome.org/show_bug.cgi?id=701717
This will allow the use of mode-specific defaults. For classic mode
we currently implement this with mini-extensions, but this may result
in confusing behavior when settings change due to extensions being
disabled during screen locks (not to mention that those mini-extensions
are hardly an elegant approach).
https://bugzilla.gnome.org/show_bug.cgi?id=701717
We will allow to use mode-specific overrides; in preparation for that,
move the code so that we only override preferences after initializing
the session mode.
https://bugzilla.gnome.org/show_bug.cgi?id=701717
There is not always a clear distinction between code and style,
which is why the interface ends up being mostly unusable when we
end up without *any* style, for instance because the specified
application-stylesheet is corrupt.
Setting the default stylesheet in addition to the application-stylesheet
is no guarantee for non-default themes not messing up the interface, but
it should at least lower the risk ...
https://bugzilla.gnome.org/show_bug.cgi?id=700097
With sticky keys, users should be able to press and release a
modifier and then press a key to activate a modifier-key combination.
Activating the overview on the Super key release keeps these
users from using keyboard shortcuts involving the Super modifier.
The solution implemented here is to simply disable the Super-release
binding if sticky keys are enabled. It is still possible to go
to the overview by using Super-S or Alt-F1.
https://bugzilla.gnome.org/show_bug.cgi?id=685974
Since commit 7cdb75e7ce, initializing UI is deferred until the session
mode has been loaded. However DBus is still initialized immediately,
which means that for DBus methods that access properties in Main, there
is now a window between the method being exposed on the bus and the
method being ready to be called. At least g-s-d grabbing global keybindings
is likely to fall in this window on session startup, and almost guaranteed
when regrabbing bindings after a shell restart.
To fix, defer initializing DBus as well.
https://bugzilla.gnome.org/show_bug.cgi?id=694321
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
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
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
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
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
Implement a basic OSD popup that shows an icon and optionally a label
and a fill level. It is based on the existing OSD implementation in
gnome-settings-daemon, which it will replace.
https://bugzilla.gnome.org/show_bug.cgi?id=613543
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
Mutter now makes session registration an explicit required
step. This is so we can tell the session manager when
we're ready to move on to the next phase.
This commit calls the new Meta.register_with_session() api after we're
initialized.
https://bugzilla.gnome.org/show_bug.cgi?id=694876
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
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
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
commit 92083eaf76 made
session mode loading an asynchronous operation.
Aspects of the session mode aren't known immediately at
start up. For instance, sessionMode.isGreeter returns
false for greeter sessions until the asynchronous
operation completes.
This commit defers start up processing until the session
mode is fully known.
https://bugzilla.gnome.org/show_bug.cgi?id=682429
The activities button may come and go at any moment now that we
have a dynamic panel. We need to re-check the activities button
whenever the panel is updated.
https://bugzilla.gnome.org/show_bug.cgi?id=694038
With the new flexible system in place, there's no point explicitly
hardcoding some built-in keybindings; just use the generic mechanism
for everything.
https://bugzilla.gnome.org/show_bug.cgi?id=688202
For now we just use it to assign an identifier to modal modes in
which we want to allow some keybindings, but we don't use it for
any actual filtering; we'll start doing this shortly.
https://bugzilla.gnome.org/show_bug.cgi?id=688202
We are currently using a hack to allow a select set of keybindings
in the overview. Implement the new MetaPlugin keybinding_filter
hook, which provides a cleaner way to achieve the same.
https://bugzilla.gnome.org/show_bug.cgi?id=688202
Entering the overview with the overlay key is done on key release but
exiting the overview on key press, which is inconsistent.
This change makes the overview hidden also on key release.
https://bugzilla.gnome.org/show_bug.cgi?id=683024
The screenshield requires gdm 3.5, which can be problematic in
jhbuild configurations, or distributions that don't use GDM as the display
manager. Allow transparent fallback to gnome-screensaver in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=683060
Remove the PlacesManager, its search provider and all associated code.
Places search is now provided by nautilus using the external search
provider API.
https://bugzilla.gnome.org/show_bug.cgi?id=683506
As PAM messages are now shown below the password entry, there is no
need for this complexity, and we can just hide all notifications.
Also, this avoids the ambiguity between notification.showWhenLocked and
source.showInLockScreen, which have very different effects.
https://bugzilla.gnome.org/show_bug.cgi?id=683369
The stage's background color can visible on screencasts when multiple monitors
with different resolutions are in use.
Change it to from blue to grey to look better as requested by the designers.
https://bugzilla.gnome.org/show_bug.cgi?id=683514
Have main.js call .showDialog() when going back from the lock-screen, instead
of using the return value of createUnlockDialog to know if the dialog
was persistent.
_keepDialog is still used as LoginDialog cannot really be destroyed,
and cancelling it does not destroy it.
https://bugzilla.gnome.org/show_bug.cgi?id=683156
Components are pieces of the shell code that can be added/removed
at runtime, like extension, but are tied more directly to a session
mode. The session polkit agent, the network agent, autorun/automount,
are all components, keyring, recorder and telepathy client are all
now copmonents.
https://bugzilla.gnome.org/show_bug.cgi?id=683156
Since we eventually want to add a system for changing the top panel
contents depending on the current state of the shell, let's use the
"session mode" feature for this, and add a mechanism for updating the
session mode at runtime. Add support for every key besides the two
functional keys, and make all the components update automatically when the
session mode is changed. Add a new lock-screen mode, and make the lock
screen change to this when locked.
https://bugzilla.gnome.org/show_bug.cgi?id=683156
The supposed reason for launching the calendar server in a peculiar
way was so that the process would be killed when the Shell was killed,
but that didn't actually work. Launch the calendar server through auto-start,
and persist all throughout the session.
https://bugzilla.gnome.org/show_bug.cgi?id=683156
We already could build the right part of the panel declaratively according
to the session mode. Extend that to handle the left and center parts.
Also, move the mapping from the roles to the classes in panel.js, as it shared
by all modes.
https://bugzilla.gnome.org/show_bug.cgi?id=682546
Use the new OVERLAY_KEY keybinding action instead of special-casing
the overlay-key to make sure the same key will be used in- and outside
the overview.
https://bugzilla.gnome.org/show_bug.cgi?id=665547
gnome-session and gnome-settings-daemon rely on the screensaver
interface to know the locked state. Since gnome-screensaver is no
longer running, it's up to gnome-shell to provide it.
https://bugzilla.gnome.org/show_bug.cgi?id=619955
Track screen lock status in the message tray, and filter banner
notifications. The message tray is completely hidden when the screen is
locked, but exceptions can be made for individual transient notifications,
such as shell messages and the on screen keyboard.
Non transient sources are shown in the middle of the lock screen. Resident
notifications (such as those from Rhythmbox) are shown in full, while
persistent ones are displayed as icon and message count.
https://bugzilla.gnome.org/show_bug.cgi?id=619955
The design calls for the curtain to appear in the gdm greeter too.
Implement this by having the screenshield manage the login dialog
(delegating its creation to SessionMode).
https://bugzilla.gnome.org/show_bug.cgi?id=619955
We are replacing the gnome-screensaver module with with a screen shield
that is part of gnome-shell.
This patch fades out the screen on idle and shows a shield with a background
image when there is activity again. The shield can be removed with a key or
button press.
https://bugzilla.gnome.org/show_bug.cgi?id=619955
Destroyed modal actors should be completely removed from the modal
stack automatically, including leaving modality if needed.
This allows for destroying modal dialogs without calling close().
https://bugzilla.gnome.org/show_bug.cgi?id=619955
Use the ShellMountOperation dialogs we have to implement a DBus API
allowing other processes to display them.
Since GtkMountOperation now tries to call into our DBus implementation,
every application that uses a GtkMountOperation will gain integration
with our shell dialogs (but will still handle the actual communication
with GVfs).
https://bugzilla.gnome.org/show_bug.cgi?id=678516
When the shell takes control of the screen (for example to show
a modal dialog or to lock the screen), it must reestablish itself
on top of the stack, and in particular restore any unredirected
window so that it is composited below the Shell UI.
Reviewed-By: drago01 in IRC.
Initially, extensions were loaded after they shell had fully created
the session and all objects, but this didn't allow extensions easy
ways to monkey patch prototypes, as most functions had already been
bound. Remove the historical vestigal function, and just merge the
two together.
https://bugzilla.gnome.org/show_bug.cgi?id=677586
In Shell.SessionType.USER mode, two separate setup functions were
used during startup. With the new feature-based checks, the second
one is now almost empty, so move its remaining code into the first
function and remove it.
https://bugzilla.gnome.org/show_bug.cgi?id=676156
Add a sessionMode.allowKeybindingsWhenModal property, which determines
whether keybindings should still be handled while a modal dialog is
up or not.
https://bugzilla.gnome.org/show_bug.cgi?id=676156
Rather than accessing global.session_type / global.session_mode
all over the place, delegate mode information to a dedicated
sessionMode object. While not very useful for now, we will replace
checks for a particular mode with checks for particular properties
that sessionMode defines based on global.session_mode.
https://bugzilla.gnome.org/show_bug.cgi?id=676156
Pausing means that we will continue to use the same output file when
the keybinding is activated again. While useful to record a single
video in chunks, it doesn't seem to be how most users understand the
keybinding. Closing the recorder will close the file and create a new
one the next time the keybinding is pressed.
https://bugzilla.gnome.org/show_bug.cgi?id=675128
