While the default Shell style is fairly decent with regard to
accessibility requirements, having the ability to tweak certain
aspects where the regular style works less well is still useful.
For this purpose, try to load a -high-contrast theme variant of
the default stylesheet when a high-contrast theme is requested
(as determined by the GTK+ theme name).
https://bugzilla.gnome.org/show_bug.cgi?id=740447
Since moving to a GFile based API in commit 642bf2b778,
setThemeStylesheet() no longer accepts %null to revert to
the default theme. We should have some way to revert to the
default and the least intrusive option is to return to the
old behavior, so do that.
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
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
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
Commit 6c2f3d1d17 moved pref overrides into JS to implement
session mode specific overrides in a clean and generic way.
However that approach comes with a cost - doing the overrides only
after having handled over control to JS means that the core will
be initialized with the non-overridden settings before changing
to the correct values. In the best case this is unnecessary work,
but it can in fact have a worse effect: when initializing workspaces,
we will restore the previous number of workspaces when using
dynamic-workspaces and reset to the configured number otherwise.
As the non-overridden default for dynamic-workspaces is FALSE, we
can easily end up moving the user's windows to the "wrong" workspace.
Now GSettings is expected to grow support for session specific defaults,
which will render our entire override system obsolete (yay!). Given
that, it seems acceptable to use a less generic (and uglier) approach
in the meanwhile, in order to fix aforementioned problems. So move
overrides back before core initialization and just hardcode the
session-mode => override-schema relation.
https://bugzilla.gnome.org/show_bug.cgi?id=695487
We only need GSystem when running under systemd. As libgsystem itself
has a hard dependency on systemd, only import it when actually needed
to keep working on systems where systemd is not available.
https://bugzilla.gnome.org/show_bug.cgi?id=728449
We had one osdWindow that we displayed either on the primary monitor or on
whatever monitor index got passed over dbus.
Change that to show the osd on all monitors when no explicit monitor is
requested. A monitor should be requested in cases like display brightness where it makes sense to only show the osd on the affected monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=722684
The asynchronous nature of extension loading, session loading, and more,
makes the code racy as to what is initialized first, and hard to debug.
Additionally, since gjs is single-threaded, the only code we're running
in a thread anyway is readdir, which is going to be I/O bound, so the
code here is actually likely to be faster.
Drop this in favor of some good old fashioned synchronous loading.
We already do this for looking glass, but it makes even less sense
for the normal run dialog - if a mode sets runDialog to false, the
intention is to not allow executing aribitrary commands.
https://bugzilla.gnome.org/show_bug.cgi?id=708218
Build gnome-shell for x11, and gnome-shell-wayland for wayland
(as well as the associated libgnome-shell and libgnome-shell-wayland).
The first one links to libmutter, the second to libmutter-wayland.
libgnome-shell and libgnome-shell-wayland are now compiled from
libgnome-shell-base (with all sources that are independent of mutter),
libgnome-shell-menu (with the copy-pasted gtk sources), plus the
sources that use mutter API
https://bugzilla.gnome.org/show_bug.cgi?id=705497
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
