We support third party themes, via the "stylesheetName" property of a
mode's json files. However, our external CSS API is not completely
stable. If a third party theme wants to work on multiple gnome-shell
versions - for example because it is shipped as a Flatpak or a Snap - it
is not possible to ensure that a theme corresponding to the running
gnome-shell version is loaded.
GTK+ loads themes from versioned directories, search backwards from the
current version. Let's do the same in gnome-shell too. Then a downstream
theme can be shipped in $datadir/gnome-shell/3.28/theme/.
We keep searching all of the current paths. Additionally, the default
case where we look for the 'gnome' theme as a resource in the binary
continues to be the default so there are no additional lookups for users
of this theme.
Modes, extensions and other GNOME Shell assets are searched in appropriate
subdirectories of each directory in XDG_DATA_DIRS, falling back
to global.datadir.
However, this isn't the case for themes, which are currently always expected
in global.datadir, even when referenced by a mode in a different XDG_DATA_DIR.
The fix is to have the theme finding pattern follow the same logic as other
elements.
Fixes#167.
When not using arrow notation with anonymous functions, we use Lang.bind()
to bind `this` to named callbacks. However since ES5, this functionality
is already provided by Function.prototype.bind() - in fact, Lang.bind()
itself uses it when no extra arguments are specified. Just use the built-in
function directly where possible, and use arrow notation in the few places
where we pass additional arguments.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/23
This is a ClutterInputMethod implementation using IBus underneath. The
input method will interact with the currently focused ClutterInputFocus,
be it shell chrome or wayland clients through the text_input protocol.
Show a dialog informing the user each time the keyboard accessibility
flags are changed by one of the clutter backends (either from toggle
keys or two-keys-off modifiers).
https://bugzilla.gnome.org/show_bug.cgi?id=788564
Using a unicode character here means it may look quite different
from the intended style (for instance with emoji fonts). Avoid
this by providing a custom icon and use that instead.
https://bugzilla.gnome.org/show_bug.cgi?id=766368
The legacy tray introduced as part of the notification redesign in
3.16 was meant as a stop-gap solution to encourage applications to
move away from the concept of status icons, but it hasn't really
done anything except of getting in the way. Given that the large
majority of apps that still make use of status icons work perfectly
fine without them, we decided that it is time to drop this unloved
bit of UI altogether. Users who still want them (or use one of the
odd cases where an app really depends on the icon) can install one of
various extensions that are available, either based on the XEmbed
support that is still kept around or implementing the DBus-based
StatusNotifier spec.
https://bugzilla.gnome.org/show_bug.cgi?id=785956
Any symbols (including class properties) that should be visible
outside the module it's defined in need to be defined as global.
For now gjs still allows the access for 'const', but get rid of
the warnings spill now by changing it.
https://bugzilla.gnome.org/show_bug.cgi?id=785084
Symbols that are defined with 'let' are no longer visible outside
the module that defines them. To unbreak the code base, define all
non-private properties as global.
https://bugzilla.gnome.org/show_bug.cgi?id=785084
This is an implementation of the pad OSD that's been previously
present in gnome-settings-daemon. Since things are moving closer
to the compositor, it makes sense to have this implemented as shell
UI.
https://bugzilla.gnome.org/show_bug.cgi?id=771067
If a sandboxed app requests access to some system resource (camera,
microphone, location), the portal frontend needs to ask the user
for permission. In GNOME, we want this to be a system modal dialog,
so provide an org.freedesktop.impl.portal.access implementation
that exposes a generic system modal permission dialog on the bus.
https://bugzilla.gnome.org/show_bug.cgi?id=768669
It is not always possible to determine the type of audio device that
got plugged in. Add a system modal dialog to query the user in that
case and export in on the bus to gnome-settings-daemon.
https://bugzilla.gnome.org/show_bug.cgi?id=760284
If activateWindow() is called as the result of activating an item
in the Time & Date drop-down (most likely a notification), it should
behave as other items and close the calendar.
Commit 5a8923ef95 removed support for legacy status icons from
the notification system, as we no longer want them to appear as
notifications. As we are unfortunately not quite at a point where
we can remove all support for them for good, so we now need an
alternative place to put them. Add a small dedicated tray at the
bottom which appears when any legacy status icons are active. By
default it is almost completely hidden to not interfere with the
user's windows, but can be expanded on demand to interact with
the icons.
https://bugzilla.gnome.org/show_bug.cgi?id=745162
Display notifications that have not been dismissed in the message
list - eventually this will replace the existing message tray summary.
Notification messages show icon, title and one line of the body and
can be clicked to activate the default action. However they cannot be
expanded, so other actions or the full body text are not accessible
in this mode.
https://bugzilla.gnome.org/show_bug.cgi?id=744817
This DBus API is intended to be used by gnome-control-center's
displays panel to show monitor labels.
Each output (i.e. hardware monitor) identified by its
org.gnome.Mutter.DisplayConfig API ID has at most one label. On
mirrored setups, all the labels for outputs corresponding to the same
logical monitor (i.e. showing the same contents in the same mode) are
shown together.
At most, only one DBus client at a time is allowed to show labels.
https://bugzilla.gnome.org/show_bug.cgi?id=743744
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.
