At least for the time being, this looks like the easiest option to
launch the service:
- we could add a systemd unit, but then we'd need to update the
RequiredComponents in the fallback session definition as well,
making it necessary for gnome-shell, gnome-shell-extensions and
gnome-session to be updated to 3.36.1 in lockstep
- autostart is problematic as it would make gnome-shell conflict
with other notification daemons; also autostart is most useful
with automatic shutdown, which would require tracking signal
subscriber to determine when the service is unused
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/547
Add a small service that exposes the Fdo notification API under the
well-known name, and forwards any requests to the actual implementation
in the shell.
That way any app with permission to talk to org.freedesktop.Notifications
will get exactly that, and nothing more.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/547
There are a couple of D-Bus services that are currently provided by
gnome-shell for which it makes sense to move them fully or partially
into separate processes:
- screen recording (performance)
- FDO notifications (security)
- Extensions (portalization)
Add some base classes and build system glue to take care of the
common boilerplate.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/547
This caches GAppInfo so that the compositor thread does not have to perform
costly disk access to load them. Instead, they are loaded from a worker
thread and the ShellAppCache notifies of changes.
To simplify maintenance, ShellAppCache manages this directly and the
existing ShellAppSystem wraps the cache. We may want to graft these
together in the future, but now it provides the easiest way to backport
changes to older Shell releases.
Another source of compositor thread disk access was in determining the
name for an application directory. Translations are provided via GKeyFile
installed in "desktop-directories". Each time we would build the name
for a label (or update it) we would have to load all of these files.
Instead, the ShellAppCache caches that information and updates the cache
in bulk when those change. We can reduce this in the future to do less
work, but chances are these will come together anyway so that is probably
worth fixing if we ever come across it.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2282
These paths are meant for Xwayland, not for X11 compositors being restarted
through alt-f2 + r. Maybe some signal analogous to init-xserver should be
added for Xwayland shutdown paths, but this signal we are currently
listening for is backend agnostic.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/2329
Since the FolderViews are not connected to the "installed-changed"
signal, we need to reload their apps by calling _redisplay() when an app
is removed or installed. We can't connect to "installed-changed" inside
FolderView because we need to ensure _redisplay() of the FolderView is
called before AppView tries to access the apps of the folder inside
_refilterApps(). So reload the FolderViews inside AllViews _redisplay()
implementation to ensure everything is up to date before accessing the
apps of the folder.
Since the "apps-changed" signal of FolderIcon now indirectly triggers a
_redisplay() of the FolderViews, the 'changed' handler of FolderView is
now redundant and can be removed. Because of this, we also need to move
the emission of the "apps-changed" signal to the start of the signal
handler to make sure the view is updated before we try to access items
of the view.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1901https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1011
We should disconnect the folders "changed" signal from the folder in
case the FolderView or FolderIcon is destroyed. While at it, also remove
the unused this._spaceReadySignalId of FolderIcon.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1011
The _redisplay() function is usally used for subclasses of BaseAppView
which want to implement their own _redisplay() function, having that
function name in two classes which have nothing to do with BaseAppView
can be quite confusing. Make those names less confusing and call the
functions _sync() and _rebuildMenu() instead.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1011
The viewBox has a border applied, so when we call adaptToSize using only
the content box of the container, the width of the border is not removed
from the content box and the grid will be allocated less space than what
we told it before using adaptToSize.
Fix that by adjusting the content box for the size of the viewBox, too.
This makes sure the correct amount of columns can be shown inside a
folder, since right now we only show 3 colums even though 4 would fit.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1011
Since 38da479ee we correctly ceil the non-integer radius of the slider
handle when calculating the offset for drawing the circle. Since the
handle also has a border with a width of 1px by default, we should also
factor that in when calculating the offset.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1569
Along the lines of `styleSheetName`, a session mode may want to provide its
own gresource file, so make this possible via a `themeResourceName` session
mode parameter, defaulted to gnome-shell-theme.gresource
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1063
Unlike any other methods in the Extensions API, LaunchExtensionPrefs()
opens what appears to be an application dialog, except that it is
really a separate application that the caller has no control over.
In order to address that, add a new OpenExtensionPrefs() method that
takes additional parameters (modelled after the desktop portal APIs)
that will make it possible to improve the behavior in the future.
The new parameters are ignored for now, but pushing the API out now
will allow us to fill in the functionality post the .0 release.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1074
The 'disable-user-extensions' GSettings key is the last extensions-related
setting that isn't exposed over D-Bus, and therefore requires consumers
to access the GSettings directly.
Expose the setting as UserExtensionsEnabled readwrite property in the
org.gnome.Shell.Extensions interface to allow consumers to manage
extensions purely via D-Bus.
The 'disable-user-extensions' setting is the last extension-related
bit from the org.gnome.shell GSettings schema that is not exposed
via D-Bus.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1074
This (mistakenly) now only depends on signals triggered on Wayland
sessions. Hardcoding the XIM support on X11 sessions will make input
in some clients work again.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/1690
Currently, a failure to start the Systemd unit `gsd-xsettings.target`
would be considered a failure to start Xwayland.
That means that if `gsd-xsettings.target` fails to start for whatever
reason, no X11 client can be used on Wayland.
However, XSettings is by no mean mandatory for X11 clients and many
legacy X11 clients do not implement XSettings. Those who do always have
a fallback path and therefore can still work without XSettings.
Make a failure to start the Systemd unit `gsd-xsettings.target` non
blocking for Xwayland, and just log a warning message.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1065
We ended up always showing the switch-user button on the lock screen,
as showing and hiding it with the prompt was too visually distracting.
But now that we have a fancy transition in place, we can easily extend
it to the switch-user button as well.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1029
We only call _updateSensitivity() to make elements sensitive, and
nothing ever touches the sensitivity of the switch-user button; so
just call the corresponding authPrompt method directly, which is the
only bit that has an actual effect.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1029
We do spawn gsd-xsettings, and watch its name before notifying on the
given task, so the mutter bits can proceed with X11 startup.
One notable change is that we only start gsd-xsettings, instead of the
generic gnome-session-x11-services target. We do so as we have to wait
on a dbus name to appear in order to deem the initialization done, and
making it all depend on gsd-xsettings seems tidier.
Less notably, we also use ::shutdown-xserver to shutdown the related
services. Its major benefit is that it'd allow us to ensure the olderly
shutdown of those services, but it's unused at the moment.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/836
When a window is being resized by the compositor, with Wayland the
compositor first asks the window to change its size and emits the
"size-change" signal, and then emits the "size-changed" signal after
the window acknowledges the new size. To show a fancy resize animation,
gnome-shell creates a "screenshot" of the resizing window on the
"size-change" signal, and later animates that "screenshot" to the new
window size on the "size-changed" signal.
Now if a client is not responding to our requests asking it to change
its size, we get a "size-change" signal and start showing the
window-clone, but never a "size-changed" signal, animating and hiding
the clone again. This causes a so called "ghost window" that is shown
above everything else and never disappears again.
To fix that, start showing the window clone once we get the
"size-changed" signal instead of the "size-change" signal. This makes
sure the window actually updates its size and the clone is going to be
hidden again.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/1078https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1055
Creating a new GTimeZone for the local timezone can be quite expensive if
done repeatedly. It requires an open(), mmap(), and parsing of
/etc/localtime.
This patch was provided by Florian, and I've tested it as far back as
3.28.4 to ensure that we are really reducing the number of open() calls
on the compositor thread.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1051
Signed-off-by: Christian Hergert <chergert@redhat.com>
The thumbnails actor `this._thumbnails` has already been destroyed when
calling `_destroyThumbnails()` from the `destroy` signal handler because
it is a child actor of the AppSwitcherPopup. So stop destroying the
thumbnails separately (fading them out inside a destroy handler wouldn't
make sense anyway).
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/167
The correct property for the scroll-direction with scrolling events is
`direction`, no `scroll_direction`. This fixes scrolling in the alt-tab
popup, which broke with the actorization changes.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/167
When the switcherPopup was initiated successfully, we return true,
otherwise the WindowManager will try to destroy it. Since an early
release of the keystroke will also switch to another application and
close the switcher just fine, we should return true to indicate success
here.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/167
Right now the index that gets selected on click and motion events is set
when connecting the event inside the addItem function. If items are
added or removed (for example when an application is closed by pressing
"q"), this index isn't valid anymore and has to be updated.
To fix this, use the items themselves instead of the index as arguments
for the event handlers and lookup the index of the item inside the event
handler.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/167
Set the accessible states of the switcherList items by calling a
function instead of manipulating class-internal variables from outside
the class, which is considered bad practice.
The check whether the item at `_selectedIndex` exists can also be
removed since we always select a new index after an item was removed
(i.e. an app was closed) and destroy the alt-tab switcher right away if
no more items exist (see `SwitcherPopup._itemRemovedHandler`).
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/167
Limit the minimum and maximum value to scroll to inside the box to 0 and
the upper limit, for some reason this was done right in _scrollToRight,
but not in _scrollToLeft.
This fixes the behavior of scrolling to the left: Before, scrolling one
item to the left moved the view to the first element of the list (this
can make the selected element invisible in large lists). Instead, scroll
one item to the left, just like scrolling to the right works.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/167
Make sure the index that's being scrolled to doesn't change while the
scrolling animation is running by using an argument instead of the
this._highlighed class scope variable.
This fixes wrongly shown arrows when selecting new elements faster than
the scrolling animation takes for one index. The check run to disable
the arrow might be checking against a newer index than the one at the
start of the animation which results in the arrow not getting hidden
even if no more scrolling is possible.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/167
Since this._highlighted is always set to the currently highlighted
index, there's no need to save the index to a separate variable. This
obviously depends on getting the new item highlighted as a result of the
item-entered event.
This fixes bugs in situations where the highlighted element changes
after an event that is not calling _onItemEnter, for example after
scrolling or pressing a key. In those cases the _currentItemEntered
variable wouldn't be updated and the old item couldn't be entered
anymore without entering another one before.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/167
Visually the button is just an interactive label, so having the
interactive area extend to the empty space next to the label
is surprising.
Instead, left-align the whole button rather than just the label
inside, so the clickable area corresponds to the visible one.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1046
The 'gdm' user is not going to run a media player, so there is no
point in allowing the corresponding section on the login screen.
All other sections are already disabled, so this is the only reason why
we end up with the message list instead of only showing the calendar.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2241
This reverts commit c0c027c608. Because for
some reason animating external opacity and position is still incurring
internal repaints, which disables offscreening and makes fading of
overlapping actors look wrong. `ON_IDLE` should be fixed in mutter before
it is used (in boxpointer at least) again.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/2270
If the sessionMode does not allow to show the overview, we should also
hide an already visible overview.
This fixes a bug where, if the lockscreen was shown while the overview
was visible, the Ctrl+Alt+Tab popup would allow navigating inside the
overview because the overview actor is still mapped.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1043
If a transition is reversed, the final property values will be the
same as before the transition. However this currently only works
correctly when we actually use a transition; to fix this with a
duration of 0, simply skip the set() call when the transition is
reversed.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1042
While the unread messages indicator is updated when starting a new
session because we call _onSourceAdded() on existing sources, we should
also update the do-not-disturb setting which might still be enabled.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1037
