Showing multiple preference dialogs at the same time (for instance
by repeated `gnome-extensions prefs` calls) may or may not work as
expected, depending on whether any of the dialogs is modal or not
(read: opened via the Extensions app).
The easiest way to address this is to disallow more than a single
dialog at the time. It's arguably also the more predictable behavior,
and means extensions don't have to deal with inconsistent state
caused by multiple dialogs.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4564
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2013>
(cherry picked from commit b93342f72e)
GTK4 relies entirely on refcounting for cleanup (that is,
there is no longer a destroy() method that forces a dispose
run regardless of the refcount).
Unfortunately that makes cleanup harder in (some) language
bindings, where an object may be kept alive implicitly by
closures etc.
Address this by releasing the hold count when the window
is closed rather than when it is destroyed.
This isn't the most elegant, but it ensure that the service
doesn't get stuck if an extension doesn't carefully clean
up everything in its prefs widget.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4564
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2013>
(cherry picked from commit 4d2b008966)
We currently ignore any error that may occur when calling the
OpenExtensionPrefs D-Bus method. Right now such an error is highly
unlikely, given that we already checked that we are running under
gnome-shell and the extension in question exists and has prefs.
We'll soon make sure that only one dialog is shown at any time,
which is an error that we can realistically expect, so handle that
properly.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4564
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2013>
(cherry picked from commit 09ed1c533c)
Windows from some applications, such as guake, are created as showing on
all workspaces. When these windows are put on the workspaces via
set_workspace_state() during construction, the first time the window is
added to a workspace in the loop triggers the shell app tracker which
then tries to move the window to its startup workspace. This makes the
window unsticky which triggers another set_workspace_state() which
tries to remove the window from all workspaces, but currently it is only
on the first one and then adds it to the startup workspace. Once that is
finished, the first set_workspace_state() continues adding the window
to the remaining workspaces, despite the window now no longer having
on_all_workspaces set to true.
When the window is now unmanaged, the window according to its internal
state is only found on the startup workspace, so it will only be removed
from that. This causes the assertion to fail that checks that the window
is no longer present on any workspace after this.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4720
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2014>
(cherry picked from commit bc32a52108)
Like the old Tweener API, ease() allows to transition multiple
properties at once. If autoReverse or repeatCount are specified,
they should apply to all transitions, but right now we only set
them for the first one.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2007>
(cherry picked from commit cc5cc0d653)
If the preedit is in invisible state, the last preedit string that
was sent around is already null, so there is no need to clear the preedit
in that case.
(Cherry-picked from commit 0177560952)
commit 8721c5db37 made StPasswordEntry
honor the 'disable-show-password' setting.
Unfortunately, it introduced a lifecycle bug where the signal handler
for noticing setting changes can out live the entry itself.
This commit fixes the problem by using g_signal_connect_object
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2004>
This job "needs" the build job and thus gets its artifacts, but
it will not inherit the environment where we already installed
Mutter in /usr. This apparently broke once there was a more
recent mutter-clutter .pc file to look up.
Install Mutter in /usr again in this job, so the new build for
coverity finds all dependencies.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1979>
If a user hits escape twice really fast when coming back to
their machine to unlock it, they made end up getting presented
with a non-functional unlock screen that doesn't show their
user icon and doesn't ask for a password.
This is because showPrompt assumes that if an auth prompt already
exists, it's ready to go. That may not be true, if it's in the
process of getting torn down at the time because it's in the middle
of a cancel animation.
This commit solves the problem by ensuring the auth prompt is always
in a fresh reset state before showing it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1999>
If the the unlock dialog gets finished before an auth dialog is
created, the code currently creates one just to tell it to finish.
This commit changes the code to skip creating the auth dialog in
that case.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1999>
Commit dd2cd6286c restricted callers of the screenshot methods to
portal implementations, gnome-settings-daemon and gnome-screenshot.
That restriction does make sense for the actual screenshot methods,
but `PickColor` is actually used by GTK in its color picker (and
therefore may be called from arbitrary applications).
Fix this by unrestricting access to `PickColor` again. Considering that
the method is always interactive, it's not very privacy/security-sensitive
anyway.
https://gitlab.gnome.org/GNOME/gtk/-/issues/4283
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1990>
Icons that are changed while an actor is not mapped may not have a theme
node associated with, and thus we'd end up not updating them at all.
In fact we return early in st_update_icon(), and this was not an issue
until commit 0b1dfbf6f3, because we'd end up to update the icon anyways
once the style was changed (and so with a valid theme node), but since
such change we might not updating the icon if no theme detail changed.
To prevent this, add a flag to require an icon update when the theme
changed, if no successfully update happened earlier.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4568
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1983>
St's theme test now requires the libmutter-test library, which is only
built when tests are enabled. Instead of mandating a particular build
configuration in mutter, add a corresponding option in gnome-shell as
well.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1975>
We currently just call sassc, but don't check its return value. That
means as long as sassc is available, the script (and therefore the
newly added dist CI job) will succeed.
Make sure we fail on failure.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1974>
So far, releases are done locally by invoking `meson dist`.
We can do better and leverage the existing CI infrastructure, to get
to the following release workflow:
- bump version in meson.build, update NEWS etc.
- open merge request for the release
- merge when the pipeline (including dist check) succeeds
- tag the release
- wait for the tag pipeline to spit out the tarball artifact
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1968>
Previously we used `get_image()`, which returned `cairo_surface`,
in order to create a `ClutterContent` with a screenshot of the
`MetaWindowActor`. This added a roundtrip from GPU to CPU memory.
Instead, use the new `paint_to_content()` API which lets us use a
`CoglTexture` directly as source of our `ClutterContent`.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1879>
This signal announces the preferred commit mode of the preedit text when
the input context is reset. Keep this mode around, and ensure to honor this
mode (e.g. maybe commit the preedit string) whenever the input method would
be reset.
This is delegated to the internal layers, so propagate this mode via
clutter_input_method_set_preedit_text().
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1929>
The Eval() method is unarguably the most sensitive D-Bus method
we expose, since it allows running arbitrary code in the compositor.
It is currently tied to the `development-tools` settings that is
enabled by default. As users have become accustomed to the built-in
commands that are enabled by the same setting (restart, lg, ...),
that default cannot easily be changed.
In order to restrict the method without affecting the rather harmless
commands, guard it by the new MetaContext:unsafe-mode property instead
of the setting.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3943
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1970>
Since touchpad smooth scroll events with source finger are handled by
the swipeTracker, the workspace scroll handler can focus on discrete
events.
Thanks to Mutter emulating discrete scroll events, see
meta_seat_impl_notify_scroll_continuous_in_impl in meta-seat-impl.c,
it is safe to ignore smooth scroll in the workspace scroll handler
and handle exclusively discrete events.
In addition, once high-resolution scroll events land in Mutter [1], a
mouse will be able generate non emulated smooth scroll events that
should be ignored in favour of the discrete scroll events.
Otherwise, a single mouse wheel click will scroll through multiple
workspaces at once.
[1] https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1962
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1959>
The keyboard is placed outside of the screen when shown and then slides
in via a transition that changes the translate-y property. This
translation does not affect the allocation of the Keyboard actor and as
such does not trigger any of the signals LayoutManager is connected to
to update the input region. This means the input region remains at the
original position of the actor outside of the screen and as a result on
X11 clicks will go through to the underlying window.
There was a workaround for this by queuing a relayout at the end of the
transition, but this stopped working due to optimizations avoiding
unnecessary allocation changes.
This updates that workaround to toggle the visibility of the actor
instead, which is the other signal that LayoutManager reacts to. Once
ClutterActor provides better ways to react to transforms this can
hopefully be removed entirely.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4556
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1955>
Sometimes when an icon is dragged and dropped in Dash, one Favourite app icon
can appear to the right of Dash separator. This can happen when available system
resources are low and the PlaceHolder destroy animation is delayed and the
corresponding container child is still present. With this commit the separator
position is calculated correctly, even when the animation is pending.
Fixes#3966, #3799
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1804>
eee2ccac fixed window opacity being changed outside of transitions but
resulted in the final step of the transition, that would set the window
to fully opaque, being missed.
This change now moves the opacity change entirely out of allocation and
instead follows the adjustment changes directly, which still fixes the
original bug and ensures the opacity is also applied for the last step
in the transition.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4561
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1957>
GJS added a console module that extensions may start using. To ensure that
extensions using console.log() and similar functions don't show up as
'Gjs-Console' in users' system logs, we should call setConsoleLogdomain()
with 'GNOME Shell'.
This GJS API addition is only accessible using ECMAScript Modules (ESM),
this commit moves shell startup to a small init.js module and adapts
CI jobs to either handle or ignore it.
We can drop the .jscheckignore file when future versions of SpiderMonkey
allow for compile checks without validating module specifiers.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1958>
!1940 added support for soup 3, including a fallback to soup 2.4
where the newer version isn't available.
Unfortunately it missed that libgweather has a hidden soup dependency,
and now gnome-shell fails to start if a weather location has been set
up and soup 3 is available.
We don't have a good way to detect that case, so hide the soup 3 support
behind a build option. Distributors are expected to switch it at the
same time as libgweather.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1966>
Unlike for the old Soup.SessionSync/SessionAsync classes,
Soup.Session:ssl-use-system-ca-file already defaults to true.
In Soup3, the behavior was made unconditional and the property
removed.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1940>
Quoting the documentation:
In libsoup 2.44 and later, you can set the session's “proxy-resolver”
property to the resolver returned by g_proxy_resolver_get_default() to
get the same effect. Note that for "plain" SoupSessions (ie, not
SoupSessionAsync or SoupSessionSync), this is done for you automatically.
libsoup 2.44 was released in 2013, so we can safely assume that Soup is
new enough to handle this for us.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1940>
The code that handles extracting extension archives currently uses
an awkward double-callback system. We can do significantly better
by using an async function and exceptions.
Partially based on code from Marco Trevisan.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1940>
Move all remaining bits to the new coding style before making
further changes.
The let → const changes are selectively done to the bits that'll
still be around at the end of the patch series.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1940>
In addition to the changes in this commit, gjs now
restricts the use of the Format module and initFormat.
We can't really replace those for translatable strings
until xgettext gains support for template strings, so
leave that bit out for now.
The other notable change is that gjs now requires
jsdoc comments. We can't plainly enable those options
without a massive amount of work first, but let's see
how requiring doc comments for new code goes.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1949>
Which better communicates what we are checking for, and is a little more
elegant than repeatedly writing:
```
Main.overview.animationInProgress && Main.overview.visibleTarget == false
```
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1440>
We hide our own "New Window" item if the app itself includes a
"new-window" action. That means that the separator between the
built-in item and desktop actions introduces a small inconsistency
depending on whether a "New Window" item is provided by the desktop
action or ourselves. There's no good reason for that from a user's
perspective, so remove the separator.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1948>
The context menu in the overview includes actions for managing
favorites. Add those to the AppMenu class, but make it another
option as the actions would be slightly weird in the top bar menu.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1948>
The top bar menu always corresponds to a running app, so it made
sense to include the 'Quit' item unconditionally. That won't be
the case for the overview context menus, so handle app state changes
and show/hide the item as necessary.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1948>
Since commit fd0da9606f, we only show the "Open Windows" section
if there are at least two windows. That's another subtle difference
with the overview context menus, but while limiting the section to
a minimum of two windows makes sense where the menu always represents
a running app, it is useful to show the section even for single windows
in the dash/app grid.
Account for both uses cases by adding a corresponding option to the
constructor.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1948>
There's a subtle difference between the top bar menu and the app
icon context menus in the overview regarding the "Open Window"
section.
The former includes skip-taskbar windows, the latter doesn't. It
clearly doesn't make sense for the context menu to include windows
that aren't shown in the overview, but skip-taskbar windows are
likely also less useful in the top bar menu.
Just settle on the behavior of the context menus and move on.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1948>
This is the expected behavior when activating a window or app. Until
now we could rely on the menu being hidden in the overview, but as
that is about to change, make sure the menu behaves as expected.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1948>
App windows are ordered by recency, so a focus change (correctly)
triggers the ::window-changed signal. If we rebuild the section
immediately in response, the activating item will be destroyed
before the menu's ::activate handler, with the result that the
menu remains open.
Defer the section update in that case to allow the menu to process
the ::activate signal first.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1948>
For now the menu is only used in the top bar, where we can assume
that it exists "forever". This won't be the case when we start
reusing it elsewhere, so make sure we clean up after ourselves.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1948>
There is a big overlap between the app menu in the top bar and the
context menu of app icons. It makes sense to unify the two both
from a design- and from a code perspective, so split out the more
modern one into a separate module as basis for a shared class.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1948>
There was a potential issue when suspend was inhibited and immediately
uninhibited again before the creation of the inhibitor has finished.
Then the new inhibitor would be kept active.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1927>
ScreenShield::_syncInhibitor() was closing (and recreating) the
inhibitor everytime it was called, even if no change was needed.
This gets called in various places, including on property changes in
the login1 dbus object. These happen by the time logind already started
suspending at which point new inhibitors can no longer be created. It is
only waiting for existing inhibitors to be closed, so closing the
inhibitor without a new inhibitor will cause the suspending to proceed
immediately if no other inhibitors are present. This can also happen
before the lock screen is shown, which will then complete after resume.
Fix this by keeping track of the expected inhibition state and only
create or close inhibitors if there was a change to that.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3736
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1927>
We have initTranslations() for binding an extension's
gettext domain, but nothing to help with using gettext
from an extension.
Such help would be useful though, as an extension that
calls textdomain() like a normal application would
inadvertently changes the default domain for the whole
gnome-shell process.
Instead, extensions have to use domain-specific versions
of the gettext functions:
```js
const Gettext = imports.gettext.domain('my-extension');
const _ = Gettext.gettext;
```
Make this a bit easier by adding those functions directly
to the extensions object when initTranslations() is called,
then expose helper functions for calling them.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2594
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1941>
Regex are a crude tool for analyzing whether some code *calls* a
particular function. Spidermonkey has Reflect.parse() that returns
the AST of the passed in code, which allows for a much more precise
check for javascript.
The old script is still used for C code, where i18n-affecting changes
are much rarer.
Based heavily on Philip Chimento's mozjs migration script at
https://gitlab.gnome.org/ptomato/moz60tool.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1941>
The value can not actually be null at that point, but it's too
hard to spot for tools like coverity:
- before setting view, we chain up to the parent's acceptDrop()
- that calls _canAccept(), which we override and check for the view
Still, and extra ? doesn't hurt, and hopefully will make the tooling
happy.
CID 351269
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1950>
There is now a location portal that provides a similar role
as our agent. Settings supports that portal in its application
panel, which allows users to revisit their choice later.
Unfortunately it uses a different permission store table, so
any permissions granted (or denied) through our agent won't
show up there.
To change that, switch to the same table as the portal/Settings.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1945>
On startup desktop-icons-ng Wayland windows have skip-taskbar==FALSE so
initially pass `_isOverviewWindow` and they get added to the overview,
which is confusing to users. However almost immediately after that they
get `meta_wayland_client_hide_from_window_list` and are removed from
future overviews. So now we respond to `notify::skip-taskbar` immediately
and prevent desktop-icons-ng appearing in the startup overview too.
This is messy and ideally we'd like to know the window type immediately
on creation, but that option only exists in X11 and not Wayland.
https://gitlab.com/rastersoft/desktop-icons-ng/-/issues/137https://bugs.launchpad.net/bugs/1936643
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1925>
At least the last stable release of gjs has an issue with async
handlers for custom (i.e. defined in JS) GObject signals.
The handler still works, but evoking it prints the following warning:
JS ERROR: Error: Could not guess unspecified GValue type
We can avoid the warning by using the addAction() convenience
method, which makes for a small nice cleanup anyway.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4531
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1938>
If an actor is not on any stage view, then it doesn't have a valid
resource scale, which will hit an assert later.
When that is the case (for example when running headless), we expect
that there is no valid theme node (yet) either, so simply moving
the clutter_actor_get_resource_scale() call after peeking at the
theme node is enough to avoid the crash.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4522
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1935>
The PointerWatcher passes the current pointer position to every watch,
so we don't have to query the pointer again scrollToMousePos() is used
as watch callback.
While that should be the only use, be conservative and still query the
pointer when called without arguments.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1932>
Right now the Show Password menu is shown unconditionally for password
entries, ignoring the org.gnome.desktop.lockdown disable-show-password
key.
StShellEntry now honors that key for its peek icon, and there's little
reason for the peek icon and the menu to ever be out of sync.
This commit forces the menu and the icon to always be in sync, and
so makes the menu lock down work automatically, too.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/687>
There's now a setting
org.gnome.desktop.lockdown disable-show-password
that ostensibly lets admins prevent from users from
showing their password in password dialogs.
gnome-shell currently ignores this key.
As a first step, this commit adds the setting to StSettings.
Future commits will use the new setting.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/687>
Most of the keys are aligned, but "screen-magnifier-enabled" isn't.
This commit lines all the keys up, giving a little more breathing
room for future keys that have longer names.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/687>
Since we correctly call the `style_changed` vfunc superclass at the end
of our own function anyway, the style changes will get propagated to the
children of the scrollView inside `st_widget_real_style_changed` anyway.
So remove those unneeded and quite expensive (because they cause the
theme node to be regenerated) calls to `st_widget_style_changed`.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/953>
Properly compare the new icon properties of StIcon to the old ones on
style-changes and only update the icon texture in case something
changed. This should help reduce the amount of texture cache requests
when we start emitting all "style-changed" signals again.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/953>
This makes it easier to track size changes when the paint scale changes,
since in those cases we basically want to do the same thing as when the
normal icon size changes: Request a new texture from the cache.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/953>
The behavior when switching workspaces now with the touchpad gesture is
very very weird, it almost always swipes to the last workspace instead
of the next one.
So revert this change again and only swipe a single page per gesture. We
can enable long swipes again when we've figured out a proper way to
detect what the user wants (which is going to be quite challenging), see
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4355.
This reverts commit dfae3281b9.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1933>
ClutterVirtualInputDevice::notify_keyval() expects time to be in
microseconds but Clutter::get_current_event_time() returns the time in
milliseconds. On Wayland the generated event triggers all the warnings
in MetaDisplay::sanity_check_timestamps() due to the event time
seemingly being in the past.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1926>
Dragging a window preview in the overview is supposed to change the
opacity of the dragged actor. This however fails for minimized windows,
because Workspace::allocate() also changes the opacity of those. The
allocation gets triggered by removing the window actor from the
workspace when starting the drag. Avoid this by only changing the
opacity during the overview transitions.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4292
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1847>
At the moment user switching functionality is controlled by two
settings:
org.gnome.desktop.lockdown disable-user-switching
for the panel when the session is unlocked, and
org.gnome.desktop.screensaver user-switch-enabled
for the unlock dialog when the session is locked.
Having the lockdown setting not apply when the screen is
locked is counterintuitive.
This commit makes the unlock dialog honor both settings.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1833>
Since this is a bin and not a button, and it doesn't have any click/keyboard
handling on its own (as in that case it needs a parent button wired like in
the messages list controls), it is confusing that it has can_focus set to
True. To avoid any confusion, this commit removes it without breaking anything
since it had no real use.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1920>
This one was moved to Meta.Context as well.
I don't know why the `debugexit` command quit with an error code
(it dates back all the way to commit 98bd590a5d). Terminating on
request by the user doesn't sound like an error, so don't replicate
that particular behavior.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1917>
We'll likely have to interact a bit with the newly added Meta.Context
object, so add a convenience property that gives us direct access
instead of getting it from the display every time we need it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1917>
Before this, creating a separate instance of `Location.Indicator` failed
because it tries to create export the same DBus path.
This is useful for extensions adding panels on multiple monitors. But
it also seems like a cleaner design to separate the indicator widget
from the logically separate role as a Geoclue agent.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1919>
We build controls layout using the whole monitor vertical space as
available, however extensions or external apps in X11 may reduce the
workarea size horizontally and the shell should always take care of it.
Given that we're already assuming that the allocation is monitor-based
and that we're adjusting it to the workarea, we can just make it more
explicit by using a workarea box that is used as the allocation area.
As per this, we also apply the same logic of applied to the vertical
dimension to the horizontal one.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1892>
To compute the available height for the layout we're currently using the
panel position, while this works for the current and default setup, the
shell may be configured to use a different workarea, so we should rely on
it to compute the available space, instead of a specific widget.
So get the current monitor index for the current view and use its coordinates
instead.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1892>
The background group is currently allocated taking care of the workarea
x, y offset but not of its width/height and this may lead to building a
wrongly sized workspace view when the workarea size is not matching the
monitor size (like when there are struts set).
So, take care of the difference between the workarea and monitor
absolute end coordinates to allocate the background scaled content box.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1892>
We currently disable all network items on both the lock- and login
screen. While it makes sense to be very restrictive on the lock screen,
there are some (fringe) use cases for being more permissive on the
login screen (like remote home directories only accessible via VPN).
There's precedence with the power-off/restart actions to be less
restrictive on the login screen, and since we started respecting
the `network-control` polkit action, it's possible to restore the
old behavior if desired.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1874>
NetworkManager installs a `network-control` polkit action that can
be used to disallow network configuration, except that we happily
ignore it. Add it to the conditions that turn a network section
insensitive.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1874>
Setting up a connection for an Enterprise WPA(2) encrypted wireless
network requires Settings. That's not available when windows are
disabled via the session mode, so filter out affected entries.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1874>
The item launches the corresponding Settings panel when activated, which
doesn't work when windows are disabled by the session mode. Rather than
failing silently, turn the item insensitive.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1874>
This job does:
1. Download the coverity bundle and untar it in a cached location
2. Build GNOME Shell using clang and the coverity tool
3. Compress the coverity report
4. Upload for analysis
In a similar setup to that of Mutter.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1913>
It was on one hand using multi-line piping (`|`) and trying to
compensate with \ to escape multiple lines, this lead to:
No match for argument: \
Also, the quoting around pkgconfig() arguments would lead to
double quoting at the shell level, thus:
No match for argument: 'pkgconfig(gio-2.0)'
Fix both by using multi-line-turns-single-line piping (`>`)
and dropping the unnecessary quotes.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1913>
Unaccelerated deltas make sure the gesture works the same regardless of how
fast the fingers move; this is what we were already doing for scrolling.
Remove the swipe multiplier as the deltas already match scrolling other than
the 1/10 multiplier Clutter applies to scrolling specifically.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1763>
Since commit 3fb02843, we no longer skip allocation for
results that don't fit the width, and give them a 0x0
allocation instead.
That has the unintended side effect of those children now
being available to keynav. There are cases where we want
0-sized actors to be part of the focus chain (e.g. FocusTrap),
but this isn't one of them, so explicitly exclude 0-sized
children from keynav.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4470
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1916>
This ports over gnome-shell and the theme test case to MetaContext,
instead of the various functions that were available before.
The test case is changed to use the special test context, used to
construct contexts for testing. It's part of a shared libary separate
from the main libmutter one.
This enables building mutter tests during CI, as the test framework is
needed by some of gnome-shell's tests.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1840>
Destroying the source from an action callback will result in the
notification being destroyed twice:
- source.destroy() destroys all its notifications
- a notification destroys itself after an action
was activated
This results in unwanted log spam when attempting to dispose the
notification for a second time.
There is actually no good reason for destroying the source explicitly,
as sources already self-destruct with their last notification.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4457
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1908>
Currently we only mark the banner as removed if it is destroyed
while in SHOWN or SHOWING state, but not if we're already HIDING
(for example in response to `NotificationBanner::done-displaying`).
If this happens, we'll try to destroy the notification again at
the end of the transition, which leads to (harmless but annoying)
log spam since Notifications were turned into GObjects (that are
disposed when destroyed).
Address this by always marking destroyed banners as removed, while
still only triggering a state update while shown (or in the process
of being shown).
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4457
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1908>
This bumps both the mutter image to the F34 one, as well as the one used
for review.
This also bumps ci-templates hashes, so that we can use
FDO_DISTRIBUTION_PACKAGES without installing weak dependencies.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1906>
`mallinfo` has been deprecated in favor of `mallinfo2`:
```
The fields of the mallinfo structure that is returned by the
older mallinfo() function are typed as int. However, because
some internal bookkeeping values may be of type long, the
reported values may wrap around zero and thus be inaccurate.
```
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1786>
It's not visible because it's covered by the actual wallpaper, so
not rendering it eliminates most of the render time for
`workspace-background`, without changing its appearance.
When animating the overview by tapping Super, this reduces the
shell's overall render time by about 15%.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1904>
Until now, the absence of a `background-color` would cause `box-shadow`s
to be invisible. That was a bug because `box-shadow` is meant to be either
the color specified in `box-shadow`, or if none was specified then the
foreground `color`.
There is nothing in the spec that says the `box-shadow` rendering should
depend on `background-color`, so separate them. This ensures `box-shadow`
is rendered even when `background-color` is absent or transparent.
https://www.w3.org/TR/css-backgrounds-3/#box-shadow
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1904>
From [the spec](https://www.w3.org/TR/css-backgrounds-3/#shadow-blur):
> the resulting shadow must approximate (with each pixel being within 5%
> of its expected value) the image that would be generated by applying to
> the shadow a Gaussian blur with a standard deviation [sigma] equal to
> half the blur radius
This does not change the value of `sigma`, it only corrects the value of
`sampling_radius` used to size the shadow texture. Since the texture is
no longer being slightly oversized it won't get scaled down when rendered
according to the dimensions provided by `st_shadow_get_box` in
`_st_paint_shadow_with_opacity`.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4409
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1897>
Having an inaccurate paint volume didn't matter until ae338af1e8, but
after that having too small a paint volume resulted in apparent clipping.
Not because `clip_to_allocation` is set, but because the offscreen
framebuffer is sized to fit the paint volume only.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1897>
These do some some signals connection and monitor layout tracking
that we forget to disconnect when the magnifier is disconnected.
This causes warnings if enabling the magnifier, disabling it,
switching to another tty, and back. (Presumably also happens for
monitor hotplugs).
This signal should just stay connected as long as it's needed,
so add a setEnabled() method on the CrossHairs actor that we
can hook on the magnifier.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1902>
Some popovers like the ibus candidate popover may be requested while
showing an unredirected fullscreen window. Disable unredirection
while the popover is visible so that it can actually be shown.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1900>
When implementing a D-Bus method synchronously, regular JS methods are
used. That is, whatever the method returns is passed as return value
to the method invocation.
However for asynchronous implementations, we need to explicitly return
a value to the invocation, otherwise the caller will wait until it times
out eventually.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1891>
The appDisplay used to be accessible via the viewSelector, but
that is gone now. Commit c09c070b15 adjusted the code, but the
replacement uses a Main.overview.appDisplay accessor that never
existed, whoops.
Fix this by exposing a new selectApp() method directly on the
overview, so we don't have to shuffle the appDisplay through
controls → overviewActor → overview.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1891>
The migration happened in GNOME 3.6 over 9 years ago. The chances
that someone migrates from 3.0.x or 3.2.x to 41 are very much zero.
And if it were to happen, it wouldn't work anyway, because we stopped
using a separate overrides schema.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1890>
With Xwayland started on demand, mutter/gnome-shell will spawn Xwayland
and GNOME settings daemon Xsettings.
Currently, gnome-shell uses a timeout of 5 seconds before canceling the
launch and declare failure to start X11 services.
While 5 seconds may seem like a lot of time, when this is executed on a
virtual machine part of a QA tests under load, this causes random
failures.
There is no good value here, we could increase the timeout but it will
always remain racy. Instead, remove the timeout, systemd itself already
has a timeout mechanism (with a much longer wait time).
Thanks to Benjamin Berg <bberg@redhat.com> for finding the root cause
and suggesting the fix.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1888>
When a GTK app is started, we create a corresponding GtkApplication
proxy to monitor the app's busy state. If the app is stopped before
the proxy request finishes, we cancel the cancellable before clearing
the running state.
Usually we clear the cancellable once it is no longer needed, namely
when we got the proxy. However when the request was cancelled, the
cancellable has already been cleared, and if there's a cancellable,
it belongs to another request (because the window was added again,
for example when moving between monitors).
Leave that cancellable alone in that case, so we can cancel the
second request as well if necessary to avoid a crash when trying
to set the proxy on a cleared running state.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/1962
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1885>
Right now we pop the modal immediately when closing, so the key-release
event of the Escape key ends up in the focus window which may consume it
for leaving fullscreen mode or similar.
We can avoid that in many cases by keeping the modal grab until the end
of the transition, as the key-release event will then likely occur while
the grab is still in place (provided animations are enabled).
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1880>
If parsing the pipeline fails for some reason, we currently end up
with a zombie session that leads to a stuck recording indicator in
gnome-shell.
Instead, properly tear down the session to allow mutter and gnome-shell
to correctly update their state.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1878>
org.freedesktop.impl.portal.desktop.gnome will be used for the
GNOME implementation of desktop portals in the future, so make
sure GNOME Shell's implementation of the access portal won't
conflict.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1872>
Not when the main actor dimensions change. So now the shadows don't get
constantly regenerated during the overview animation. In my case this
reduces the render time of the overview animation (tapping Super) by
approximately 10% with 2 windows, or 20% with 10 windows.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1869>
Another trivial cleanup. This is in preparation for next commit, that
will expand on this if clause, and will make it a bit more complicated.
Using a variable here makes it easier to read.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1866>
Often, when using multiple monitors, the thumbnails box may be
destroyed before the 'hidden' signal of the Overview is emitted,
which leaves a bunch of lingering signal connections to the
workspace manager.
Call this._destroyThumbnails() in the _onDestroy handler, which
disconnects from workspace manager. This fixes the some of the log
spam that GNOME Shell produces with backtraces of destroyed actors.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1860>
app_notify_events_added uses an intermediate builder to construct an
array that is then added to the main variant using g_variant_builder_add
which should clear the intermediate, but doesn't due to the way it is
passed: by value, rather than as a pointer.
This was debugged with the help of Eduardo Habkost, who believes it
works on x86 due to big structs being passed as pointers.
Fixed: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3440
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1848>
On systems/setups not using systemd, a failure to start gsd-xsettings
with NOT_SUPPORTED does not denote a failure to start Xwayland, just
that we're not using systemd.
In that case, we should just ignore the error, otherwise it will prevent
Xwayland to start on such systems/setups without systemd.
Thanks to Rose Kunkel (@rosekunkel) for spotting the issue/suggesting
the fix.
Fixes: 019229c40e - windowManager: Return failure to start X11 services
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4284
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1850>
Currently, handling of touch devices in the app grid is a bit awkward,
paging by dragging the view can only happen if started from the gaps
between icons, trying to drag from an icon will trigger DnD, and popping
up the menu takes over it all.
Instead, have the app grid actions play this game of rock-paper-scissors:
- Fast swipes on icons trigger scrolling, beats DnD and menu
- Slower press-and-drag on icons trigger DnD, beats scrolling and menu
- Long press triggers menu, beats scrolling, is beaten by DnD
This allows quick swipes to handle navigation, while still allowing the
fine grained operations. DnD, when triggered, dismisses the menu, if
shown.
This all could probably be nicer with a more stateful gesture framework,
we're not there yet though.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3849
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1774>
This setting (by default, 0) sets a time threshold in order to allow
DnD. If the drag is shorter than this threshold, DnD will be cancelled,
and event handling left to the next handlers.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1774>
We do notify on the ::pressed property after touch begin/end and
recording the event sequence, but we do not return the correct value
if the button was triggered via touch.
Consider the event sequence also in the ::pressed getter, so the
button is considered pressed.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1774>
The switcherPopups use _next() and _previous() to get the items
in the text direction. I. e. with LTR _next() gets the right item;
on RTL it gets the left item. This doesn't work well with RTL when using
the arrow keys since the text direction doesn't matter in those cases.
Pressing Left Arrow should still move left regardless of text direction.
So use the opposite methods.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2547
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1835>
If for some reason the xserver failed to start, mutter/gnome-shell
should not attempt to connect to the X11 display otherwise it will
lock up in XCB.
An indication of such a premature failure of the xserver is when the X11
services fail to start.
Return the status so that the caller can cancel the connection in time
and avoid the lockup of mutter/gnome-shell in case of failure.
This, however, makes the X11 services a critical component to start
Xwayland, meaning that a failure to start those services for any other
reason than the xserver failing to start would still prevent Xwayland
and therefore X11 clients to run in Wayland. This is however a lesser
issue than mutter/gnome-shell locking up.
This basically reverts commit a96753f0 - "windowManager: X11 can work
without gsd-xsettings".
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1837>
Since commit f60a469a34, everything outside the fade area is painted
fully transparent. That is required for the fade effect during app
grid navigation, to prevent unfaded parts of surrounding pages
becoming visible on wide-screen displays.
However in most other cases, that behavior is the exact opposite
of what we want: Elements outside the fade area (like scroll bars)
should never fade.
In order to fix the regular case, hide the new behavior behind a
property.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4234
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1831>
Change behavior on pressing Super+Number in Activities/Overview mode
so that the overview mode is hidden and application can be used.
This makes it consistent with clicking icon in the dash.
Closes: #4212
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1839>
Previously the workarea was only set on construction and then never
updated. As a result the preferred width and height as well as the
allocation were based on an outdated workarea size when it changed after
construction. This for example was happening during the startup
animation, for which the WorkspaceLayout is constructed before the panel
is shown. This caused the workspace in the overview to be slightly
smaller when it is first shown and the overview closing animation to
not expand the workspace to the correct size the first time it is
closed.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3945
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3816
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1771>
In the nested session the startup animation sometimes fails, weirdly
that always happens to me when running a freshly built gnome-shell the
first time. The reason it fails is that mutter fails to aquire a pointer
grab from the xserver, XIGrabDevice() is unsuccessful.
A simple workaround for this race condition in the xserver is to just
grab the devices a bit later, that is after the startups animation
instead of before it.
This was also tested with disabled animations, and seems to work just as
well in that case.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1812>
Some drag actor parents might change their width to 0 after the drag
actor has been removed. If the drag is now canceled and the drag actor
is animated to return to the current parent position and scale, this
scale can not be determined and falls back to 1.0. This might be wrong
and can result in the drag actor being too large/small at the end of the
return animation.
To avoid this calculate the scale of the parent by recursively
calculating the product of its parents individual scales.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4017
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1790>
Now that we made window previews overlap the edges of the wallpaper
underneath them, the app icons of those windows are getting quite close
to the dash and there is almost no more spacing.
Let's make it look a little bit better and slightly increase the
margin-top of the dash so that the workspaces move a few more pixels
away from the dash.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1813>
We want to clip the Workspace actor in the appGrid state of the overview
in order to make sure windows that overflow the monitor don't spill out.
So far we had commit b1970b95b8 for that.
Now since the last commit, window previews always slightly overflow the
allocation with their icons. That means a part of the window icon gets
clipped away as soon as the transition to the appGrid starts, which
looks weird.
Fix that bug in the transition by slightly extending the clip downwards
when animating between the window picker and the app grid state. The
extra height we extend the clip by is controlled by the overviewState,
which means we extend the clip by the full icon overlap in the window
picker state, but don't extend the clip at all when in the app grid
state.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1813>
We want to use as much space as possible for showing window previews in
the overview, and the title and close buttons of those windows are only
visible on hover, so we can show them above anything if we want.
On both primary monitors and secondary monitors, there's a certain free
space available towards the bottom edge of the monitor (on the primary
monitor we show the dash there, and secondary monitors just scale down
the Workspaces). We can make use of this by checking how much free space
there is available from the bottom edge of our allocation to the bottom
edge of the monitor, and then aligning the window previews to make full
use of this space.
So stop adding any padding to the edges of the Workspace, which will
make the windows a lot larger and completely fill the Workspaces
allocation.
The left, top and right monitor edges should always be far enough away
to accomodate the close button and hover scale-up of the window. Only
with the bottom edge of the monitor we have to be a bit more careful
(the overflowing height of the window title is quite big), so there we
check if enough free space is available. If there isn't enough free
space, we simply apply a bit of bottom padding again and shift the
window up.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1813>
Make the SecondaryMonitorDisplay a bit more similar to the
ControlsManager container on the primary monitor, and clip that widget
instead of the WorkspacesViews on secondary monitors.
This will allow us to overpaint the WorkspacesView allocation and paint
the WindowPreview overlays like the title and close button outside the
allocation with the next commit.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1813>
The current gstreamer pipeline performs quite bad on slower machines and
is dropping lots of frames, improve the pipeline by changing a few
things:
- Use threads for videoconvert and improve speed of videoconvert by
disabling some unneeded things
- Add a queue before the encoding step, this allows the encoder to work
at its own pace and will lead to a lot more stability
- Remove the fixed quantizer and only set a max quantizer, this helps
quite a bit with performance
- Change the deadline parameter of vp8enc to 1: This makes the encoder
go into real time mode, which will make it a lot faster
- Set cpu-used to 16, the maximum possible value.
- Set static-threshold to 1000, static-threshold is the motion detection
threshold, and while a value of 100 is recommended for screencasting in
the gstreamer documentation (see [1]), using 1000 appears to perform a
lot better and still outputs fairly good quality
- Set a larger buffer size than the default size, this seems to get a
bit more stability during high load scenarios
All in all, those changes make the pipeline drop no more frames when
recording at 30 FPS and 2K screen resolution. That was tested on a
fairly recent mobile core-i5 processor.
Also, because we now have two %T replacement strings for the number of
threads, we need to switch to replaceAll(). For that to work, we have to
put the %T matching expression into quotes.
[1] https://gstreamer.freedesktop.org/documentation/vpx/GstVPXEnc.html?gi-language=c#GstVPXEnc:static-threshold
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1633>
On the new horizontal workspace-thumbnails, the old placeholder from
vertical dash appeared too small, and was easily hidden behind the
dragged window/icon. Rotate the placeholder 90 degrees to better fill
the spacing between thumbnails.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1801>
The original parent of a dragged actor might have been destroyed after
the drag has been started. When the drag is canceled and _dragOrigParent
is set, the code is trying to get the current position and size of it
when restoring. With a destroyed parent this however would result in a
crash.
This could happen for example when starting a drag on a window preview
while the overview is hiding and then releasing it once the transition
is done.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4024
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1817>
`ThumbnailsBox` listens for the `showing` signal from the `Overview` to
create its thumbnails and destroys them on the `hide` signal. Since the
`showing` signal can be emitted multiple times when switching between
the shown and hidden state without ever fully completing the transition,
this will cause `_createThumbnails` to be called multiple times, each
time adding another set of workspaces.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3819
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1828>
When starting a gesture to open the overview while a transition to hide
the overview is running, Overview._shown will be first set to false when
starting the transition and then to true by the gesture before the
`onComplete` callback is called. The `onComplete` callback in this case
is `Overview._hideDone()` which starts a transition to show the overview
again which also emits the `showing` signal. Since the gesture emits a
`showing` signal as well, this results in two consecutive `showing`
signals without a `hiding` signal in between.
This breaks the `searchControler` which adds a key press handler to
start the search on `showing` and removes it on `hiding`. So every time
this happens a new handler that will never be removed is added,
resulting in the first key press being repeated.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4004
Related: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3819
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1828>
For the screensaver service, it is quite normal that a consumer only
subscribes to the "ActiveChanged" signal without calling any methods.
The result is that we don't know about the consumer, and shut down
the service anyway after we hit the timeout.
If this happens, we break functionality like gnome-settings-daemon's
screen blanking on idle.
Fix this by simply disabling auto-shutdown for the service, which
also reflects the expectation that the screen saver service is
always running in a GNOME session.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4114
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1824>
It can happen that we get a problem report and a verification failure at
the same time. For fingerprint, a problem report can result in an
internal verification failure to be queued.
Remove this queued failure again if we got a failure already from GDM
directly.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1821>
At the moment a failure in a background service can lead to the
various verification signals getting disconnected, even though
we still need them for a foreground service.
This commit changes the code to only disconnect when we've run
out of tries.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1821>
At the moment we set the state of the auth prompt to failed any
time the user fails an attempt. But verification is still going
on until the user exhausts all attempts, so that's wrong.
This commit changes it to only set the state to failed when the
user is out of tries.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1821>
At the moment we treat a failure in any service as a signal to stop
tracking users responses to service questions.
This commit makes sure we don't stop waiting for answers if a background
service fails.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1821>
When we press a key with variants, we used to prevent an
early ::pressed, because a long press could show the options
popover, and the press be undone.
In addition, this long press could move to one of the suboptions,
and be released there. For this case we also want this late
emission of the ::pressed signal.
This makes the "tap, drag, release" pattern work on the
regular OSK keys, in addition to the emoji panel.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1789>
This is already allowed for pointer events, but touch events still expected
that the touch begin and end happen on the same Key actor. Change this
behavior for touch events, this is necessary for the tap-drag-release
pattern to select key variants to work on all input devices.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1789>
With commits fab39bbea5 and
62e40a1350 we started depending on a new
ClutterActor API: clutter_actor_invalidate_paint_volume()
Given that this commit was applied to the 40 stable release, it broke
ABI compatibility with mutter, which is something we guarantee between
stable releases. So use GModule to dynamically find the symbol in our
loaded libraries. If it exists, use it and invalidate the paint volume.
If it doesn't exist, libmutter is still at version 40.0 and we don't
need to invalidate the paint volume.
This also adds a dependency on gmodule. We need to link against gmodule
to use g_module_open() and g_module_symbol() APIs.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1807>
At the moment the timed login feature is implemented in the user list.
If there's no user list, we don't show the indicator anywhere and
don't proceed with timed login.
This commit allows timed login to work when the user list is disabled.
It accomplishes this by putting the timed login indicator on the
auth prompt in that scenario.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1809>
When super is pressed again during the overview transition, we shift
up to the app grid. That means that the feature currently doesn't
work when animations are disabled (like in a VM), because there is
no transition in that case.
Address this by adding a time-based fallback in that case, i.e.
shift up when a second super-press occurs within 250ms after the
first one.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4121
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1811>
Using the callback directly as signal handler means that it will
receive the signal parameters (in this case: the StButton instance
that emits the signal).
This leaks an implementation detail that is harmless in the best
case, but can break dialogs when using bind() on the callback.
Avoid that trap by explicitly calling the callback without arguments.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4139
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1819>
For the primary monitor workspace thumbnail, we must keep the monitor
index in sync with what is currently the primary monitor index,
otherwise we might end up trying to move windows to non-existing
monitors.
For example, if the primary monitor index was 1 when the thumbnail box
was created, but later, the primary monitor index changed to 0, with the
other monitor being turned off, moving a window to one of the workspaces
on the workspace thumbnail, gnome-shell would attempt to move it to the
monitor with the index the primary monitor had in the past, with the
problem being that that monitor no longer exists.
Fix this by listening on the 'monitors-changed' signal on the layout
manager, and update the monitor index of the primary workspace
thumbnails box. Make sure to connect to the signal before creating the
thumbnails box, as the thumbnails box itself will listen to the signal
and recreate its actual thumbnails, and it must do this with the up to
date monitor index.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4075
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1810>
StWidget is overriding ClutterActors get_paint_volume() vfunc to adjust
for overpaint of things like box shadows that get set in CSS, it does
that by setting the paint volume to the theme nodes paint box.
Since StWidget can't really get notified when the paint box changes, we
just invalidate the paint volume when the theme nodes paint_equal()
returns FALSE.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1484>
Since StViewport uses the value of the StAdjustment to create its custom
paint volume, ClutterActors newly introduced proper caching of paint
volumes doesn't get notifed about changes to that paint volume and will
simply reuse the cached old one.
So make use of the newly introduced
clutter_actor_invalidate_paint_volume() method to make sure ClutterActor
will ask for the paint volume again on the next paint.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1484>
When OverviewControls goes from HIDDEN to APP_GRID, it constantly checks
if AppDisplay needs to be visible or not by checking the current overview
state is bigger than WINDOW_PICKER. Turns out in this case this check is
problematic, because when the current state trespasses WINDOW_PICKER, the
layout manager will have already positioned AppDisplay halfway to its final
position.
Use either the final or the current state, whichever is biggest, when updating
the AppDisplay visibility. It optionally allows passing the overview state
params to _updateAppDisplayVisibility() so that we avoid a few trampolines to
recaltulate the adjustment state.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1805>
Both app grid and window picker are now always visible in the overview,
so their handling of the PgUp/PgDown keys conflicts.
Resolve that by checking for the overview state instead.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1798>
Window previews looks slightly offset to the left and top right now
because we don't use the same padding on all edges of the Workspace. We
do that because the oversize and overlap of the window previews is
different on all sides (for example the bottom overlap is very large
because there we show the window title).
To make sure window previews are always perfectly centered on the
Workspace, only use the largest one of the oversize values as spacing
and padding, and add the larger one of the overlap values for the
vertical padding in addition.
With this, we now center the window previews on the Workspace while
never overpainting the allocation of that Workspace to show overlays.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3634
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1670>
This was forgotten when porting to GTK 4, leading to the following error
when user tries to copy the error message produced by an extension:
JS ERROR: TypeError: Gtk.Clipboard is undefined
_initActions/<@resource:///org/gnome/Shell/Extensions/js/extensionsService.js:255:31
run@resource:///org/gnome/Shell/Extensions/js/dbusService.js:177:20
main@resource:///org/gnome/Shell/Extensions/js/main.js:19:13
run@resource:///org/gnome/gjs/modules/script/package.js:206:19
start@resource:///org/gnome/gjs/modules/script/package.js:190:8
@/nix/store/fwnkwvhwm3kqck4fhkc5y5z853radggg-gnome-shell-40.0/share/gnome-shell/.org.gnome.Shell.Extensions-wrapped:7:17
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1795>
We only want to show the welcome dialog in the user session, not
on the login screen or during initial setup. We currently achieve
that by explicitly checking for those mode names, but there are
other modes like gnome-classic where the dialog is equally un-
helpful. Support those cases by adding a session mode property
that determines whether the welcome dialog should be enabled,
so that modes can opt in or out of the feature themselves.
(Both the 'gdm' and 'initial-setup' modes are based on the
'restricted' mode, so this change does not affect them)
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4026
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1793>
Usage of GET requests for checking updates was made deprecated
at website some time ago [1], but REST endpoint was
CSRF-protected until recently [2].
The body of update request may be big enough and thus does not
suitable for GET requests.
[1] 0b38da1b2b
[2] e3ab0c07dc
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1781>
As documented in g_once_init_enter(): "While @location has a volatile qualifier,
this is a historical artifact and the pointer passed to it should not be
volatile.". And effectively this now warns with modern glibc.
Drop this from our logging function.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1770>
As documented in g_once_init_enter(): "While @location has a volatile qualifier,
this is a historical artifact and the pointer passed to it should not be
volatile.". And effectively this now warns with modern glibc.
Drop this from our logging function.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1770>
`key` is an empty string in this case, causing `charCodeAt(0)` to return
`NaN`, which when passed to `Clutter.unicode_to_keysym` now generates an
error in gjs >= 1.67.3:
```
JS ERROR: Error: Argument wc: value is out of range for uint32
```
And the symbolic keys like Backspace, Enter and Caps Lock would have their
presses ignored.
Just skip the call to `charCodeAt` that will fail and allow
`Clutter.unicode_to_keysym` to return its usual error flag.
Fixes: https://bugs.launchpad.net/bugs/1918738
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1758>
The parameter to `ModalDialog.close(timestamp)` is optional. But when
invoked via the network dialog's Cancel button it was receiving an
implicit parameter value that's definitely not a timestamp:
```
[0x560f18af0c50 StButton.modal-dialog-linked-button:first-child hover ("Cancel")]
```
And as of today (or gjs >= 1.67.3) that's reported as an error:
```
JS ERROR: Error: Argument timestamp: value is out of range for uint32
popModal@resource:///org/gnome/shell/ui/main.js:638:12
popModal@resource:///org/gnome/shell/ui/modalDialog.js:206:14
close@resource:///org/gnome/shell/ui/modalDialog.js:179:14
```
and so you can't Cancel the dialog anymore.
Make sure `ModalDialog.close()` receives an `undefined` timestamp it
knows how to handle.
Fixes: https://bugs.launchpad.net/bugs/1918666
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1757>
Since commit 770231, StImageContent implements the GIcon interface, which
allowed us to represent all application icons as GIcon (app-info, X11 icon
property or themed fallback icon).
While that change made for a nicer ShellApp API, it did introduce a
conceptual issue in st_texture_cache_bind_cairo_surface_property():
GIcons usually represent static icons, while the ClutterContent
returned by that method updates automatically when the bound property
changes.
Address this by tracking the MetaWindow:icon property in ShellApp, and
update the fallback icon when it changes. With that, a GIcon object
always represents the same icon, and any icon change is reflected
by a corresponding GIcon change.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1761>
We hold a reference to all windows we track for the app. While that
reference is unlikely to be the last remaining one, we still shouldn't
release it until we are done with the window.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1761>
Creating a content object from a cairo surface may fail, in which case
we return an empty content with a 0x0 preferred size.
However when we treat such a content object as GIcon, we happily load
it anyway. Don't do that, so consumers like StIcon can fall back properly
to an alternative.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1761>
While most GIcons passed to this function cause a StImageContent to be
created with the requested size, cairo surface based icons already are
passed as StImageContent with a preferred size corresponding to the
size of the surface they were created from. As a result icons of window
backed applications were never scaled up like the other icons. Fix this
by ignoring the content size for these case.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1751>
Right now we use a ClutterClone ghost of the panel simply to add some
spacing to the top monitor edge.
We can remove the panelGhost by adjusting the allocations of all the
parts of the overview ourselves inside ControlsManagers vfunc_allocate,
this should also work with extensions that move the panel somewhere
else.
This makes the initial relayout of the overview significantly faster,
because we now no longer have to relayout the whole panel in the
process.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1755>
The OverviewControls actor gets allocated a fixed size by its parent,
the OverviewActor, anyway, so it's pretty useless to go through the size
request machinery and add up all the sizes of items in the iconGrid,
coming up with a preferred size that's wrong anyway.
Instead simply return a min and preferred size of 0 in
get_preferred_height/width of ControlsManagerLayout.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1755>
Hiding actors allows excluding them from layout, so by hidding the
appDisplay in all the cases where the overviewAdjustment is not actually
showing it, we can save a lot of time on the first frame of painting
the overview because we no longer have to layout the whole appGrid.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1755>
We create a lot of BaseIcons for the appGrid, one for every app, and for
all of those we have to hop through JS to get the preferred width. That
makes it another obvious target for moving to C, so let's do that.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1755>
The logic that decides whether we should shift the window up when the
cursor rectangle overlaps with the keyboard rectangle doesn't work
properly right now, we want it to work like this:
- If the currently focused window is shifted up, keep it shifted up
until the cursor rect no longer overlaps the keyboard rect. To do that
comparison correctly, we need to adjust for the height the cursor rect
is shifted up by (keyboardHeight) and temporarily shift it down again.
- If the currently focused is not shifted up, we want to shift it up as
soon as the focus rect overlaps the keyboard rect. If that's not the
case, want still want to call _setFocusWindow(null) in order to shift
the previously focused window back down.
This fixes two issues: 1) We're currently shifting windows back down at
the wrong position of the cursor (that is y < keyboardHeight). 2) We're
not shifting down previously focused windows when focusing a different
window with the new focus in a specific region (y >= keyboardHeight &&
y + h < monitor.y + monitor.height - keyboardHeight).
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1760>
So far the FocusTracker of the OSK can only recognize grab ops on a
window, that is when the user grabs the window using a mouse or the
touchscreen and actively drags it somewhere.
Window can also be moved using keyboard shortcuts, fullscreen buttons or
other ways which don't rely on grabs. Start also supporting those window
movements by listening to the "position-changed" signal on the currently
focused window and emitting the new "window-moved" signal in that case.
Because the OSK sometimes moves windows by itself, we temporarily
disconnect from that new signal while we move the focused window in
_windowSlideAnimationComplete().
This also takes care of resetting this._focusWindowStartY on movements
of the window.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1760>
Commit 8526776b4a changed the OSK to use
the translation-y property of the MetaWindowActor when animating a focus
window, which broke two things:
1) It's not compatible with the obscured region culling we do for
windows in mutter. That's because MetaCullable strictly operates in
integer coordinates and thus has to ignore any transformations
(translation-y is a transformation). Because of this, during the
animation and gesture, window damage is now tracked incorrectly,
introducing painting issues. The best fix for this would probably be
factoring in transformations when tracking damage in MetaCullable, but
that's not feasible right now.
2) It broke the shifting up of maximized and tiled windows, likely that
is because they are positioned using constraints internally, and mutter
enforces those constraints every time meta_window_move_frame() is
called, not allowing the window to move somewhere else.
To fix both issues, go back to the old way of shifting the window for
now, using the fixed y position of the ClutterActor. To make sure the
drag-up gesture still works, store the initial y1 position of the window
and then use that as a reference point for all our animations.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1760>
I suggested it myself when reviewing
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1668, so
here I am reverting that again...
The difference between calling _setFocusWindow(null) and simply
unsetting the focusWindow is that the former animates the window back to
its position before we shifted it up, while the latter simply "lets go
of the window".
In this case we actually want the latter because after the user grabbed
the window, we obviously should not animate it away right underneath the
users pointer/finger.
To ensure the same mistake doesn't happen again, add a small comment
explaining why this code is as it is.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1760>
If the actor is unmapped in the handler, the touch gesture will cancel.
Since we haven't reset the state yet, it will still work and will actually
cancel the gesture, so reset before that instead.
Fixes overview cancelling when trying to open it with a swipe.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1731>
When this class was written, all swipes in the shell were vertical, so it
made sense to make the default orientation vertical. This isn't the case
anymore, thus pass make it mandatory to specify orientation when creating
a tracker.
Change the property default values to horizontal as well to match Clutter
instead of the old shell design.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1731>
The focus rectangle of the OSK currently gets stored with an offset that
removes the global coordinates and makes it window-local coordinates.
This offsetting has been applied since the introduction of the
FocusTracker with commit fc5ab44704 and it
seems there's no real reason for it.
By removing this, we also emit position-changed when the window has
moved but the window-local coordinates stayed the same. We really want
to emit position-changed in that case because it might affect whether
the window needs to be shifted up.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1728>
Apparently some clients, including gtk don't "clip" the focus rectangle
to their window bounds when scrolling the focus outside the window. This
makes us shift up windows when the focus actually is no longer visible.
This issue needs fixing in GTK, it should probably stop reporting
focus changes when the focus moves outside of the visible view. We can
still do a little bit better on our side though and "clip" the rectangle
to the windows frame rect: If it moves out of the window, we simply stop
updating our focus rect.
The intersection check introduces a small problem though: Some clients
(for example gedit) will give us a cursor rect that has a 0 width or
height. This won't play well with graphene_rect_intersect()
(GrapheneRects never intersect if they are 0-sized), so we set the size
to 1 in case we get a 0-sized rectangle.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1728>
The FocusTracker keeps track of the currently focused window using its
internal this._currentWindow property. It will only pick up the focused
window though when receiving a "notify::focus-window" signal, so the
focused window that's set when the FocusTracker is created won't be
picked up.
Fix that by setting the _currentWindow during creation of the
FocusTracker.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1728>
Now that we got rid of the external calls to setCursorLocation(), we can
make that private. animateShow() and animateHide() weren't called from
outside anyway, so let's make those private, too.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1728>
What this signal does is fire when a window was grabbed. A receiver
might want to do something special when a window was grabbed, whereas
"reset" can mean anything. Rename the "reset" signal to
"window-grabbed".
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1728>
Instead of interpolating our workspace and layout boxes for each child
using clutter_actor_box_interpolate(), use our Util.lerp() function and
stay in JS land instead.
This is quite a large performance improvement since it avoids
heap-allocating a new ClutterActorBox for every child. With this, we're
finally at a duration of 1.0 ms to allocate the Workspace with 20
windows.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1743>
Move the get_preferred_width/height() and allocate() vfunc
implementations of WindowPreview to C, subclassing the C GObject from
JS.
This gets us another significant performance gain, allocating a
workspace with 20 windows now only takes 1.2 ms.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1743>
It turned out that getting properties and saving them to a variable
outside of loops instead of accessing them everytime inside the loop can
have significant impact on performance, so do that in Workspaces
vfunc_allocate().
Here the impact is not that large, about 0.05 ms with 20 open windows,
that still seems worth it though.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1743>
These checks aren't needed since Clutter should enforce this for us
already and skip the implicit transition when possible. This gets our
time spent in vfunc_allocate() down to 2.0 ms with 20 windows
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1743>
Setting four properties is more expensive than calling two C functions,
so move to set_origin()/set_size() calls for our ClutterActorBox
handling.
This gets us down to an average time of 2.1 ms spent in vfunc_allocate()
with 20 windows
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1743>
We can save a little bit of time in this loop by iterating directly
over the windowSlots array instead of iterating through children and
then performing a search for the windowSlot. This saves more time and we
only spend 2.2 ms instead of 2.3 ms in vfunc_allocate() now.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1743>
This layout manager is used quite often and the time we spend calling
it's allocate and get_preferred_width/heigth functions increases with
every open window.
We can save a lot of precious time during the layout cycle by moving
this layout manager from JS to C, thus avoiding the overhead of
trampolining between C and JS land.
In a measurement where the average time spent in vfunc_allocate() of the
Workspace actor was measured while opening an overview with 20 windows,
the average time spent went down from 3.1 ms to 2.3 ms.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1743>
With the introduction of the transparent panel in the overview, we
started making the panel text/icon color slightly brighter in the
overview and on the lockscreen to ensure best contrast. Now
unfortunately, setting the text color incurred a relayout of the
underlying ClutterText actor (fixed with
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1750), and
setting the icon color causes the icon texture to get regenerated
(fixed with
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/932).
Regenerating the icon texture will replace the icon actor, which also
causes a relayout.
This relayout of the panel has been measured to add at least 1
millisecond (the numbers fluctuated a lot) to about 5 ms it takes to
layout the first frame when showing the overview.
Since https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/932 is
unlikely to land this cycle, this commit proposes a different solution:
Simply don't use a different color for text in the overview. To avoid
issues with contrast in the overview, make the default color slightly
brighter and change it from #ccc to #ddd.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1733>
Right now we always recreate the icon of the appMenu when calling
_sync(). This will relayout the panel everytime we open the overview,
because we call _sync() in that case.
We can easily avoid that by only recreating the icon actor in case the
app that's opened actually changes. This gets us close to doing no more
relayouts of the panel when opening the overview.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1733>
We already set the AppMenuButton to be non-reactive and transparent when
we hide it. Hiding it completely using clutter_actor_hide() will
additionally make it no longer affect layout and thus queue a relayout.
Since we hide the appMenu in the overview and we want to avoid
relayouting the panel when entering and leaving the overview, don't
completely hide the AppMenuButton to avoid queueing this relayout.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1733>
This updates the use of bind_cairo_surface_property for the changes
from d7cb2eeebc. Now this function returns a StImageContent and not
an Actor like the following code expects, so wrap it in a StIcon.
Also the function lost its size argument.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1718>
This is how the code works and how it is already used from the C side.
There would also be no point in keeping this transfer none, because
textures generated from this function will not be shared and are not
kept in the cache.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1718>
This reverts commit 87558efbf1.
The commit did not fix the bug it was supposed to fix, it just
complicated the code. The hopefully correct fix is in the previous
commit.
The point of this commit was to ensure everything gets removed when
bind->source gets removed. This however was already the case since the
signal handler was already connected to bind->source and has a
destructor registered that takes care of everything. And since gobject
destroys its signal handlers before it clears the weak refs, this new
weak ref was effectively never being used.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1718>
If the icon surface of a window got updated and its type or format no
longer match what we expect, st_texture_cache_reset_texture() might
overwrite the existing image in the bind with a new image, while still
keeping the weak ref on the old image. Due to this the old image might
trigger a st_texture_cache_on_pixbuf_notify() after the bind has already
been freed by g_signal_handlers_destroy() in the bind source. While this
usually would remove the weak ref, the weak ref it tries to remove is
on the new image, not the old one. The call to
st_texture_cache_on_pixbuf_notify() then tries to read the already
free'd memory from the bind which causes the cast to G_OBJECT to fail,
resulting in the crash.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3785
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1718>
Changing the workspace of a window causes the window tracker to remove
and add it to the app again. If this happens from within
_shell_app_add_window() before the window has been added to the windows
list, this will cause the check that is supposed to prevent adding the
same window multiple times to fail and the window to be added twice.
The app will then be considered still running after the last window has
been closed. Then when clicking on the corresponding app icon, the shell
would attempt to switch to a NULL workspace for the closed window
instead of starting a new instance, resulting in a crash.
Changing the workspace also needs to happen after increasing the
interesting window count, because otherwise removal of the window by
the window tracker would trigger a uint underflow leading the app to be
considered running with UINT_MAX interesting windows, despite having no
windows, leading to crashes right after launching the app.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3833
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1745>
If the window wasn't in _windowSlots, the index is -1, so the last
element of the array is removed, leading to
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3547
I logged the stack trace from removeWindow() and it seems that when you
move the window from the second monitor to another workspace like shown
in https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3547,
removeWindow() is called twice for it, presumably once for the second
monitor workspace, and then once for the first monitor workspace for
some reason. It is during that call that _windowSlots doesn't contain
the window, so instead the last element (index -1) is removed, leading
to the animation bug.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1727>
We block state updates while the indicator for the active workspace
is animating. To track that, we check whether the scroll-adjustment's
value matches the active workspace index. That works as long as the
adjustment's value changes after the active workspace, but not when
switching workspaces via SwipeTracker which only changes the active
workspace after transitioning to the new scroll value.
To fix that, update the indicator on workspace changes as well.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1716>
Animating items of the iconGrid involves calling a few more C functions,
which is quite slow. Especially calling ClutterActor.set_easing_delay()
is slow because we override that function in JS to adjust for the
animation slow-down factor. So add a small class variable to make sure
we only animate the icons of the grid when we actually need it.
This makes the average time spent in vfunc_allocate() of the iconGrid go
down to about 0.7 ms.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1713>
It's quite slow to access class variables in JS, especially when they're
backed by GObject properties. To avoid accessing them in every iteration
when we're looping through the children of iconGrid, store those values
to another variable and reuse that inside the loop.
This shaves off another 0.2 ms from iconGrids vfunc_allocate(), getting
the average time spent in that function down from 1.3 ms to 1.1 ms.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1713>
Using a preexisting array to iterate over is much faster than iterating
over the actors children using a "for ... of" loop, that's because the
latter calls into C functions to get the next actor all the time.
Also, stop using array deconstruction here, it turned out that this is
extremely expensive. When profiling this part of the code, it turned out
that only 9% of the time spent in _getChildrenMaxSize() is spent calling
the get_preferred_height/width() methods. When not using array
deconstruction, this time increased to 22%, still not great, but a lot
better.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1713>
We need to access the visible children of a page in inside
vfunc_allocate(), and since getting those children is quite slow (it
involves iterating over all the children of the actor) let's avoid that
and cache the array instead.
This reduces average time spent in vfunc_allocate() of the iconGrid from
1.6 ms down to 1.4 ms.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1713>
We call this._getChildrenMaxSize() from the allocate() vfunc of
IconGridLayout. Since the function is quite expensive, it slows the
layout process down a lot, so instead of re-calculating it on every
relayout, cache the max size of children.
This makes the average time spent in vfunc_allocate() of the iconGrid go
down from 2.3 ms to 1.6 ms.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1713>
Instead of always aligning window previews vertically at the bottom of
their row, only do that if we have multiple rows. If there's only a
single row of windows, align every window vertically centered.
This is a very small step towards the new layout for window previews in
the overview, but since the release of 40 is getting nearer and nearer,
changing more is not feasible anymore.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3634
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1737>
To ensure the workspace thumbnails are vertically closer to the window
picker than to the search, scale down the wallpapers by a fixed number
of pixels. Using 24 px for this means we'll take of 12 px at the top and
12 px at the bottom of the wallpaper, that's a better strategy than
always scaling it by a fixed factor since it doesn't change with the
monitor size.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1702>
Use a bit less margin at the top and add some margin at the bottom of
the search entry. This should ensure the search entry is closer to the
panel than to the workspaces and avoid associating the workspace
thumbnails with the search instead of the window picker.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1702>
The Dash currently has a horizontal margin and a top margin applied. The
horizontal margin isn't necessary since there already is a horizontal
padding applied, and the top margin is a bit large, since the
ControlsLayout enforces a spacing between the different containers
already, so slightly decrease the margin-top here.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1702>
The back → transparent transition gives it a very bad look when
booting and running the startup animation.
Use the same transition duration hack to ensure that the panel
starts completely transparent.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1678>
There's this little hack that we do to match the panel transition from
transparent to black with leaving the overview via swipe down. The only
problem is that, while the duration of the panel transition itself is
matches, the corners don't, and they get out of sync.
This isn't very noticeable with the swipe gesture, but it'll be much
more prominent when booting straight into the overview.
Bind the 'style' property of the panel to the corners', so that the
transition duration hack applies to all of them.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1678>
The new startup animation consists of rising the Dash from the bottom,
falling the search entry from the ceiling, and going from HIDDEN to
WINDOW_PICKER with an opacity applied.
One little trick from IconGridLayout was added to ControlsManagerLayout,
which is a promises-based wait for allocation. This is required to make
sure that the transformed position of the search entry is valid, which
is only the case right after an allocation.
This animation also ensures that the overview is shown right on startup.
For session modes that do not have an overview, continue using the same
fade + scale animation.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1678>
We want to avoid updating the input region on startup, since it incurs
in roundtrips to the X server, but not workspaces struts, since they
affect the visible clip of wallpapers in the workspace. Since next
commits will make the overview be the after-boot screen, we really
don't want the wallpaper to be clipped wrongly.
Allow updating regions while starting up, but only workspace struts.
Make sure input is not updated by accounting for 'this._startingUp'
on 'wantsInputRegion'.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1678>
This is an X11-specific routine, and building the list of input region rects
on Wayland is a waste, since it incurs in many trampolines only to throw them
in the trash.
Don't build input region rects on Wayland. By modifying the 'wantsInputRegion'
variable, it also skips actors that only update input, which is another small
optimization for Wayland.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1678>
LayoutManager doesn't update struts when there's any modal running. Turns
out, the Overview itself is a modal. That, and the fact that the Overview
will be the startup state, prevents the workarea to be updated.
Allow updating struts when there's no other modal than the Overview.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1678>
Launching applications on a particular workspace works through
launch contexts and startup notifications. While this is no
longer required by a launcher/WM split, in theory this allows
us to reliably identify the correct window to apply startup
properties to.
However in practice we fail more often than not: Missing support in
toolkits, differences between display protocols, D-Bus activation
and single-instance applications all provide their own pitfalls.
So instead, take advantage of the fact that launcher and WM live in
the same process, and go with the unsophisticated approach: Just
remember the last workspace that was requested when launching an
app, then move the next window that is associated with the app to
that workspace.
This will break X11 applications that set an initial workspace, but
that's legacy functionality anyway (given that there's no wayland
protocol for that functionality), and seems a price worth paying
for making launching apps on workspaces more reliable.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1316>
Let the goToPage call afterwards to take precedence, instead
of resetting the adjustment (thus the view) on the side.
This resulted in strange state when the last page contains
a single icon, and it is dragged. The last page being emptied
triggers a pages-changed signal, which half resets the view
to the first page while DnD is ongoing.
Letting goToPage do its business means we neatly clamp to the
closest page to currentPage, the last page in that case.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1630>
When clicking on the page hints, the hint rectangles being visible
in place and not moving together with the page is a bit too
distracting.
Since the page hints are not part of the iconGrid hierarchy and
we have just 2 general ones for prev/next page (i.e. no page
associated), do this sliding via some smoke and mirrors: We don't
slide the page hints, but a parent container for both of them, and
we also control opacity so that the container is fully transparent
mid-page. At the point it is transparent, the container can be
snapped to the other side of the page, and faded back in as it
slides together with it, so it always looks like it goes away and
comes from the right sides.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1630>
Depending on the available horizontal space, we may want to manipulate
the icon grid and scroll view spacing to result in an optimal layout
that has space left to preview prev/next pages.
The main change here is that, when adapting to the available size, the
space given to a page does not necessarily match the available space,
as we need to be able to show more than one page at a time.
With this decoupling of available and page sizes in place, we now know
how much space there is available in order to extend the padding between
pages, or the fade effect applied to the previewed pages.
Underneath, we rely a bit less on hardcoded CSS paddings, and a bit more
on the StScrollView::content-padding property.
All put together, gives us proper space management from ultra-wide
displays, to display ratios that are close to the optimal grid ratio.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1630>
Remove padding on left and right of the contained widgetry, so
there's no seams animating things from the border. Also, remove
the padding between IconGrid pages, so the nest/prev pages are
visible given the dialog width.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1630>
When DnDing an icon, we show both previous/next page, and optionally
a "placeholder" actor to allow creating new pages. These sides on the
scrollview are drop targets themselves, allowing to drop an app onto
the next/prev page without further navigation.
Still, preserve the checks to maybe switch to prev/next page without
finishing the DnD operation, for finer grained operations.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1630>
Add the necessary animations to slide in the icons in the previous/next
pages, also needing to 1) drop the viewport clipping, and 2) extend scrollview
fade effects to let see the pages in the navigated direction(s).
The animation is driven via 2 adjustments, one for each side, so they
can animate independently.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1630>
We want to show left/right side pages during navigation, also in
FolderViews. Let this scrollview use the same style than the "all
apps" one, and generalize the name a bit.
This will compress the scrollview horizontally, so there's actual
overflow space to show these pages.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1630>
This will be needed for fine tuning of the visible area for appGrid
navigation purposes. We most nominally can let it happen via CSS as
the size calculations happen on size allocate, so we want to avoid
triggering relayouts while adapting to the given size.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1630>
Instead of taking just vertical/horizontal offsets, take a ClutterMargin
to allow us set the fade offsets on each direction specifically. Also,
handle negative values in margins, the fade effect will run in the negative
space left by the scrollview padding instead. Another difference now is
that areas outside the extents of the effect will be transparent, instead
of the effect ending abruptly past the given extents.
This will be used by the app grid, in order to selectively let see either
of next/prev pages while navigating.
While at it, fix code style issues in st_scroll_view_update_fade_effect(),
and clean up unused variables from the GLSL code.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1630>
This property controls whether the viewport clips the content to its own
allocation or not. This will be necessary in special modes that we want to
render past the viewport inside a scrollview.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1630>
The workspace minimap is much less prominent than the old workspace
switcher, and serves primarily as an indicator.
That means that duplicating it on secondary monitors (if workspaces
on non-primaries are enabled) is harder to mistake for per-monitor
workspaces, so make some people happy by including the minimap on
every monitor.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1735>
Now that the backgrounds was moved into workspaces, the fullscreen
views on secondary monitors are visually inconsistent with the
primary view, as there's no dash or search entry that reduces the
available height and allows adjacent workspaces to peek in.
Address this by adding padding above and below the view, so that
it is limited to 70% of the available height.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1735>
Right now the handling of external monitors is relatively simple, and
consists of putting either an extra workspace or a full view on the
monitor, depending on the workspaces-only-on-primary setting.
We are about to tweak the behavior on secondary monitors, prepare for
that by splitting out an intermediate actor that manages the views on
non-primaries.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1735>
At the moment views on non-primary monitors take up the entire work area,
so simply allocating the available size works. However we'll soon shrink
the views a bit to match the visuals on the primary monitor. As workspaces
keep the ratio, reducing their height will also reduce the width; override
the default allocate() to keep the extra workspace horizontally centered.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1735>
At the moment, we only get the initial :should-show value when populating
the thumbnails. That only happens when entering the overview, so any
listeners to notify::should-show will perceive it as a change rather
than an initialization, which can result in unwanted transitions.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1735>
We currently initialize the porthole to the screen size instead of
the monitor's work area we actually want. At the moment this doesn't
matter, as the minimap is created during initialization with the rest
of the overview, so we can expect a work area change that updates the
porthole to the correct values.
That won't be true for minimaps we put on secondary monitors, so make
sure we initialize the porthole to the actual values.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1735>
The minimap is currently created once when populating the overview,
and kept around until the end of the session. That will change when
we start to also show it on secondary monitors, so do proper clean
up when destroyed.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1735>
This is used to detect whether a click was short enough to select a
window and activate it or long enough to start a drag. Usually when
clicking on a window and selecting it, this leaves the overview, but
when clicking on a window on a neighboring workspace, the overview is
kept open, but selected is not unset in this case. So all attempts at
dragging the window after using it to switch workspaces will fail.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3783
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1717>
The property describes the target visibility (that is, the visibility
that will be set after the ongoing transition), and is therefore updated
at the start of the transition rather than from hideDone().
The overview gesture currently misses resetting it at the end, so it
is only updated to the correct state the next time the overview is
entered.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3798
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1726>
When adapting the check to the new versioning check, we just blindly
copied the old behavior for stable/unstable versions:
- stable releases must have matching major numbers
- unstable releases must match major and minor ("alpha", "beta", "rc")
That worked for the old even/odd scheme, but now has the absurd effect
that we consider an extension that lists "40.alpha" in its shell-version
incompatible with "40.beta", but compatible with "40.2".
At least this provides us with a good opportunity to reconsider the
behavior. While it is true that breakage is much more likely between
unstable releases, in practice extensions are either following shell
development closely or update once around the time of a stable release.
For the former, the stricter check isn't usually too useful (as the
extension releases around the same time as gnome-shell anyway).
For the latter, it's annoying that ".rc" is treated differently from
".0" and requires an update to become compatible.
The latter is also by far the more common case, so update the check
to only match on the major version regardless of whether a release
is stable or unstable.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3787
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1719>
Since commit 9980c80619, the porthole position is ignored. As a result,
previews are only shown if the primary monitor is located at (0, 0).
To fix this, we either need to propagate the porthole to every thumbnail,
use a custom layout manager that applies an offset to all children, or
add an intermediate actor that offsets the contents.
The last option is the simplest and doesn't require calls into JS on
every allocation, so pick that one.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3781
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1721>
The preview was getting scaled up by a factor based on what is needed to
increase the width by activeExtraSize pixels. With windows that are
wider than than they are tall, this means that the size of the window
will not increase any more than activeExtraSize in any direction, but
for windows that are taller than they are wide, the vertical scaling
can exceed this. This would break some of the assumptions in the
reported size for the preview chrome and could for very narrow windows
result in a rather large scale.
To fix this, calculate the scaling factor based on whatever is larger,
the height or the width.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1707>
Since commit 0f1b566918, we use gjs' automatic getters/setters for
the shader properties. Those handle the properties on the JS and
GObject side, but they don't update the corresponding uniform,
whoops.
Revert the lightbox bits of commit 0f1b566918 to get the effect back.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1712>
In the allocate() vfunc of WorkspaceLayout we use a small trick to make
the nonlinear animation paths when opening the overview less jarring:
Because a window might get smaller than its target size during the
animation, we make sure the size never drops below the final size
calculated by the layout strategy.
In the app grid the Workspace is very small though, and the size of a
window slot calculated by the layout strategy might actually be larger
than the workspaceBox. This means we might use the window slot size
instead of the workspaceBox size and end up with a window that's at the
correct position, but its size is too large.
Fix this by only applying this trick when we're animating towards or
from the state where we actually expect the workspaceBox to be larger
than the window slot, that is during the the transition from the session
to the window picker (or the other way round).
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1698>
It should be allowed to set this._spacing to 0 and thus pass 0 as
rowSpacing or colSpacing to this._adjustSpacingAndPadding(). The current
if-condition there won't add the oversize to the spacing in case 0 is
passed though.
So change that if-condition and explicitely check for null instead.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1698>
Window previews can spill out of the container when their position in the
session overflows the monitor boundaries. In the past, Workspace didn't have
a visible background, and was (almost) always fullscreen, which would mask
this particular problem. However, nowadays, it is very much noticeable when
this situation happens.
Clip the window previews container to its allocation when the overview state
is bigger than WINDOW_PICKER. That is, between HIDDEN and WINDOW_PICKER states,
inclusive, no clipping is applied.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1691>
Instead of adding it to the window previews container, add it to Workspace
itself. This requires expanding WorkspaceBackground, so add the relevant
x and y expand flags.
Since the background is beneath the window previews, create and add it before
the window preview container.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1691>
Currently, Workspace is a single actor that contains both the background,
and all window previews, and is managed by WorkspaceLayout. In the future,
this concentrating aspect of it will bite us; we want the window previews
to be clipped to the allocation, but not the background, since it will
have shadows.
Make Workspace subclass St.Widget with a ClutterBinLayout as layout manager,
and move window previews to a child actor. To reduce the impact of this
extra actor, it's a ClutterActor instead of a StWidget, and the spacing is
still set on Workspace itself.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1691>
The WorkspaceBackground class has specific code to clip the background
to the workarea. However, it doesn't monitor for workarea changes, which
means it cannot react after being created.
Connect to 'workareas-changed', and update the workarea, the radius bounds,
and relayout when workareas change.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1691>
The primary workspace is displayed in the overview, and clipping it
ends up clipping the shadows too. Since Overview's ControlsManager
itself clips to allocation, no windows in the primary monitor spill
to other monitors. However, not clipping non-primary monitors might
end up in situations where their windows spill into the primary one.
Make sure to only clip workspace views of non-primary monitors.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1691>
The dialog is shown at session start, which right now means in the
regular session, however the plan is to start the session in the
overview. When that happens, the "Take the Tour" button should get
the user to the Tour without additonal actions.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1699>
Right now the rowSpacing and columSpacing of the layout strategy is
calculated by looking at the overlapping sizes of the close button and
the app icon of the WindowPreview, plus a constant spacing read from CSS
by the WorkspaceLayout that's added to that. We're not factoring in the
extra size of the scaled-up WindowPreviews here and instead depend on
the constant spacing being large enough. If we don't want to depend on
the spacing here, we should add the scaled-up extra size to the sizes
returned by chromeWidths() and chromeHeights().
Since the last commits all previews scale up by the same amount of
pixels, so we can now just add that size to the values returned by
chromeWidths() and chromeHeights().
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1692>
Scaling differently sized WindowPreviews by a constant factor will
result in smaller windows getting enlarged by a smaller amount of pixels
than larger windows (1000*1.02=1020 but 100*1.02=102, one will grow by
20 pixels and the other one by 2), this can look a bit weird because
smaller windows don't scale up as much as larger windows.
So introduce a constant extra size to use when scaling windows up, we
set only the half size there because we want to ensure that the size
added on both sides is not fractional and we remain aligned to the pixel
grid.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1692>
Right now the spacing between icon and title works using a little trick
that doesn't really seem intended: The title is offset by
(icon-height * ICON_OVERLAP), when the icon is actually overlapping the
preview by ICON_OVERLAP, and *overflowing* the preview by
(1 - ICON_OVERLAP).
So correct that and offset the title by
(icon-height * (1 - ICON_OVERLAP)), and since now there's no spacing
anymore, add a proper ICON_TITLE_SPACING to that offset.
Also add the new ICON_TITLE_SPACING to the overlapHeight, where the
spacing was ignored so far.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1692>
The scale property tracks the relative size at which we display thumbnails
given the space we have available.
That assumes that the allocation represents that available space, but it will
actually be smaller while the minimap itself is collapsing.
Luckily we have an easy option to avoid a distorted scale: Just don't update
it while collapsing. We expect scale changes when adding or removing thumbnails,
but as we freeze those during transitions, we can do the same with the scale.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3739
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1696>
Right now the minimap only hides itself in case of a single static
workspace. That's not only an edge case, but also not expected to
change while the overview is visible, so changing the visibility
without a transition is fine.
However that is about to change, and we'll hide the minimap as well
when there are fewer than three workspaces. As that condition is
very much expected to change from within the overview, the transition
should be animated.
Implement that via a new :collapse-fraction property on ThumbnailsBox,
and use that to transition both the height of the box itself and the
scale of the individual thumbnails.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3739
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1696>
We currently have two components that show or hide the minimap:
- the thumbnails hide themselves in case of a single static workspace
- overview controls show the minimap when no search is active
That obviously doesn't work correctly.
To fix this, change thumbnails to set a new :should-show property instead
of the visibility, and let the overview controls take it into account
when changing the visibility.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3739
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1696>
A small mistake snuck in right before landing the previous commit and
the box-shadow was moved 4px vertically above the wallpaper instead of
below it. Fix that and put it 4px below the wallpaper.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1697>
According to the GNOME 40 mockups, add a box-shadow to the workspace
background. For this to work, we also need a background-color (St
limitations), and to make sure that background-color doesn't bleed over
the rounded corners of the wallpaper, we also need to tell St to use a
border-radius and clip the background-color painting using a rounded
path.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1651>
As planned and shown in the mockups for GNOME 40, round the corners of
the background wallpaper of workspaces.
To do that we use the new rounded-clipping support of
MetaBackgroundContent and we animate the radius by attaching it to the
stateAdjustment just like everything else.
Because we show only a part of the wallpaper and "cut away" the area of
the panel in WorkspaceBackgrounds vfunc_allocate(), we also need to set
the rounded clips bounding rect to the rectangle we're actually showing,
otherwise the texture would be rounded in the region that's cut away.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1651>
This is the same as the vertical swipe gesture, but for keyboard
junkies: Analoguous to the <super><alt>left/right shortcuts for
switching between workspaces, add <super><alt>up/down to shift
between session, window picker and app grid.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1695>
When commit 3a9acb96 moved around padding to extend the clickable
area to the screen edge, it reduced the inner padding too much and
the running indicator ended up outside the highlighted area.
Adjust the padding to put it back into its place.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1693>
The animation handling is kinda split between layout (for the
keyboard slide), and keyboard (for the focus window slide). It
would be nice to have more fine grained control on those, so
move the animation handling altogether to keyboard.js as a start.
This is roughly similar, except that transformations apply to
the Keyboard actor, instead of the keyboardBox (its parent). We
now queue a relayout after the animation in order to update the
chrome tracking.
The only layering break now is that we emit
layoutManager::keyboard-visible-changed in keyboard.js, its
purpose will be dropped in future commits, so leave it there for
now.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1668>
Gestures leaving the overview from a short distance result in an
ugly effect with the panel opacity transitionhaving a fixed duration.
Make this transition have the same duration (although in a hackish
way) so we avoid the ugly effect.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1643>
The gesture internally manipulates the main adjustment so one swipe
up brings up the overview, and a second swipe up brings the app
grid. The gesture also works in the other direction to get out of
the overview.
Internally, this is delegated on the OverviewControls, so the
adjustment is not leaked out of there. This however meant open
coding the gesture interaction so it can be directed from
overview.js code.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1643>
This will be set whenever an event controller is manipulating the adjustment.
It should enter the same transitional state it does for animations. This
will be used by the overview gesture.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1643>
Separate this logic from _switchWorkspaceBegin() and ensure it is set
before this call. The SwipeTracker code uses the orientation to determine
whether the gesture should begin at all, so changing the orientation on
gesture begin was a bit too late.
But also, that meant the SwipeTracker was left at the default orientation,
which was vertical (unlike workspaces, and like the overview gesture).
This made both swipe trackers try to handle the same swipe, with the
WorkspacesView being doubly unfortunate (for triggering in the first place,
and for happening after the other gesture did queue relayouts on it).
Taking this logic outside of _switchWorkspaceBegin() and having the right
orientation beforehand results in both gestures looking for their direction,
and not meddle with each other.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1643>
We now have multiple touch swipe gestures with matching fingers and
different directions set on the overview hierarchy. Accepting all
touch swipes without checking the direction makes one of these gestures
take control of input, without other gestures having a say on this.
So, look for the direction of the touch events and look if it matches
the expected orientation before accepting the gesture.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1643>
Make the touchpad gesture keep track of its state, and enter in a
rejected state if the swipe is happening in the wrong direction.
Effectively, this means touchpad gestures are locked on a single
direction, and horizontal+vertical swipeTrackers won't be handling
events at the same time.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1643>
We now have multiple touch swipe gestures with matching fingers and
different directions set on the overview hierarchy. Accepting all
touchpad swipes without checking the direction makes one of these gestures
take control of input, without other gestures having a say on this.
So, look for the direction of the swipe events and look if it matches
the expected orientation.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1643>
Some actors don't have the scale applied to them directly but are
children of a scaled parent. In those case just retaining the scale will
not be enough and the scale of the actor itself needs to be adjusted
when reparenting. This could for example be seen when dragging windows
from the workspace thumbnails.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1687>
Even if activePage has been removed as part of commit 27627bd40, we've
still a reference of it in key press handler.
Given that there's no anymore an active page to redirect input to,
remove these references, so that can be handled in the proper view to
implement key-navigation.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1688>
When opening a large number of windows, the computed space and scale for
a layout can become negative due to the per-row/per-column spacing. This
is smaller than the initial values of lastSpace and lastSpace, leading
to a null return which then causes all sorts of other issues resulting
in the workspace becoming invisible.
This change ensures that the function always returns a layout, even if
it may look a bit broken and does not conform to the scale/space
requirements which are impossible to fulfill for the given number of
windows. It's better than displaying nothing, since it allows users to
move/close windows and restore this to a more usable state.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3730
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1685>
When we got an error, all the other HINT or INFO messages are not useful
anymore and delaying to show them is just a waste of time and may be
even wrong in scenarios with fast authentication devices.
An example are the fingerprint devices, where the user may touch the
sensor repeatedly while we may still show the "touch the sensor" hint
instead of notifying of possible errors.
So, in case we got an error override all the other errors coming from
the same service with lower priority.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1683>
Once the verification has been stopped or has failed all the messages
that are not of error type are just not needed or wrong to show.
For example, in the fingerprint case we may still show the hint to swipe
or touch the device, while the fingerprint PAM service has already been
stopped.
So filter them by adding a new function that adds a null message to the
queue, overriding all the messages that have a lower priority.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1683>
There are cases in which a service may want to override a message with
one coming with higher priority, for example an info or hint message
isn't useful anymore if we've already got an error message.
In the same way when a service has been stopped we don't care anymore
showing its info or hint messages, while it still may be relevant to show
errors.
An example is the fingerprint service that may emit errors quickly while
the hints messages should not be kept around when an error is already
queued or when the service has been stopped.
So, add function that allows to override queued messages based by their
type that follows this policy:
- Messages coming from different services are always preserved in
their original order.
- Messages (from the same service) with a priority equal or higher than
the last queued one are preserved.
- Messages matching completely the last queued are dropped in favor of
this one.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1683>
It can be convenient to get the currently showing message in order to
replace or remove it in case it's not needed anymore.
So simplify the message queue handling by only depending on a single
local variable (_messageQueue) and redefining hasPendingMessages
depending on its content.
Now messages are kept in queue till they are not fully processed and the
first message is always the one currently shown.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1683>
When a fingerprint failure event happens we may also soon receive a
conversation-stopped event with an error message (such as in the case
we hit the MAXRETRIES value), but this is going to be ignored in case we
are too quick in consider the first failure a verification-failed event
because that implies disconnecting from all the events and then ignoring
such signals.
To prevent this, add a small timeout before failing the verification so
that if we get a further event we will process it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1683>
In the case a service is not available (as it can be in the fingereprint
case when a supported reader is available but has not enrolled prints)
we were trying indefinitely to restart it, however this can lead to
troubles since commit 7a2e629b as when the service conversation was
stopped we had no way to figure out this case and we'd end up to
eventually fail the whole authentication.
However, in such cases the PAM services are expected to return a
PAM_AUTHINFO_UNAVAIL and gdm to handle it, emitting service-unavailable
signal.
So connect to ::service-unavailable and keep track of the unavailable
services so that we can avoid retrying with them.
In case such service is not the foreground one, we can just silently
ignore the error as we did before commit 7a2e629b, without bothering
failing the whole verification.
In case we got a valid error message on service-unavailable, we also
show it, this is normally not happening unless GDM isn't redirecting
here other kind of problems (such as MAXTRIES) which are supposed to
stop the authentication stopping any further retry.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3734
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1683>
When creating an icon for the system actions search provider, set the
icon size using StIcons own icon-size property instead of ClutterActors
width and height property. That ensures the scale factor is applied and
the icon will be properly scaled on hiDPI screens.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1686>
The icon and close button might be overlapping the window actor but
were not considered in has_overlaps() which gets used to decide whether
to offscreen the actor for transparency. Since currently the icon is
visible when the preview is dragged and the whole actor is turned
transparent, the opacity will not be applied to everything as a whole
but the child actors individually. This leads to the window becoming
visible behind the icon.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1684>
Calling startTouchGesture() on the workspacesViews can change the
visibility of the workspaces if not all of them are already shown, such
as when there are more than 3 workspaces or for 3 workspaces if we are
not on the central one. This invalidates the allocation and the width
used as distance for the gesture would become 0, resulting in drag
gestures immediately jumping to the first or last workspace due to a
division by 0.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3721
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1682>
Currently when the foreground service conversation stops we increase the
verification failed count and try to start it again, while if a
background service has been stopped we just ignore it.
This is causing a various number of issues, for example in the case of
the fingerprint authentication service, it is normally configured to die
after a timeout, and we end up never restarting it (while the UI still
keeps showing to the user the message about swipe/touch the device).
So, in such case let's just consider it a "soft" verification failure
that doesn't increase the failures count but will cause us to reset the
UI and try to restart the authentication (and so the affected service).
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1652>
Wiggle may make the error message to be visible for less time so provide
the auth prompt an API to increase the timeout to be used for showing a
message in some cases.
This could be reworked when we'll have a proper asyn wiggle function so
that we could just make the user verifier to "freeze", then await for
the wiggle transition to complete and eventually release the verifier.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1652>
Currently whenever an authentication failure happens we wiggle the
entry, however this may not be related to the service which failed.
For example if the fingerprint authentication failed for whatever reason,
there's no point to wiggle the text input as it's something unrelated to it.
So, only apply the wiggle effect to the entry in case the failure is
coming from the querying service.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1652>
By giving to the AuthPrompt information regarding the source service
name (and so the ability to know whether it's a foreground service) can
give it the ability to behave differently.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1652>
Fingerprint PAM module can have multiple failures during a runtime
and we rely on the pam module configuration for the maximum allowed
retries.
However, while that setting should be always followed, we should never
ignore the login-screen's allowed-failures setting that can provide
a lower value.
So, once we have a fingerprint failure let's count it to increase our
internal fail counter, and when we've reached the limit we can emit a
verification-failed signal to our clients.
As per this we need also to ignore any further 'info' messages that we
could receive from the fingerprint service, as it may be configured to
handle more retries than us and they might arrive before we have
cancelled the verification session.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1652>
Decouple the verification failure count increase from
_verificationFailed as there are some cases in which we may want to
increase it without emitting a verification-failed signal.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1652>
When the login/lock screen is shown the error messages for background
services are always ignored.
However, in case the service is the fingerprint authentication method
we still want to be able to show error messages to inform the user
about what failed, and eventually that the max retries (that may be
different from the login screen configuration) has been reached.
This handles partially the design issue [1] related to the login/lock
screen fingerprint authentication.
Eventually we want to use pam extensions to use clearer and parse-able
messages, however in the case of the fingerprint service we can be sure
that the fprint PAM module will only send errors on auth failures.
[1] https://gitlab.gnome.org/Teams/Design/os-mockups/-/issues/56
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1652>
When we're painting off-stage, for example because we're screencasting
or taking a screenshot, there won't be a stage-view associated with the
paint context. The BlurEffect previously didn't handle that case and
would crash.
Fix that and handle that case by assuming the scale is 1 and not
offsetting the rectangle we blit from the draw framebuffer.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1673>
Checking whether the item is empty is now the history’s job, per the
previous two commits. The history also trims the input for us.
The effect of this is that we call _history.addItem(), and thereby move
to the end of the history, even if the input is empty (or consists only
of whitespace); clearing the input field and pressing Enter becomes a
quick way to jump back to the end of the history. (The current history
item is not overwritten if the input is empty.)
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1653>
This ports the runDialog changes of [1] to the underlying history
component, where they can benefit looking glass as well: the history is
now responsible for trimming the input and deciding that it shouldn’t be
stored if empty. (Note that _setPrevItem and _setNextItem already
skipped updating the history if the entry was empty.)
Since both users, runDialog and lookingGlass, also need the trimmed
input for other reasons – runDialog to avoid issues when interpreting
the command as a file path (if it can’t be executed as a command),
lookingGlass to decide whether a command should be run at all – have
addItem return the trimmed input. (runDialog and lookingGlass are not
yet changed to take advantage of this – that will be done in separate
commits.)
[1]: https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1442
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1653>
When verification failed using a specific authentication service we're
currently restarting the whole user authentication system, which leads
to lots of unneeded operations (reinitializing a new user verifier proxy,
restarting all the gdm workers with the relative PAM modules and so on).
And this makes also debugging of login problems more complicated, given
we're cluttering the journal with repeated data.
However, at reauthentication failure GDM has already set up for us an
user verifier that we can use reuse to start only the service that had a
failure. So when possible, just start a new service instead of rebooting
the whole authorization process.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1622>
When retrying the authentication we should make sure that all the
previously initiated services are stopped in order to begin a new
authentication session with all the configured services.
Unfortunately at the current state we only dispose the currently used
user verifier, but we don't make it to stop all the relative gdm workers
and then they'll stay around potentially blocking any further usage of
them (as it happens with the fingerprint one, that has unique access to
the device).
So, cancel the currently running authentication before starting a new
one if we're explicitly retrying.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1622>
In case a background service such as the fingerprint authentication
fails to start we'd just mark the whole authentication process as
failed.
Currently this may happen by just putting a wrong password when an user
has some fingerprints enrolled, the fingerprint gdm authentication
worker may take some time to restart leading to a failure and this is
currently also making the password authentication to fail:
JS ERROR: Failed to start gdm-fingerprint for u: Gio.DBusError:
GDBus.Error:org.freedesktop.DBus.Error.Spawn.Failed:
Could not create authentication helper process
_promisify/proto[asyncFunc]/</<@resource:///org/gnome/gjs/modules/core/overrides/Gio.js:435:45
### Promise created here: ###
_startService@resource:///org/gnome/shell/gdm/util.js:470:42
_beginVerification@resource:///org/gnome/shell/gdm/util.js:495:18
_getUserVerifier@resource:///org/gnome/shell/gdm/util.js:405:14
async*_openReauthenticationChannel@resource:///org/gnome/shell/gdm/util.js:378:22
async*begin@resource:///org/gnome/shell/gdm/util.js:194:18
_retry@resource:///org/gnome/shell/gdm/util.js:561:14
_verificationFailed/signalId<@resource:///org/gnome/shell/gdm/util.js:584:30
_emit@resource:///org/gnome/gjs/modules/core/_signals.js:133:47
finishMessageQueue@resource:///org/gnome/shell/gdm/util.js:268:14
_queueMessageTimeout@resource:///org/gnome/shell/gdm/util.js:273:18
_queueMessageTimeout/this._messageQueueTimeoutId<@resource:///org/gnome/shell/gdm/util.js:288:65
Given that background services are ignored even for queries or any kind
of message, we should not fail the authentication request unless the
default service fails.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1622>
When a verification session has failed we may want to wait for the user
to have completed all the waiting queries and to have read all the
incoming messages, however during such time an user verifier should
not be allowed to queue further messages to the UI, as we're about to
completely stop the identification or start a new one.
Unfortunately this is not true because we're still connected to the
identifier signals, and so we may still show messages.
This is particularly true when using the fingerprint PAM module as it
may restart the authentication while we're in the process of stopping
it.
So, keep track of all the signals we've connected to, and disconnect on
verification failed and during cancel/clear operations.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1622>
Answering a query may be delayed to the moment in which we've not any
more messages in the queue, however this case can also happen just after
we've cleared the UserVerifier and in such case we'd have nothing to
answer, but we currently throw an error:
JS ERROR: Exception in callback for signal: no-more-messages:
TypeError: this._userVerifier is null
answerQuery/signalId<@resource:///org/gnome/shell/gdm/util.js:249:17
_emit@resource:///org/gnome/gjs/modules/core/_signals.js:133:47
finishMessageQueue@resource:///org/gnome/shell/gdm/util.js:266:14
_clearMessageQueue@resource:///org/gnome/shell/gdm/util.js:301:14
clear@resource:///org/gnome/shell/gdm/util.js:223:14
cancel@resource:///org/gnome/shell/gdm/util.js:205:18
reset@resource:///org/gnome/shell/gdm/authPrompt.js:482:32
cancel@resource:///org/gnome/shell/gdm/authPrompt.js:569:14
vfunc_key_press_event@resource:///org/gnome/shell/gdm/authPrompt.js:128
So handle this case more gracefully keeping track of the current
cancellable and checking whether it is still valid before trying to answer
a query or do a delayed action.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1622>
As per previous commit the user can cancel an ongoing authentication via
Escape key and that will always send the user back to the clock view in
lockscreen or user-selection view in login prompt.
However, we can be a little more permissive and don't switch view to be
able to restart the authentication without further action.
To avoid this to be abused though, we consider the user verification
cancellation via escape key to be a "soft-failure", so once the
configured "allowed-failures" gsettings value has been reached, we'd
just act as before, ignoring any further request (until we don't get
back to the user auth view).
In this way we still make brute-force attacks harder to do, while still
giving the well-behaving user some ability to fix mistakes.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1622>
Escape key is supposed to cancel a verification, however if the user
already hit Enter to begin the authentication the Escape key won't work
until the verification completed.
This may be quite inconvenient when an user did a typo while writing and
wants to cancel the already started auth.
So, while authenticating (or in general while the entry is unsensitive)
give the key focus to the authpromt itself so that we can still get the
input events and cancel an user action.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1622>
When a cancel event in the user lockscreen happens we first emit a reset
signal and immediately a cancelled one.
This lead to start a new gdm worker for each enabled authentication
method and then immediately to stop it.
As per the previous commit, we don't have anymore dangling gdm workers
around, but still we should not even start a new one in such case.
So, when the user explicitly cancelled the authentication session, first
emit a cancelled event and only emit a reset event with a begin request
if we are outside the lockscreen.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1622>
When we cancel an user authentication via Escape key or cancel button on
AuthPrompt we reset the view and we emit a 'cancelled' signal that leads
to destroying the auth prompt and the user verifier.
However, the verifier may still have an operation in progress and its
completion may take some time (as in the case of gdm-fingerprint), but
we just leave the gdm worker running until its pam module completes
(potentially never) clearing and disposing its handle.
So, instead of just clearing the verify, actually cancel and clear it.
In case the user verifier is set, clearing the relevant data will happen
anyway as part of the cancel() call.
Ideally this would have been handled by gdm itself, but unfortunately we
can't fix it there because the verifier itself is a class generated by
gdbus-codegen, so we can't handle this automatically on disposal nor we
can automatically monitor when the caller proxy is stopped on our side.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3654
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1622>
Scaling the icons all the way from/to 0 is a relatively big transition,
which is fairly distracting when playing simultaneously for multiple
previews after reaching the WINDOW_PICKER state.
Instead, tie the scale to the overview state itself, so that the animations
runs in parallel.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1654>
Back when the Dash was vertical, the size of each item was calculated
solely based on the available height. After making the Dash horizontal,
this was swapped by the available width. However, when the height of the
Dash decreases, the current code results in never scaling them up ever
again.
Fix that by making ControlsManagerLayout explicitly pass the maximum Dash
sizes. Remove the 'notify::width' handler that served the same purpose.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3651
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1638>
Remove the dummy applications page that was introduced as a temporary
step. Replace the 'page-changed' and 'page-empty' signals with a 'search-active'
boolean property.
Remove ViewSelector.ViewsPage since it's now unused, and all the page handling
mechanism. At last, since we don't use any ShellStack features anymore, simply
make it a St.Widget with a ClutterBinLayout as the layout manager.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1667>
Add a "screenshot-taken" signal from the screenshot service's internal C
implementation, and use that to trigger the camera flash visual effect
and the click sound, allowing them to run in parallel with the PNG
compression instead of waiting until the file is complete to start.
This significantly improves perceived latency on high res setups such as
4K, 5K, or dual 4K screens.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/512
Co-authored-by: Brion Vibber <bvibber@wikimedia.org>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1658>
On my local jhbuild setup some local stuff is not set up and
there's no pictures folder. This fixes a regression where it
blew up instead of saving to the home dir in this situation.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1658>
In addition to disabling the overlay when the state is not 1,
disable it also when not in the active workspace.
Make the Workspace class track the workspace's active state,
and resync the overlays when it changes.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1645>
The behavior of workspaces is different depending on whether
the overview is in window picker state, or app grid state.
When in window picker state, clicking on adjacent workspaces
should only activate them, without hiding the overview; and
clicking on the active workspace hides the overview. When in
app grid state, clicking on a workspace must always hide the
overview.
Pass the overview adjustment to Workspace, and leave overview
if the overview state is bigger than WINDOW_PICKER.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1645>
The overview transition consists of getting the initial and final
states of the overview adjustment, derivating various other internal
states from them (such as the fit mode, opacities, translations, etc),
and finally interpolating the allocation boxes.
When interpolating between the fit mode, WorkspacesView uses the current
allocation box to derivate the SINGLE and ALL fit mode boxes. However,
that creates a curved path during overview transitions. What we really
want to do here is calculate the fit mode box relative to the corresponding
overview state. For example:
+----------------+----------+------------------------+
| Overview State | Fit Mode | Workspaces geometry |
+----------------+----------+------------------------+
| HIDDEN | SINGLE | Cover entire screen |
| WINDOW PICKER | SINGLE | Between minimap & Dash |
| APP GRID | ALL | 15% screen height |
+----------------+----------+------------------------+
Using the table above as the reference, when the overview transitions
between WINDOW PICKER and APP GRID, we must interpolate between
(SINGLE fit mode @ between minimap & Dash) and (ALL fit mode @ 15% screen
height). That way, we always interpolate the final boxes, which corrects
the odd path that workspaces follow during this transition.
Make the WorkspacesView of the primary monitor use these cached boxes
when the overview is in the middle of a transition, and the fit modes of
the initial and final state differ, to calculate the workspaces positions.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1624>
It makes more sense in a spatial overview that the app grid
comes and goes to somewhere in the screen, instead of fading
in and out into the void.
Make the app grid rise from the bottom of the screen.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1624>
Move AppDisplay, WorkspacesDisplay, and ThumbnailsBox from ViewSelector to
ControlsManager. This allows to always allocate the correct size for AppDisplay,
and will enable for a plethora of further improvements. The end goal is to
completely remove ViewSelector, and let ControlsManager handle the layout of
everything that's visible in the overview.
For now, replace the apps page with a dummy actor in ViewSelector.
Adjust various callers around the codebase to not access the ViewSelector
directly from the overview anymore.
Bind the opacity of the primary workspace to WorkspaceDisplay's opacity. This
allows removing the parent opacity hack in place, which will be done by the
next commit.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1624>
Now that Overview is able to ease into any state, be it window
picker or app grid, we can move this ViewSelector method to
Overview itself, which is its rightful place to live.
Remove ViewSelector.showApps(), and make all callers call
Main.overview.show(ControlsState.APP_GRID). Also make sure the
show apps button is correctly toggled.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1624>
Next commits will requires ControlsManager to animate to different
states, depending on how Overview is called. Add a new 'state'
parameter to ControlsManager's, and OverviewActor's animateToOverview,
and Overview.show().
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1624>
Remove Workspace.zoomTo/FromOverview(), they're unused now. Rename
everything up to ControlsManager to prepareToEnter/LeaveOverview(),
since these classes don't run the animation anymore.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1624>
WorkspacesView uses the floating layout when the overview is in window
picker mode, and the session layout when the overview is in app grid
mode. Up until now, the fit mode adjustment was used to derive the
workspace mode, but it is incomplete as it doesn't have the full range
of workspace states.
Make ViewSelector cascade the overview adjustment to WorkspacesDisplay,
and use the overview adjustment itself to derive the workspace mode.
Extra workspaces don't have to account for the fit mode, and thus are
basically a clamp(state, 0, 1) of the overview state. However, don't
call animateTo/FromOverview() anymore, since they ease the workspace
mode adjustment.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1624>
Boy, does this commit feel good.
While the workspaces view on the primary monitor *appears* as part of
the overall overview hierarchy, this hasn't actually been the case
until now. We synchronized its size and (stage) position to match
the workspaces display, but actually kept in a separate layer for
the transitions to and from the overview.
But now that the new layout manager slides out completely during the
overview transitions, the workspaces display starts out covering the
entire work area, which is exactly what we need for the transition.
So finally stop faking it, and actually make the primary workspaces
view a child of the workspaces display.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1624>
Instead of delegating it to ViewSelector, make the transition to and from
overview ease the main state adjustment.
This commit temporarily breaks these animations, but on the other hand
introduces an important feature: ViewSelector is always allocated to the
actual size. This will finally allow for adding WorkspacesView as a child
of WorkspacesDisplay, and finally remove the actual geometry hack, which
is what next commit is about.
This commit also effectively reverts b64103efc.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1624>
Instead of directly accessing ViewSelector and calling these methods
there, cascade the calls to OverviewActor, ControlsManager, and finally
ViewSelector. Also move the opacity transition to OverviewActor.
This commit has no functional change.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1624>
Currently, ActivitiesContainer reacts to showAppsButton and
transitions between app grid and window picking states on
its own. In the future, we want full control over this.
ControlsManager already has a state adjustment that represents
all possible overview states. Propagate this adjustment up to
ActivitiesContainer, and use it to drive the transition.
This requires moving the callback to the showAppsButton to
ControlsManager, since now it control the state adjustment
itself, not ActivitiesContainer's adjustment.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1624>
In the future, we want to tightly control the state of the
layout throught gestures, which requires hooking everything
together with adjustments. This is the first step in this
direction.
Add a new custom layout manager for ControlsManager that
allocates the search entry, the view selector, and the Dash,
vertically.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1624>
Currently, gnome-shell uses the wrong scrolling direction for
horizontal scrolling events.
When dx < 0 for a smooth scroll event, then the scrolling direction is
supposed to be Clutter.ScrollDirection.LEFT, instead of
Clutter.ScrollDirection.RIGHT, as dx is smaller than 0.
Fix this issue by swapping the values LEFT and RIGHT.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1665>
It is possible for an initiated session to complete without
a request if polkit can authenticate the action without user
input. We fail to clean up after ourselves in that case, as
the cleanup is done after the dialog is closed.
The dialog can still be shown when the code that hides existing
dialogs while the screen is locked shows it on unlock. But as
the session was closed, the dialog is now defunct and cannot
be dismissed by the user.
Fix this by running the cleanup on close() when the dialog
wasn't shown.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3701
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1662>
The children variable holds the icons that were originally in
the dash. For the separator visibility, we should consider the
icons that are in the dash after the update, so we must consider
additions as well as removals.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1659>
Previously we used a bunch of heuristics for this. We checked if velocity
was directed towards the nearest snap point and its value was larger than
a threshold. If it is, we completed the swipe, otherwise we cancelled it.
This was good enough at the time, because this code was originally written
for back/forward swipe. Since then, the swipe tracker was extended to
handle arbitrary snap points and not just 0 and 1, or -1 and 0, depending
on text direction. After that it was iterated on, but never significantly
redone.
This worked well enough, but had two problems:
1. In some cases, notably overview, it may be wanted to be able to swipe
through multiple pages at once. This wasn't really possible because we
always picked the adjacent snap point.
2. Since we can't do that well, we want to restrict swipes to one page at a
time. It was done in a rather hacky way by clamping the position into
[-1, 1] range from the place where we started the swipe. This works
if we start the swipe from idle position, but if an animation was
already going, the range would be clamped to arbitrary values, and very
likely containing only one snap point, which we already swiped past at
this point. In this case, finishing the swipe would cancel it regardless
of velocity. This means that if one tries to quickly move through
carousel pages via swiping, half of the swipes will be inexplicably
cancelled.
We'll use the deceleration formula from
https://medium.com/@esskeetit/how-uiscrollview-works-e418adc47060#10ce
to calculate then projection point, then pick the nearest snap point and
calculate the duration as we did before. It works well enough for short
distances, but has two problems:
1. It caps the maximum distance at a pretty low value - about 5 pages in my
testing.
2. With how we pick the nearest snap point, it's too easy to accidentally
cancel the swipe,
To combat the first problem, we can modify the curve: only use linear
function at small distances, and smoothly transition it to a parabola
further.
For the second problem we can add two special cases: first, if the swipe
ended up between the initial snap point and the next one, we always prefer
the latter. Second, a good old velocity threshold for cancelling.
We'll also use a slightly smaller deceleration value for touchpad: 0.997
instead of 0.998.
Now that we can pick any snap point, the [-1, 1] clamping doesn't make
sense anymore, so instead let's replace it with a more flexible
mechanism: if we're near a snap point, pick its adjacent snap points.
Otherwise, take the two nearest snap points, and take their adjacent
snap points. This way we have 3 snap points to choose from when
starting a swipe from an idle position, and 4 if we start during an
ongoing transition.
This way, if we've just swiped from snap point n to n+1, the transition
will pick snap points n-1, n, n+1, n+2 and if we swipe again, we will
likely land on n+2. During that transition, if we swipe again, it will
likely have already passed the snap point n+1, so this time the available
snap points will be n, n+1, n+2, n+3, so we can swipe again and it will
still complete, and so on.
This will make it easy to allow multi-page swipes as well, by just
removing the clamping.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1647>
In some cases we may get anevent with very low delta at the end of the
swipe. While we can't completely ignore them, we can smooth them using a
scroll history, similarly to what GTK kinetic scrolling does: keep track
of the last 150ms of events, and sum their deltas when calculating the
velocity.
The logic is based on what GTK does in GtkGestureSwipe and
GtkEventControllerScroll.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1647>
The reason this wasn't using the Gio.DBus.makeProxyWrapper() convenience API is that it passes custom flags to the proxy, and that wasn't supported by the wrapper at the time.
As this is now possible, this commit migrates us to the new API.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1572>
Commit 473e77e2c5 fixed applying the :insensitive pseudo class to
initially unreactive widgets, and adjusted the style test to work
with that.
In hindsight, we can do better than just making the test work, and
include a test case for the :insensitive styling as well (namely
the issue the previous commit was fixing).
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1649>
Let empty input result in an error, just like other invalid commands
(bad syntax, nonempty whitespace, etc.). GLib already has an error
message “Text was empty (or contained only whitespace)” which it shows
for whitespace-only input, so letting that message apply also to empty
input makes sense.
This requires some tweaks further down the file to avoid interpreting
empty input as an empty path (relative to the home directory) and then
opening the home directory.
Part of https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3183.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1442>
We are applying the :insensitive pseudo class to unreactive widgets,
or at least we are supposed to. As we currently only update the style
on notify, we don't apply it to initially unreactive widgets.
This was covered up partially until recently when Clutter started to
use G_PARAM_EXPLICIT_NOTIFY. Before that, the notify handler would run
when explicitly setting :reactive to FALSE at construction time.
Make sure we always apply the pseudo class correctly by updating it
after construct properties have been set.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3685
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1648>
We want to use the fast path of filling the entire area if either the
left and right shadows would overlap or the top and bottom shadows. The
latter check was wrong due to a typo resulting in the regular path
being used in some cases it couldn't (and shouldn't) handle.
This was causing the inset shadow used to highlight panel buttons to
not appear for buttons above a certain width.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1646>
Resource icons are added to the fallback icon theme, so they won't
get used if a matching icon is found in the configured theme.
That includes fallback names, so Adwaita's "window-close-symbolic"
takes precedence over "window-close-24-symbolic" in hicolor.
Fix this by using a custom name for a custom icon.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1640>
Adwaita uses ui/ for the corresponding icon, but GTK treats icons
from a resource path as part of the hicolor theme that doesn't
have such a subdir. And as GTK determines subdirs by enumerating
the theme directory, any subdirs that only exist in the resource
are ignored, whoops.
Make sure the icon can be found by moving it to a standard subdir.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1640>
The Message class this is derived from unconditionally adds a close
button with 0 opacity that only gets shown on hover for messages that
can actually be closed. The MPRIS MediaMessage however can never be
closed and having a close button can cause the title to be cut short
unexpectedly.
Similarly the secondary text which other notifications use to display
the notification time is always left empty here as well.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3664
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1632>
grabHelper is passing a boolean argument to onUngrab() callback function
and since commit 1acbdcc9b3 we'd end up adding it to to the callback list or
we'd try to invoke it:
(gnome-shell:3490851): Gjs-CRITICAL **: 17:19:20.460: JS ERROR:
TypeError: func is not a function
onComplete/<@/media/M2/GNOME/gnome-shell/js/ui/appDisplay.js:2407:56
onComplete@/media/M2/GNOME/gnome-shell/js/ui/appDisplay.js:2407:40
_makeEaseCallback/<@/media/M2/GNOME/gnome-shell/js/ui/environment.js:85:13
_easeActor/<@/media/M2/GNOME/gnome-shell/js/ui/environment.js:170:64
Use an arrow function so that we can control the parameters we pass
to popdown.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1635>
We now set a padding for the left and right
side of the pill. We also got rid of the padding on the icon.
Probably broken due to the removal of the dropdown arrow
which likly handled the padding the right side of this item before.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1615>
This get's rid of the single-indicator introduced in one of the latest
commits. This was causing the accessibility pill in the top panel
to have different padding from the keyboard layout pill.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1615>
So far, we couldn't allow workspace scrolling outside the overview
because scroll events were always sent to clients. However mutter
was changed recently to pass on scroll events when the mouse button
modifier (usually super) is pressed, which allows us to enable the
same workspace scrolling as in the overview now.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1612>
The design now calls for super-scroll for workspace switching
in the session, however it is currently only possible for
SwipeTracker to either handle scroll events or not.
In order to support the new use case, add a new :scroll-modifiers
property that allows specifying modifiers for which scroll events
are handled.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1612>
The code to update the actor position based on the cursor and current
scale was run in a 'new-frame' handler. This is working fine when
animations are enabled, but when they are turned off this does not work.
This is because the 'new-frame' signal is emitted before the changes for
that frame are applied. So with animations off the position was only
ever updated with the starting values. As a result the shrunk actor was
not being dragged by the position where it was clicked, but by where it
was clicked in the original size, which is likely not even on the shrunk
actor.
This change now also updates the position in the onComplete handler
which gets run with the final scale, even if the duration is 0.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/1699
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1627>
Next commit will bind the workspace state adjustment to the snap
adjustment in WorkspacesView, and we'll need the preparation
steps but not the easing of the state adjustment.
Split preparation steps from zoomFromOverview() into a new method
prepareToLeaveOverview().
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1613>
As per the latest mockups, then horizontally snapping, the active
workspace should be highlighted. Because WorkspacesView clips to
allocation, we cannot simply scale up the active one. Instead,
scale down the inactive ones.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1613>
Synchronizing the actual geometry while animating from / to the overview can
break the animation. Let's prevent that. This code will go away soon anyway,
but to not lose bisectability, it's better not to leave it misbehaving until
then.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1613>
When vertically snapping, WorkspacesView currently allocates workspaces
side-by-side, then applies an extra step of translation to center to
the active workspace. This extra step, however, gets in our way because
now we need tighter control of the workspaces positions in allocation,
in order to properly interpolate them.
Move the translation of workspaces to the allocation code itself, and
remove the extra translation step.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1613>
Currently, WorkspacesView positions each workspace on a
per-page layout, each page with the allocated width and
height of WorkspaceView. This layout doesn't work well
with horizontal workspaces.
Layout workspaces side by side, instead of per page. The
layout is influenced by a "fit mode", which reflects the
different behaviors exposed in the mockup. This fit mode
represents whether a single or all workspaces will fit
available geometry.
The single fit mode is always used for now. Next commits
will make it switch to the all fit mode when in the app
grid state.
The translation_{x,y} also needed to reflect the switch to
a side-by-side layout, and use the geometry of the workspaces
to determine the offset. Notice that, when the fit mode is ALL,
there's no translation applied.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1613>
Nowadays gjs allows to omit get/set accessors for read-write properties,
and will define reasonable defaults in that case. In many cases we don't
need anything more than the default handling, let gjs handle those props.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1611>
The app grid itself now is horizontal, and is displayed beneath
workspaces, above the dash. This makes the indicator animations
out of place, as they're not coming from the edge anymore.
Use PageIndicators for both FolderView and AppDisplay.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1629>
The new window preview overlay requires getting the app icon for a
window from the window tracker when it gets initialized. The window
tracker listens for the same 'window-added' signal on the MetaWorkspace
that the gnome-shell Workspace listens for to add the window preview.
The window tracker however reconnects all its signal handlers whenever
the number of workspaces changes, which means that its signal handlers
get called after the ones in Workspace ones. So by the time the
'window-added' handler in Workspace is called, the window tracker does
not have an app associated with the window.
To fix this ensure that all window related signal handlers in Workspace
are run after the ones in the window tracker.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3656
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1625>
Currently, there's one animation for the whole canvas. While it looks fine
with just one screen, it causes windows to move between screens when
switching workspaces. Instead, have a separate animation on each screen,
and sync their progress so that at any given time the progress "fraction"
is the same between all screens. Clip all animations to their screens so
that the windows don't leak to other screens.
If a window is placed between every screen, can end up in multiple
animations, in that case each part is still animated separately.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1213
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1326>
Currently, the workspace swipe transition only has one workspace in each
direction. This works until you try to do multiple swipes in quick
succession. The second swipe would continue the existing transition, which
only has 2 or 3 workspaces in it, and will hit a wall.
To prevent this, take all workspaces and arrange them into a column or row,
depending on the layout, and use that as a transition.
For the transition that happens when focusing a window on another workspace
(for example, via Alt+Tab), still use only two workspaces instead of all of
them.
Since we don't support layouts other than single rows/columns anymore,
diagonal transitions aren't supported anymore, and will be shown as
horizontal or vertical instead.
Since nw alt-tab and gesture transitions are different, don't allow to do
both at once, that is, disable swipe tracker when a programmatic transition
is going. This will also conveniently cancel a gesture transition if a
programmatic one is initiated while a gesture is in progress.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2612
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1326>
In future we will need to use window clones to better support multiple
monitors. To avoid having to hide every window, show wallpapers behind
the workspace transition: one per monitor.
Put the wallpaper into a separate class right away, later it will be
useful to make the animation per-monitor.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1326>
Simplify the code a bit. The workspace group is relatively self-contained,
so split it from the general animation. Reimplement _syncStacking().
This will help a lot later, with workspace strip and multi-monitor support.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1326>
We always request a natural width based on the maximum thumbnail scale,
but may very well use a smaller scale when allocating. This currently
results in thumbnails being off center, fix this by distributing any
extra space evenly before allocating thumbnails.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1620>
Accessing GObject properties from JS has proven to be quite slow because
of the JS->C->JS roundtrip involved. With the WindowPreview this
actually has an impact since we're accessing those properties very often
while creating new layouts.
So cache the boundingBox and the windowCenter properties of the
WindowPreview using a this._cachedBoundingBox JS object. This might
speed up opening the overview with lots of open windows significantly.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1617>
Make computeScaleAndSpace() return an array including scale and space so
we no longer have to access the layout object from outside.
With this we also no longer need to set layout.space, since only the
scale property is needed in computeWindowSlots().
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1617>
Start cleaning up the whole mess around the layout object a bit and
return a new object in the LayoutStrategies computeLayout()
implementation. This object is supposed to be opaque to the API user and
will only be passed to the layout strategy.
For now, keep setting a few things on that object from outside, we'll
clean that up later.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1617>
Only keep computeLayout, computeWindowSlots, computeScaleAndSpace and
the contructor in the superclass, the rest is actually layout specific
and won't apply anymore when we introduce the new vertical layout
strategy.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1617>
Move the background to the Workspace class by introducing a new container
called WorkspaceBackground, which handles clipping the background to the
workarea.
Move the click action from WorkspaceDisplay into each workspace.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1599>
When the original animation was implemented, workspaces would only
ever be added at the end. We therefore got away with not having a
separate EXPANDING stage corresponding to the existing COLLAPSING
one when animating out.
Since support for creating in-between workspaces via DND was added,
this is no longer the case. And now that the thumbnails are centered,
the jump is quite noticeable.
Address this by adding new transitional states, so that we can
expand new thumbnails before scaling them in.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1609>
Make the slide property control the workspace scale, so that new workspaces
scale up, and destroyed workspaces scale down. The scale is done horizontally,
and only slightly vertically, as per design direction.
Rework the state tracking mechanism to remove the COLLAPSING state, since there's
no split between sliding out and collapsing anymore. Also remove the corresponding
'collapse-fraction' property from WorkspaceThumbnail.
Make ThumbnailsBox.vfunc_get_preferred_width() consider the slide-position property.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1593>
There are situations where MetaWorkspaceManager and ThumbnailsBox disagree
on the number of workspaces, for example when animating them out. It's more
important to follow the visible number of workspaces while they're updated.
Make vfunc_get_preferred_width() and vfunc_get_preferred_height() use the
current number of workspace thumbnails to calculate their sizes, instead of
MetaWorkspaceManager's n-thumbnails property.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1593>
ThumbnailsBox currently allocates each workspace thumbnail using their
porthole size, and scales them down using scale-x and scale-y. This is
slightly problematic since it doesn't allow for properly styling these
thumbnails through CSS.
Rework ThumbnailsBox to allocate workspace thumbnails at their actual
sizes, and scale down the '_contents' actor inside WorkspaceThumbnail.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1593>
Allocate workspace thumbnails horizontally. This requires introducing code
to handle the RTL direction. Do a small rewrite of the DnD hover method to
be simultaneously simpler and easier to follow, and work correctly on RTL.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1593>
This is now all centralized in the apps page, so move the workspaces
thumbnails to ViewSelector's apps page. This allows us to remove
all the slider controls too, since they're now unused.
The transition between showing the workspaces, and the app grid, is
based on the most recent mockups: scale and move it down, and fade it
out.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1593>
Now that there's only a ACTIVITIES and a SEARCH page, the old method of handling
keyboard tabbing (extra parameters to ViewSelector._addPage()) limits what we can
do.
Manually set up the Ctrl+Alt+Tab support for each element.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1593>
Add them both in a StBoxLayout subclass with a vertical layout. This
new ActivitiesContainer class already contains an adjustment controlling
the transition between workspaces and app grid states, and althought it
is internal to it, it'll be easy to integrate with gestures in the
future.
Notice that AppDisplay is added before WorkspacesDisplay. That's because
we want the paint order to paint WorkspacesDisplay on top of AppDisplay.
Switch the ViewsPage enum to call this page ACTIVITIES, and adjust the
only caller in OverviewControls to it. At last, rename '_appsPage' to
'_activitiesPage' to also reflect the name change.
The usefulness of organizing this code in pages is lost here, but this
is a transitional state, and pages will be removed in future changes.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1593>
This is the same color that the Dash currently has, except
it isn't transparent.
The reason for this change is that the app grid coming from
the bottom and passing below the Dash looks odd with the
transparency there.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1593>
Only the area used by favorite apps can be used as drop targets, it
is not possible to add new favorites between the running apps at the
end. While that behavior makes sense, it is currently impossible to
distinguish the two areas with confusing results.
Address this by adding a visual separator between favorites and
running apps.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1606>
When we display the hint string for e.g. (or swipe finger), the login
box gets pushed up. This is leftover from older styling and should be
removed. The padding-top is unnecessary and can also be removed, so just
remove the whole line styling login-dialog-message-hint from the
stylesheet.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1582>
WokspacesDisplay simply remaps the scroll direction into the next
workspace, but that doesn't account for the new horizontal layout.
Scroll horizontally on horizontal layouts when scroll direction is
on the vertical axis.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1603>
The scroll adjustment's upper value corresponds to the number of
workspaces, not to the last workspace index. We want the latter
when mirroring the layout in RTL locales, so subtract 1.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1598>
Now that apps either appear in the dash or the app grid, it makes
sense to allow DND between the two components to add and remove
favorites.
Currently this only works for adding items to the dash, update the
app grid code to also accept drops from the dash.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1594>
We use a custom actor to make sure that the show-apps button remains
visible even when there's not enough space to show all icons.
We can achieve the same result with much less code, by using a custom
BoxLayout layout manager for the icons to override the minimum width.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1592>
With the transparent top bar in the overview, constraining to the
primary monitor's workarea causes the (now visible) area beneath
the top bar to not have the darker background, which causes a visual
discontinuity in the layout.
Don't constrain to the primary monitor workarea.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1590>
The code previously was using CSS to define row/column spacing and
padding which was combined with a subicon size computed in code relative
to the requested icon size.
In smaller icon sizes it was possible for the CSS spacing+padding + the
size of the two subicons to exceed the requested icon size. This then
would lead to the label being pushed down for app folders compared to
other icons.
Another more severe issue caused by this would happen if the first item
in an icon grid was an app folder. Then the calculation for the maximum
allowed icon size could be off, leading to all icons in the grid
becoming smaller than actually necessary.
This commit changes this to use homogeneous row and column layouts to
evenly distribute the remaining spacing instead of using a fixed CSS
value.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3069
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1581>
This is some leftover from code that was used to keep track of volumes
added/removed while the screen was locked before the move to a
components system in 2a800e4c. All that the remaining code does is
filter devices from an empty list.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1579>
Now that the Dash is horizontal, the popup menu of the Dash icons must
show up, instead of left/right.
Make AppIcon.popupMenu() receive an optional parameter with the side
to show the menu, using St.Side.LEFT as default. Override this method
in DashIcon to always pass St.Side.TOP.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1559>
And move it to the bottom of the overview. Change the height-based calculation
of the icon sizes to be width-based. Put the DashFader in a vertical box, and
make all corners of the Dash equally rounded.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1559>
Like the mutter 40.alpha.1.1 release, we missed adjusting to a
GSettings schema move from g-s-d to gsettings-desktop-schemas,
resulting in an abort on startup with the latest released
gnome-settings-daemon.
Between the GTK4 port and the latest GTK4 version, calling realize()
on a newly created window to force its surface to be created stopped
working.
So instead, wait for the window to get realized regularly to set its
parent.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1574>
The shader code currently only accounts for padding for the
bottom and right fades, but not for top and left.
As a result, we only fade the right edge when swiping through app
picker pages, whoops.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1569>
With the previous preparations in place, it is time to take the plunge.
As both the app and the portal use the same small library for handling
external windows, port everything at once to avoid the hassle of building
and installing two versions of the library.
With the portal using GTK4 now, all extensions must port their preference
widgets as well.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1495>
We currently use separate frames for the details expander and the
expanded details. That layout works as long as frames are boxy (as
in the default GTK3 style), but breaks down with rounded corners
(as in the default GTK4 style).
In order to work with either style, adapt the layout to use a single
surrounding frame and appropriate borders as separator.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1495>
GTK4 will remove the GtkHeaderBar:title property, so stop using it
and set the window's title property instead, as that's what headbars
use in both GTK3 and GTK4 unless explicitly overridden.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1495>
There's little point in setting properties to their default value,
so stop doing that.
(GtkFrame:shadow-type actually defaults to "edged-in" rather than "in",
but all types other than "none" are treated the same nowadays)
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1495>
Unlike in previous GTK version (or Clutter), destroy() no longer
breaks reference cycles but just releases the reference held by
GTK itself.
So any reference we hold - either the explicit property or any signal
handlers that bind the window as `this` - prevents the window from
being disposed when closed, and the application won't quit.
Work around this by explicitly running dispose() on the window when
it is removed from the application.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1495>
GTK4 will remove the GtkHeaderBar:title property, so stop using it
and set the window's title property instead, as that's what headbars
use in both GTK3 and GTK4 unless explicitly overridden.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1495>
The overview is using a heavily darkened background image nowadays.
Since the contrast provided by this is always good enough, this makes it
possible to always have a fully transparent panel while showing the
overview.
So change the theme to always make the panel fully transparent while the
overview is shown. The duration of the animation for that is 250ms
because that's the duration of the show and hide animation of the
overview.
Also add special handling for the high-contrast theme, where we always
make the panel opaque.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1397>
The SHADE_ANIMATION_TIME variable sets the duration of the animation of
the background shading that is done when showing the overview. As
explained in the code-comment, that value must be smaller than the
animation time of the overview.
Now since we're going to start animating the background color of the
panel when showing the overview and we're going to use the overviews
animation time for that, we want to make sure the shading of the
background image and the animation of the panel are kept "in sync",
otherwise the transitions would look bad.
So slightly increase the value of SHADE_ANIMATION_TIME to 240 (the
overviews animation time is 250) to make sure those happen in the same
timeframe.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1397>
The current way of indicating focus of elements in the panel does not
work very well with a fully-transparent panel, a line at the bottom of
the panel doesn't make too much sense if there is no real panel, but
only the text and icons.
To make the indicators look better in this case, switch to a pill-shaped
background color to indicate the focus of items in the panel.
For this to look good, there has to be a small black border above and
below the background, this also requires increasing the height of the
panel (from 1.86em to 2.2em) for visual purposes.
Also, since we now no longer need to color the lower bottom of the
panel, we can remove the custom drawing code for the border of the
panels corner, so do that.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1397>
The activities button doesn't have an icon, which makes its horizontal
padding appear a bit smaller than the padding of most other items in the
panel.
We're going to indicate hover and focus of items in the panel using a
pill-shaped background color, which means the padding of those items
will get more visible. So give the activities button a special treatment
and slightly increase its padding to make sure the new indicator will
look good.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1397>
Mutter added some additional rules, for instance to enforce proper
capitalization style in commit messages. That's a good idea, and
now that adding rules is easy, let's adapt them to gnome-shell.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1544>
Currently the hint reflects the `active` state, which effectively
corresponds to the screen blank. That's a bit surprising considering
the name, plus the `active` state is already exposed by the ScreenSaver
D-Bus interface for anyone interested.
It seems reasonable that the `LockedHint` property reflects the lock
state, so change the handling to do exactly that.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/351
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1561>
We want to either handle a scroll event ourselves, or delegate it
to the swipe tracker. What we never want is StScrollView's default
handler that doesn't have any knowledge of pages, so disable it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1560>
Even if they're in the end of the list. So far we've managed to not be affected
by this bug because until GNOME 3.38, workspaces didn't have a background, and
there was no way to navigate to these leftover workspaces, but with the proposed
overview changes for GNOME 40 it'll be very much visible.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1560>
When handling all scroll directions, it is imperative to ignore emulated
events. Otherwise we may get the wrong scroll direction, e.g. when natural
scrolling is enabled.
Ignore pointer emulated events in WorkspaceDisplay._onScroll().
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1560>
All subclasses of BaseAppView now are horizontal, thus we
don't need to deal with the vertical case anymore.
Remove the corresponding parameter from the BaseAppView
constructor, and move the StBoxLayout that both AppDisplay
and FolderView have in common into the base class.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1554>
The man pages don't change very often, but draw in both docbook and
asciidoc. The latter is particularly problematic, as some distros
still ship only a python2 version of the tool.
Address this by generating the man pages at dist time, and including
the result in the tarball.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1553>
The man page hasn't been updated in years, so the list of options ended
up being quite outdated. Most notably it's missing all wayland-related
options.
Remove obsolete options and add all the missing ones so that the list
is up to date again.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1553>
We already use asciidoc for the gnome-extensions man page, while
the main man page is generated from docbook XML. The former is a
much friendlier source format, so use it for both man pages.
Hopefully the plain text format encourages updates, to prevent the
page from getting as badly out of sync again as it is currently.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1553>
Turns out that shell_screenshot_screenshot_area was affected
by the same issue that shell_screenshot_screenshot used to have.
Adapting code changes from commit id c09be8b0:
"screenshot: Grab screenshot during paint on X11" fixes it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1549>
While most secrets are serialized as individual settings with a string
value, all VPN secrets are serialized together as a string dict which is
the value of a single setting. Incorrect serialization causes VPN
secrets to not be remembered by NetworkManager.
This commit adds a new method that allows adding secrets as VPN secrets
specifically such that they can be correctly serialized.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1535>
I messed up and released 40.alpha at the same time as 3.38.2, when it's
supposed to be in January. In order to re-align with the schedule, change
the upcoming version to 40.alpha2 so we don't have to skip a release and
will be back on track in time of 40.beta.
Recent commit [1] added a strong light border around user avatar
icons, in accordance with design mockups.
As a probably unintentional side-effect, the border was also added
around the symbolic fallback icon, which is displayed whenever the
user avatar is not available. This doesn't work well with the current
design, as the strong border makes the subtle fallback icon
background indistinguishable. Additionally, it doesn't match the
design mockups for the symbolic avatar icon [2].
Correct this by adding a style class for when avatar image is used,
and apply the border only for that case.
[1] 498710c2ec
[2] https://gitlab.gnome.org/Teams/Design/os-mockups/-/blob/master/lock-login/username-based-login.png
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1490>
The default sizing for user-icon style was not defined in the theme,
but it simply used the default Avatar iconSize from UserWidget.js.
This didn't work with the current fallback avatar styling (i.e. when
the avatar icon is not set for an user account, and a symbolic icon
is displayed in its place), as the fallback StIcon was not scaled
to align inside the circle shaped user-icon properly.
Define the user-icon and corrected fallback StIcon sizes in the
stylesheet to correct this. The default 64px user-icon size is based
on default UserWidget.Avatar iconSize. The sizing for the StIcon is
taken from `.user-widget.horizontal .user-icon` styling, which uses
the same base icon-size.
Additionally, the special `.user-widget.horizontal .user-icon`
styling is removed, as it is now redundant.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1490>
What the blur shader does is going n_steps in each direction (e.g. in case
we're in the horizontal pass that means left and right direction), sampling
the adjacent texels of the texel we're currently blurring. That means
n_steps actually is the amount of texels we're sampling in one direction,
not in both directions.
Make n_steps match what the blur shader does, and rename it to sampling_radius
to match what it really means. Do that for both st-theme-node-drawing.c and
st-private.c
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1542>
This new ClutterOffscreenEffect vastly simplifies subclasses
by allowing them to hand the parent class a CoglPipeline to
use.
Override the create_pipeline() vfunc and return the (cached)
pipeline. Remove the paint_target() override and the now
unnecessary texture size fields from the structure.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1350>
We might not be able to directly paint the stage to an offscreen, if
there currently is a fullscreen unredirected window. To make it possible
to take a screenshot in this situation, disable unredirecting, queue a
frame, and take a screenshot after having painted that frame, before we
go back being unredirected.
Don't do this on Wayland because it's a waste.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1453
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1534>
With ClutterBlurNode available, we can remove our own implementation
and delegate the blur shader and framebuffers. This simply replaces
the pair of layer nodes (vblur and hblur) with a ClutterBlurNode,
and removes all dead code.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1528>
When checking for a suitable icon size, Dash currently checks which
of the hardcoded icon sizes is smaller than the calculated available
size.
On some circumstances, however, when the calculated available size
is exactly equal to the hardcoded icon sizes, Dash selects a smaller
size. This cascades (the next icon size is exactly the smaller size,
etc) and ends up with always Dash selecting smallest size available,
even with plenty of available space.
Check if the calculated available size is smaller or equal to the
hardcoded icon sizes.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1533>
$CI_COMMIT_REF_NAME can be a branch name or a tag, depending on the
pipeline, but our checkout script only deals with the former at the
moment.
Address this by rather than looking for a remote branch name, just
try to fetch the ref like we do for merge request pipelines.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1529>
We are currently not very good at communicating what's going in,
in particular for non-merge request pipelines where the output
is usually just "Using origin/master instead" (instead of what?).
Improve this by consistently communicate what we are looking for,
whether we found it, and what we end up doing.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1529>
Port the blur effect to the new ClutterEffect.paint_node() vfunc.
Update the function names to match what they do, e.g. "apply_blur()"
now creates the blur subtree and thus was appropriately renamed to
"create_blur_nodes()".
There are 3 subtrees that can be generated by the blur effect:
1. Actor mode (full subtree; no cache)
Root
|
|
Layer (brightness)
|
Layer (horizontal blur)
|
Layer (vertical blur)
|
Layer (actor)
|
Transform (downscale)
|
Actor
2. Actor mode (partial subtree; cached contents)
Root
|
Pipeline
(final result)
3. Background mode
Root
|-----------------------
| |
Layer (brightness) Actor
|
Layer (horizontal blur)
|
Layer (vertical blur)
|
Layer (background)
|
Blit
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1339>
Updating scroll position may have significant side effects, e.g.
switching workspace; this should never happen during allocation, as
we're in the middle of painting a frame. So, put it in an idle callback
if we're doing it from an allocation to have the side effects happen the
right time.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1527>
Clarify the comments on ConditionEnvironment= by mentioning that a
ConditionEnvironment= line must be located in the [Unit] section.
The comments suggesting using ConditionEnvironment= themselves are
in the [Service] section, which implicitly and wrongly suggests
that ConditionEnvironment= could be defined right there as well.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1472>
Screen magnification is the compositor's business, not that of "random"
unprivileged tools. And for cases where a more specialised behavior is
wanted, an extension likely does a better job than a consumer of the
D-Bus API.
In addition to that, exporting the interface has been broken for an
unknown time, because the object that holds the implementation isn't
referenced and thus ends up being garbage collected, whoops.
And last but not least, this gets rid of the last public D-Bus name
that isn't clearly in the system namespace (org.gnome.Shell,
org.gnome.Mutter, org.gtk).
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3452
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1523>
This is a relict from the pre-3.0 days, when it was common to
replace a running GNOME 2 session with gnome-shell. There has
been no good reason to claim the name for many years, time to
drop it.
If someone really wants to run gnome-panel alongside the shell,
they probably know what they are doing. Or cannot be helped anyway.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1521>
Simplify the opacity dance to simply setting it to the initial value
before animating (0 when animating in, and 255 when animating out),
and to the final value after the spring animation is done (vice-versa).
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1518>
To run the spring animation, IconGrid uses the transformed position and size
of the icons. This works okay when IconGridLayout doesn't need to update the
icon sizes, but looks bad when IconGridLayout selects a different icon size.
Wait for the icon sizes to be recalculated, and the icons beallocated, before
running the spring animation. If no icon size update is pending, run the spring
animation directly.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1518>
In the future, both AppDisplay and FolderView will be horizontal, and thus
using the orientation to determine whether to use animated indicators won't
be enough.
Use a different flag to control that, and make FolderView not use animated
page indicators.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1518>
SwipeTracker connects to signals of the stage, but doesn't disconnect on
destroy, leaving them hanging and potentially running callbacks for
destroyed objects.
This is visible when removing a folder by dragging all icons out, and
running the swipe gestures, which will produce a bunch of warnings.
Explicitly destroy, remove, and disconnect the swipe tracker.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1518>
Make it subclass ClutterActor, since we don't need any of StWidget's
features. Pass the source actor of the bind constraint in the
constructor, and remove the extra method to set the source actor.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1518>
ControlsLayout is a tiny layout manager whose only purpose
is emit "allocation-changed" after allocation. This signal
was listened to update the workspaces actual geometry.
However, since d66cd0d206, ControlsManager doesn't listen
to this signal anymore, rendering the class useless.
Remove ControlsLayout.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1518>
In some styles the top or left sections of box-shadows would go missing
even though they had non-zero thickness. This was because the inner
local coordinates could become very slightly negative and were then
incorrectly judged to be invisible.
Negative coordinates should not be ignored because that's where the
entire top/left sections of shadow are meant to exist. It's only the
sections of shadow with zero thickness that we should skip.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1417>
How and if notifications are shown is controlled by NotificationPolicy
objects. But ever since 098bd45, only notification daemon sources or
notifications associated with an app are hooked up to GSettings.
The hardcoded default policy for built-in notifications (including
those provided by extensions) arguably made sense back then, but
now that the main setting has been rebranded as "Do Not Disturb"
and is exposed prominently in the calendar drop-down, following
GSettings is a better default.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3291
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1511>
When selecting the best icon size for the available area, we
iterate from the biggest icon size to the smallest one, and
stop when finding a size that fits the available area.
However, the 'bestSize' variable is only updated when the
available area is positive. This is problematic in super bad
cases like when none of the icon sizes actually fit the availabe
area, which was hit with a previous iteration of this branch.
Make sure to update the best size while iterating, so that the
smallest size is selected even in such bad cases.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1510>
Use the Clutter.ActorAlign.FILL alignment by default, which
expands the grid until max-row|column-spacing is hit. This
was the behavior we originally wanted for the icon grid, and
it's finally being realized.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1510>
This is a new property to control the padding around each page,
as opposed to the padding around the entire container.
Following the original design of IconGridLayout [1], changing
the page-padding property doesn't trigger relayouts; the container
is responsible for queueing a relayout appropriately.
[1] 3555550d5e
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1510>
Plain classes are private to their file, so accessing them from
another module results in the following warning:
That property was defined with 'let' or 'const' inside the module.
This was previously supported, but is not correct according to the
ES6 standard.
Fix by assigning the class to a public variable instead.
(Eventually switching to ES6 modules with proper imports/exports will
fix this as well)
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1512>
Not checking for this would result in `clutter_actor_add_child`
failing, but StBin keeping a copy in `priv->child`. So later on,
`st_bin_remove` would never be called on it and this assertion
would fail and crash the whole shell:
```
static void
st_bin_destroy (ClutterActor *actor)
{
StBinPrivate *priv = st_bin_get_instance_private (ST_BIN (actor));
if (priv->child)
clutter_actor_destroy (priv->child);
g_assert (priv->child == NULL);
```
By disallowing spurious `st_bin_set_child` calls we now prevent StBin
from entering such a corrupt state and the above assertion won't fail
anymore.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1507>
The grid icons in the search results page doesn't expand to
acommodate the multiline label, resulting in the multiline
label to overflow behind the list search results. However,
after 548d3b62d, it was possible to trigger this behavior
with keyboard focus.
Don't update multiline labels for search results.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1509>
Adding children to the WorkspaceLayout without calling addPreview() is
not supported, so let's log an error in case that happened.
We also have to allocate that child an empty ClutterActorBox, otherwise
Clutter will complain loudly.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1481>
Clutter expects actors overriding the allocate vfunc to allocate all
mapped children of the actor, otherwise bad things happen.
So make sure we actually allocate all our visible children in our custom
allocation functions, and since we don't want to give them a real
allocation, just pass them an empty ClutterActorBox.
It would be nice if we had a way to hide children during the allocation
process where no relayout is queued like gtk allows with
gtk_widget_set_child_visible(), then we could avoid those weird empty
ClutterActorBoxes.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3098
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1481>
When logging out or terminating gnome-shell, mutter will unmanage all
open windows, triggering the window-close animation in gnome-shell and
very quickly after that emitting "kill-window-effects". That means we'll
call _destroyWindowDone() to cleanup our animation data, but at this
point the MetaWindow of the window is already gone, so we get an error
that get_meta_window() returns NULL.
Fix that by checking whether get_meta_window() returned NULL and if it
did, don't access the window.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2018
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1483>
only/except keywords where deperecated in favor of rules.
Since we started using GNOME/gnome-shell!1492 it introduced
a second pipeline being run for each commit.
Detached pipelines are the only way to access CI_MERGE_REQUEST_*
variables, and if we disable normal pipelines you will need to
create wip/spam MRs in order to run the tests.
This reworked rules makes it so, the normal pipeline needs manual
interaction to be started, and the detached/MR pipleines is always
run.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1503>
The image registry must be enabled for the CI to work, as the container
image from the upstream registry is placed (as a reference, more or
less) in the local registry.
Recently, ci-templates got a bit more helpful if this happened, and will
fail up front and generate a JUnit report with a message describing the
issue.
Update to this version.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1505>
This rebuilds the automaticaly whenever the image tag changes. Whenever
something in the image needs to change, alter the installation script
and change the tag to the current date.
This removes the -s (strict) argument from js68, as it doesn't exist in
js78.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1492>
Instead of making sure there is a reference to a bug or merge request,
make sure there isn't. The reason for this is that marge-bot will always
append a merge request URL in the end of the commit message.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1491>
We have been transitioning to the new coding style for a while now,
and there has been reasonable progress. So hopefully it is not too
intrusive at this point to enforce non-legacy style for all lines
that are changed in a merge request. If it turns out to be still too
annoying, we can always reconsider and turn off the additional job.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1497
This is unnecessary hard in shell when compared to a proper programming
language. It becomes even easier with a node-js script, as that gives us
access to the underlying ESLint module rather than just the CLI interface.
Besides that, node-js has the added benefit that we don't need to add
more dependencies to the CI image.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1497
If the adapt to size occurs after the grid page has been changed the
page is set to zero. This patch just keep the current page with the same
value that it has before.
Fix https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3388
gjs improved its default property getter/setters, and as a result it
is no longer possible to set read-only properties.
Add proper getters (backed by private properties) to fix the resulting
errors.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3203
`shouldShowApp()` is called in `_addFavorite`, so adding a favorite when
this isn't true won't work. Also, it seems when this is false, favorites
that do exist won't be shown anyway.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3342
When initializing the shell, we create the magnifier, and (normally)
let it disabled. This still toggles cursor visibility on, which is
not right since there's other considerations to take during
initialization.
Only do this after actual changes to the magnifier state, so
initialization is left unperturbed.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1486
When support for notification sounds was added, it made some sense
to keep the 'enable-sound' setting independent from 'show-banners'.
However that changed when 'show-banners' was rebranded in the UI as
"Do Not Disturb", as sounds are at least as disturbing as the banners.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2873
We sometimes add dialogs multiple times to the WindowPreview, for
example for modal dialogs we receive both the "window-added" and the
"window-entered-monitor" signal, which means we call
WindowPreview.addDialog() twice.
We handle that fine already in the WindowPreviewLayout and return NULL
in case the window already was added, so simply handle that NULL return
value and bail out of WindowPreview.addDialog() in this case.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1482
Most media players have a media player that shows the title of a song
and artists in the song. In those media players the title is
highlighted (bold text) and the list of artists is under the title.
Shell does the exact opposite in the player in the notification area.
Example media players: Spotify, Rhythmbox, GNOME Music
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1480
The background-size interactive test includes a test-case which uses the
ClutterActor::paint signal to hijack the painting of the actor. We're
removing that signal from Clutter, so remove that signal handler and
paint the outer border unconditionally to mark the boundaries of the
widget (the outer border actually never worked to force the cairo/cogl
path). To fix the test, change it to not paint a border on the inner
container in the useCairo=false case, which should make sure the cogl
path gets used.
Also remove the useless useCairo argument from addTestLine().
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1479
IconGridLayout uses the biggest minimum size to allocate its
children. Next commit will make app icons with long names show
not ellipsize on hover, and it is important that the icon itself
is able to follow that.
Use preferred size if it's bigger than the minimum size.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1477
When the icon area gets allocated additional space, we want the
icons centered rather than left-aligned. This may happen in locales
with long-ish translations for the title or buttons when only a
subset of possible icons is shown.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3307
Commit de610a13f1ad1e7e34d4b9a81df58d4da3693059 in mutter made it
impossible to access the actors last allocation after unmapping it,
this broke the scale-up/down animation when starting a drag.
Fix that animation again by saving the actors transformed size before
unparenting (and therefore unmapping) the actor instead of afterwards.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1475
The screen shield code listens for motion events on the stage
so that it can hide the pointer until the user moves the mouse.
Unfortunately, if the user never moves the mouse, the signal
handler connection gets leaked.
This commit makes sure the connection gets disconnected when the
shield goes away.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1459
The screen shield watches for motion events to know to display
the pointer when the user wiggles their mouse.
It checks for motion events by looking at the event type and
seeing if it is of type `Clutter.EventType.MOTION`. To do this
comparison it uses the equality operator (==). Using the equality
operator isn't considered best practice, because it can returns true
when comparing disparate types, if those types happen to be equivalent
after coersion.
From a code resiliance point of view, it's better to use the
identity operator (===), which requires both sides of the comparison
to be of the same type.
As a policy, any legacy code that gets changed or moved should be
switched away from the equality operator to the identity operator, if
appropriate.
This commit makes that change as prep work for a fix to that part of
the code.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1459
When using `Actor.ease_property` if the property starts with '@' and the
duration of the transition is zero (which may happen if the actor is not
mapped even if a non-zero duration was passed to `ease_property`), the
impl will try getting the actual target object where the property should
be set.
This works fine for most cases but it currently throws an error when
passing '@content.*' properties. Fix this by handling '@content' as
a property of `actor.content` (used by MetaBackgroundActor when
showing the overview).
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1461
The panel corners try to match their style to the buttons closest
to them. In order to make sure the corner styles stay in sync with
their neighboring buttons, they connect to the style-changed signals
of the buttons.
In order to make sure the style-changed signal handler isn't leaked,
it gets disconnected when the button is destroyed.
Unfortunately, the destroy signal handler connection itself gets leaked!
This commit ensures the destroy signal handler gets disconnected any
time the neighboring button is re-determined.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1460
With the new versioning scheme, the previously-minor version gets
shifted up to major, and unstable releases are marked by non-numeric
"versions" rather than uneven numbers. Reflect that in the extension
version check.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1456
Clutter nowadays omits reallocations when only the stage position
changed, that is when the allocation relative to the parent changed.
As a result (apart from better performance of course), workspaces
in the overview may now end up with an outdated "actual geometry"
in case the overview moved to a new primary monitor (of equal size
as the previous one).
Work around that by emitting a signal from the overview on allocation
changes, and use that to update the cached geometry.
We can revert that change once workspaces become part of the regular
overview hierarchy.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3211
When dragging icons out of a folder dialog, there is a very peculiar
combination of steps that may break GNOME Shell:
1. Open an app folder dialog
2. Start dragging an icon to outside the grid
3. Wait until the popdown animation starts
4. Before it finishes, drop the icon
5. See the warnings / crash
That's caused by the source icon being destroyed after the delayed
move timer starts, and before it finishes.
Protect against the source icon being destroyed before the delayed
move timeout triggers by connecting to the 'destroy' signal and
removing the timeout on the callback. Use a single field, called
'_delayedMoveData', to store all data related to delayed moves.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1447
When dragging an icon outside of a folder dialog, there's a small delay
before the dialog pops down. If the icon is dropped during this delay,
the drag is cancelled, and the icon continues to be in the folder.
However, this behavior turned out to be problematic, and it was a common
point of failure that throwing icons outside folders wouldn't work.
Remove the icon from the folder when dragging it to outside the dialog.
Related: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3092https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1447
At the end of BaseAppView._clearAnimateLater(), the '_grid' actor's opacity is
set to 255. As it turns out, _clearAnimateLater() is called, among others, by
vfunc_unmap(). However, unmapping is part of the destruction process, and at
the time it is called, '_grid' is already destroying, which makes GJS complain
about accessing an invalid object.
Don't change opacity on BaseAppView._clearAnimateLater(), and instead move it
to the couple of places outside vfunc_unmap() that call it.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1447
After dragging an icon to inside a folder, we do not save the grid layout,
leaving the icon's position stored when it actually isn't there anymore.
Fix that by saving pages whenever folder apps change.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1447
To delete a folder, FolderView needs to reset all keys under that particular
folder's GSettings path. That generates 5 'changed' signals, all of which
end up calling AppDisplay._redisplay(), which is costly.
Don't emit 'apps-changed' when deleting a folder.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1447
If you try and drop an icon that's in the same page, but before the
drop target, it'll be one position ahead of where it should be -
because we just removed one icon before the target position.
Adjust the final position of the to-be-created folder.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1447
This new public API moves items without removing and readding
them, which allows us to avoid some tricky behavior. Noticeably,
following the original design described at 3555550d5, the new
IconGridLayout.moveItem() method does not call `layout_changed`.
This is done by IconGrid itself, queueing a relayout.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1447
When adding an item to the app grid, the item is added to
a sorted array. This is calculated by adding all visible
items in pages before the one being modified. Future commits
will need this to move items without reparenting them, so
factor this code into a separate function.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1447
This was missed in commit 96f63b08c2 when splitting the combined
layout+scrolling method into allocation and translation.
Add it back to prevent windows from other windows leaking into view
during the transition.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3208
We couldn't clip workspaces views during the overview transition
when we used the "porthole" approach, but as view's allocation
now always matches the expected visible area, we can just apply
the clip unconditionally.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3208
Commit ff3d32dd18 added a custom DashIcon subclass that disables
all DND methods from ancestors, including canceling the context
menu timeout and emitting the overview's item-drag-begin signal.
All we want is opting out of the parent's scale-and-fade behavior,
so override those methods instead.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3209
Currently the width of the calendar column is solely determined
by the calendar, while other elements are ellipsized as necessary.
While that is the desired behavior for the events-, world clocks-
and weather sections, we don't want to cut off the date in the
header. However switching to bold text made that more likely in
non-English locales or when using large text, so explicitly take
it into account for the width negotiation.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2230
The purpose of password peeking is to spot and correct errors;
the latter isn't possible when the entry is non-editable, so
we can hide the password again while authentication is ongoing.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3138
Just like the internal ClutterText, the icon actors are part of the
entry. It therefore makes sense for the icons to not react to clicks
when the entry itself is non-reactive; again, just like the text.
That behavior is also consistent with icons in GTK entries.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3138
BaseAppView not disconnecting from the 'app-filter-changed'
signal means parental controls may trigger callbacks on
a destroyed grid, which tries to access destroyed icons,
which spams the journal with stack traces.
Disconnect from parental controls when BaseAppView is destroyed.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1441
We split the search string into words using whitespace, while
GLib.tokenize_and_fold() splits on any non-alphanumeric characters.
That is, a valid search term like ',' will be tokenized as [], so
the original non-empty terms may get mapped to an empty array.
And as [].every() returns true for any condition[0], we end up
matching *all* system actions in that case. We want the exact
opposite and not return any results, so handle that case explicitly.
[0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/everyhttps://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3169
It's best to not mix transient indicators with (probably) permanently
visible items, so move the remote-access indicator (which also handles
screencasts now) to the position of the old screen recorder icon.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1438
Like `GtkAdjustment`, `StAdjustment:changed` is not emitted for the
`value` property except when changed with `st_adjustment_set_values()`.
Note this behaviour in the signal documentation
closes https://gitlab.gnome.org/GNOME/gnome-shell/issues/3147
A window preview's floating geometry is scaled down according to the
workspace's allocation, while the layout geometry is computed directly
for the available space.
For previews that maintain their real size in the layout geometry,
that scaling leads to a distracting size bounce when transitioning
between both layouts.
Address that by not allowing the scaled floating size to drop below
that layout size (which is at most equal to the unscaled floating size).
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2968
As per GSettings documentation, it is necessary to read a particular
key at least once before being able to connect to the corresponding
'changed::' signal.
Read the 'app-picker-layout' key before connecting to the changed
signal.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1428
It is wasteful to emit layout-changed when updating pages, because
the caller (AppDisplay) already has an updated state by the time
this is called.
Only emit 'layout-changed' if the GSettings notification doesn't
come from AppDisplay updating the pages.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1428
widget.get_effect(...) can return null while locking the screen, resulting
in a TypeError. In this situation the screen ends up black with a cursor
but never going to sleep, and moving the mouse brings the old screen
contents up but does not allow unlocking.
unlockDialog.js assumes that widget.get_effect will return non-null,
but other places such as getWindowDimmer in windowManager.js go out of
their way to be more careful.
[smcv: Add commit message, remove hard tabs, add missing semicolon]
Resolves: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3071
Bug-Debian: https://bugs.debian.org/968440
When promisifying async operations in commit 764527c8c, the
finish function for read_line_async() was sneakily changed from
read_line_finish_utf8() to read_line_finish().
That is, the call returns a Uint8Array now that requires an
explicit conversion to string.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1407
Since gjs moved to mozjs60, return values of int8_t arrays can
no longer be treated as strings. We originally made the conversion
conditional to keep working with the (then) stable gjs release.
That was two years ago and we require a more recent gjs nowadays,
so there's no good reason for keeping the old code path.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1407
(optional) is only valid for (out) or (inout) parameters (that are
marked as such).
However GError** arguments appear as throws="1" in the GIR anyway
instead of an explicit parameter, so we don't need any annotation
at all here.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1408
When the last item of an IconGridLayout page is removed,
the page itself is removed too. However, the indexes of
items of next pages are not updated, which mess up the
layout manager state.
Update the page index of the items at forward pages when
removing a page.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1406
While the performance framework was originally written to collect
performance metrics, driving the shell by an automated script is
also useful to ensure that basic functionality is working.
Add such a basic test, initially checking top bar menus, notifications
and the overview.
Eventually it would be nice to separate the automatic scripting from
gathering performance metrics, but IMHO that can wait until we switch
from gjs' custom imports system to ES modules.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1396
global.run_at_leisure() is used from automated scripts to schedule
a callback when the shell is idle. However since we moved away from
Tweener, animations are no longer taken into account; fix this by
marking transitions as "work" if the convenience ease() functions
are used.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1396
The original scripting framework was based on SpiderMonkey's
pre-standard generators, and was simply translated to the
corresponding standard syntax when updating it to work with
recent JS versions.
We can do even better by using the standard async/await pattern
instead of generators/yield.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1396
If the user's battery power is low, we should not check the checkbox to
install updates by default. Rationale: if the user's battery is not low,
it's very unlikely to run out during a normal system upgrade. Low
battery is defined as any level below 30%, matching our battery status
indicator.
We'll also change the battery warning to only display when battery is
actually low. However, we will still always warn on battery for full
system upgrades, since these are expected to take a long time.
Future improvement: it would be nice to make the checkbox insensitive
when on low power. However, I don't think we currently have a proper
style for insensitive checkboxes. I was unable to make it look good.
Lastly, note that I did not test this on a laptop. I tested this by
mocking the return values of _isDischargingBattery() and
_isBatteryLow().
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2717
A side effect of removing the action buttons in favor of a regular
submenu is that we are a lot less constrained by size. So instead
of lumping "Restart" in with "Power Off", make it a separate menu
item.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2202
We will split off restart from the existing shutdown dialog, and
instead offer it as a separate menu item in the session submenu.
But before doing that, make sure that the existing restart dialog
exposes the same feature set as power off.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2202
Much of St is undocumented, aside from input/output arguments. This is
no doubt because a lot of it parallels Gtk closely, but is worth
improving since many new programmers are not familiar with Gtk.
closes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2983
A recent Docker image update broke the test, as xgettext now prints
the following warning:
warning: a fallback ITS rule file '/usr/share/gettext-0.21/its/metainfo.its'
is used; it may not be in sync with the upstream
That is completely unrelated to what the test is meant to catch and
could be fixed by adding appstream to the image, but considering that
- the test didn't actually catch the last template string regression
- we no longer allow template strings in files that include translatable
strings (and enforce that with a CI job)
- as of gettext 0.20.2, the template handling really really is fixed
(we'll see)
let's remove the test rather than piling up more stuff in the container
image.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1399
This eliminates the need to wait for redraws, drawing cursors, and
stiching together cairo images in case the screenshot covers multiple
monitors.
All of that is now handled by mutter itself.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1383
This implements the "Alt" behavior for the "Reboot" button as outlined in
the design here: https://wiki.gnome.org/Design/OS/BootOptions
Note I've tried implemeting this with the AltSwitcher class from
js/ui/status/system.js first, but that puts the button in a St.Bin()
which causes the button to think it is the only button on the dialog
and makes it have rounded corners on both of its bottom corners.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/199
Immediately add buttons to the dialog instead of first building an
array of button-info structs.
This is a preparation patch for adding support changing the "Reboot"
button into a "Boot Options" button when Alt is pressed.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/199
The framebuffer we use for rendering shadows is scaled by the resource
scale, that means we also need to offset coordinates when translating
them to the framebuffers coordinate system.
So far we forgot to do that when translating the framebuffer using the
position of the actor, which lead to small rendering bugs of
text-shadows for actors allocated at non-zero origins. To fix that,
simply multiply those positions with the actors resource scale.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1390
Fix what is probably a copy-paste error and return false instead of a
CONTINUE DragMotionResult which is only meant for dragMotion events, not
drop events. This makes sure we don't create a folder when dropping an
app over the drag leeways of another icon.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1389
For more obscure network configurations, we need to launch the
corresponding Settings panel with additional parameters, so we
cannot simply launch the .desktop file.
However we can do better than spawning a command line: Control center
exposes an application action we can use instead, so the process is
launched with the appropriate activation environment and startup
notification support.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1385
This fixes an issue where the indicator can be out of sync until the
RfkillManager (used by it) properties change.
The problem is that multiple instances of the indicator will use
the same RfkillManager instance (getRfkillManager() returns a singleton)
that only guarantees to emit the changed signal in two scenarios:
when the D-Bus proxy connects and when the proxy properties change.
If by the time an indicator is instantiated the RfkillManager's D-Bus
proxy is already connected, that indicator would only sync its state
when the RfkillManager properties change.
Let's fix that by always syncing the state on construction - in the worst
case scenario the RfkillManager's D-Bus proxy won't have connected yet
and the indicator state will be temporarily out of sync but once it gets
connected the indicator will sync again with the correct state.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1386
To do this, we now wait for the start/stop job to complete. We also have
two targets in gnome-session to ensure that everything is working as
expected.
In order to start the services, we simply request the
gnome-session-x11-services-ready.target unit, and wait for it to become
available. To stop, we use the gnome-session-x11-services.target unit
which should stop all services in a way that is entirely race free.
This requires both gnome-session and gnome-settings-daemon changes to
work (which are in the corresponding merge requests).
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/895
Move the GNOME shell service file adapation for x11/wayland into the
target/service files. This means that the session definition can simply
pull in org.gnome.Shell.target, without having to care about whether it
is starting an X11 or wayland session.
Note that this currently requires fork'ing to do the test. This will
however not be needed in the long term when ConditionEnvironment becomes
available (see https://github.com/systemd/systemd/pull/15817).
We technically do not need to use template units. But doing so means
that the unit can be translated to the app id more easily (though it is
not yet completely clear how this should look like in the long term).
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/895
In general we want to move towards using reverse domain names for
systemd units. Doing this also means we have a consistent name between
desktop file and systemd unit, allowing us to create a generator that
pulls in the unit as defined in the sessions RequiredComponents.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/895
Move the screencasting into a separate D-Bus service process, using
PipeWire instead of Clutter API. The service is implemented in
Javascript using the dbusService.js helper, and implements the same API
as was done by screencast.js and the corresponding C code.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1372
If something started the service, but crashed before managing to make a
method call, we'd end up with the service running indefinitely. Fix this
by queueing a shutdown check immediately on startup.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1372
If a remote access is marked as a recording, visualize it the same way
as a built in recording. Also don't stop it if there is an actual screen
sharing going on, so that one can use a plain "recording" while still
disabling what is an actual screen sharing.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1372
While we do have some handling for removing the active menu, it has
been a no-op for years. The bit that we really care about from the
PopupMenuManager's point of view is the existing grab though. Drop
that instead of calling _closeMenu() directly; ungrabbing will still
call the method indirectly, and it will still be a no-op :-)
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3022
At the moment, if a user switches to the login screen vt,
the login screen fades in whatever was on screen prior, and
then does a reset.
It makes more sense to reset first, so we fade in what the
user is going to interact with instead of what they interacted
with before.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2997
On X11, clients can grab keyboard on pointer (for example for popup
menus), and as a result the pushModal() call when opening the overview
fails.
However when the hot corner was used to toggle the overview, we still
show the ripple animation in that case, which is confusing as the action
did not actually happen.
Fix this by only showing the ripples if the overview is animating after
calling toggle(), as that should be a reliable indication of whether
the call was successful.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3005
As backgrounds are cached, it is possible that we never emit the
'loaded' signal added in commit f386103bc1. We are relying on the
signal though, so do the same as Background and emit the signal
from an idle if the background was already loaded.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1371
Currently, the login animation can occur before the user's wallpaper has
been loaded. When this happens, we wind up displaying a solid blue
background for half a second or so before the proper background is
displayed. This looks jarring and bad. It's great that we can start
GNOME quickly, but starting up before the wallpaper is ready is *too*
quickly.
I've been meaning to fix this since 2014. Better late than never! We can
just have BackgroundManager emit a loaded signal the first time it loads
its first background, and have the startup animation code wait for that
before proceeding.
Some of this code is by Florian, who helped with promisifying. Thanks!
https://bugzilla.gnome.org/show_bug.cgi?id=734996
On Wayland, navigating menus with the keyboard would not open drop-down
menus when NumLock is enabled.
That's old issue (gnome-shell#550) that was not completely fixed with
commit 88556226 because the lock mask needs to be filtered out in
_onKeyPress() as well.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/550
As per design discussion, the first page is a somewhat of a special
page where we really don't want to change anything unless necessary.
Append new icons at the first available slot after the first page.
Make the placeholder icon be appended to the first available page
as well, since it's always used when dragging from folder dialogs.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1284
When the app folder dialog handles a drag hover, it starts a timeout
to popdown if dragging outside the "real" dialog area. However, when
dragging inside it, BaseAppView handles all drag hover events which
would disarm the popdown timeout. In cases like this, it's almost
impossible to prevent the timeout from triggering, which always pops
down the dialog.
Add a drag monitor when handling any drag hover (which only happens
when dragging outside the folder's icon grid); and eventually disarm
the popdown timeout from the monitor's motion event. Remove the drag
monitor when dragging over the folder dialog again.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1284
App folders are now customizable, and the way to move icons to
another page is by throwing the cursor to either the left or
the right of the grid.
However, doing that triggers the popdown timeout, wich is 600ms
as of now, which is considerably short for such interaction.
Increase this timeout to 1.5 seconds.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1284
Now that the DnD code is shared between AppDisplay and
FolderView, we hit an unexpected problem: FolderView is
handling drag events even when the folder dialog is hidden.
As a side effect, this spams the journal with warnings.
Only handle drag events when mapped. On unmap, disable
the view's drag monitor, and disconnect from all drag
events.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1284
This code will be shared with FolderView in the next commit, so
avoid duplication already and move the to-be-shared code into the
base class.
Because BaseAppView can handle vertical and horizontal orientations,
adapt the drag overshoot code to also handle horizontal overshoot.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1284
When redisplaying, we currently only remove and add icons, but
never adjust the position of already added icons. If the icon
position changed, it wouldn't be reflected on the icon grid.
Make sure to move already added icons.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1284
It is important that '_loadApps()' return a sorted list -- adding the
same icons at the same positions but in different orders results in
a wrong icon grid.
Add support for using a custom positioning function, and implement it
in AppDisplay. Because FolderView doesn't implement a custom sorting
function, the items are still sorted alphabetically.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1284
This is the key that will be used to store the pages and the icons in
each page. The idea is that we we store an a{sv} variant for each page.
This variant will contain <icon id> → array of properties, where we
can store arbitrary data for each icon. The expected output of this
key is:
[
{
'polari.desktop': <{ 'position': 0 }>,
'epiphany.deskop': <{ 'position': 1 }>,
},
{
'telegram.desktop': <{ 'position': 2 }>,
'builder.desktop': <{ 'position': 0 }>,
'gitg.desktop': <{ 'position': 1 }>,
}
]
The toplevel array is sorted, and pages of the grid always show in the
order they are stored.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1284
The leeways are parts of the icon that ignore incoming drag
events. This is how IconGrid and IconGridLayout treat it, and
this is how the icons should treat themselves too.
Make AppIcon ignore dragging over the left and right leeways.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1284
The timeout seems to have been carried over from the old code that
relied on gnome-shell calling 'GetEvents' after every 'Changed' signal
where it was used to throttle the signal. In the new code where
calendar-server is sending the changes themselves via signals this is no
longer necessary and actually causes a delay when switching between
months.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2992
While GtkIconTheme does look up icons in the toplevel icons resource
path, it will only use them as ultimate fallback. That is, if the
icon theme (or the hicolor fallback) include a "keyboard" icon, it
will be used over the "keyboard-enter-symbolic" icon in the resource.
Moving the icons to appropriate subdirectories gives them higher
priority than the fallback names, and thus fixes the issue.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2631
When using the NVIDIA driver, textures tend to loose their pixels when
suspending. In the past we handled this by figuring out when the NVIDIA
driver was used, and reload the background whenever we noticed we
resumed from suspend.
This shouldn't be needed anymore after
https://gitlab.gnome.org/GNOME/mutter/merge_requests/600, as it should
handle this by listening to video-memory-purged signal. Thus remove our
special handling here.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1358
When using the fade animation when transitioning to the overview instead
of zoom, we fade out all window previews to fully transparent. But after
commit 751189253a removed the old _updateWindowPositions() function,
nothing resets the opacity again, so when switching from the app- to the
window picker, all previews are hidden.
Fix this by always resetting the window preview opacity after showing
or hiding the overview.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2969
We don't animate size and position when fading, so we want all previews
to already be at their final position. However when the app picker is
opened from within the overview, window previews use the zoomed layout,
so that's the state we are then fading when leaving the overview from
the app picker.
Fix that by setting the correct state at the start of the fade transition.
(In the case of fadeToOverview(), the value should always be correct
already, but set it anyway for symmetry with fadeFromOverview())
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2969
In commit 9297d87775 we stopped syncing the primary view's actual
geometry at the start of the transition when doing a fade animation,
however the view animation may still be triggered by an allocation
change.
Prevent those unwanted size changes during fade by keeping track of
the fade state and explicitly skip syncing the geometry while a fade
is ongoing.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2969
Since commit af543daf1c, we skip the overview transition when the
actual geometry hasn't been set yet. However with the new layout
manager, the only bit that still needs the separate geometry is
the transition of the view, the workspaces can do their transition
just fine.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2969
When dragging the workspaces through the swipe gesture, all
workspaces must be visible. WorkspacesView's _updateVisibility()
method special-cases this and ensures that.
However, this method is only called when (1) going to the active
workspace, and (2) when the gesture ends. That means, if there
is any workspace hidden by the time a gesture starts, it is never
shown!
Call _updateVisibility() on startTouchGesture() as well.
Related: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2969https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1360
Because for most frames during a workspace switch it's not changing and
we can repaint it faster if it's cached on the GPU as a single texture.
This seems to reduce the render time for workspace switching by more
than 20%.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1356
Since commit b60836932 we only allow WM_CLASS matches for sandboxed
applications if the found app's ID is prefixed by the sandbox ID.
The existing check still has a hole in it though: "org.example.Foo"
and "org.example.FooDevel" are different applications, yet the former
is a prefix of the latter.
So tighten the check by including a trailing "." in the checked prefix;
this excludes cases like the above, while still working for the regular
case of a single .desktop file because our app IDs include the ".desktop"
suffix.
Spotted by wjt.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1357
When going straight to the app picker, we fade in the overview instead
of doing the full-blown zoom transition. In order to keep windows at
their floating position, we must apply the same to the view itself
and not transition to the overview geometry when fading.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1353
We don't always want to sync the geometry when entering the overview,
namely when the fade transition is used.
However we do want the correct geometry once we have entered the overview,
so that workspaces are at their place when switching from the app picker.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1353
Non-primary views always use their monitor's work area for their
geometry, so there's nothing to animate when leaving the overview.
The animation is already limited to the primary view when entering
the overview, so this is also more consistent.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1353
It doesn't matter which animation we use to enter the overview,
we always want to start and end with the floating layout.
The simplest way to achieve that is by creating the state adjustment
with the correct value in the first place.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1353
The transition was temporarily removed when switching to the new
workspace layout manager. Now everything is in place to reimplement
it with a combination of the layout manager's state adjustment and
the view's allocation.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1345
So far we've been allocating workspaces in a stack, and relied on
translation to move them to the right position. And as the position
depends on both the workspace's index and the view's viewport, some
care is needed to prevent gestures/scrolling from interfering with
layout updates.
Clean that up by properly allocating workspaces in a row or column,
and use a translation to reflect the current scroll position.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1345
Since the workspaces themselves stopped using it, there is little
reason for upholding the difference between "full" and "actual"
geometry.
Just base positioning/swiping on the view's allocation.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1345
The workspace's layout manager keeps the workspace at the same ratio as
the work area, so it makes more sense to base the views' default geometry
on that as well than the monitor area we are using right now.
(It shouldn't matter much in practice, as this only affects views on
non-primary monitors where the work area usually matches the monitor area)
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1345
We adjust the size and position of the primary view to match the workspaces
display, but views on other monitors are always set to fill their monitor.
Take that into account and create views with a fixed size and position, then
only sync the primary view to the new geometry.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1345
WindowPreviews now contain and manage overlaid elements like close
button or title label themselves. That's generally better, but right now
the only way to disable those overlays (for example during transitions)
is to prevent any hover or focus events from getting to the preview.
Instead, add some explicit API for enabling or disabling overlay support.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1345
For the windowPreview we need to ensure the style information of the
border and title is up-to-date when chromeWidths() or chromeHeights() is
called. Since the introduction of the WorkspaceLayout those functions
may be called during an allocation cycle, which means we should avoid
calling queuing relayouts inside them. Calling StWidgets ensure_style()
method will queue a relayout though in case the newly generated theme
node has a different geometry.
So avoid queueing a relayout during allocation cycles (and the warning
Clutter logs because of that) by ensuring the style of the border and
title earlier, as soon as the WindowPreview is attached to a stage.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1305
Switch to the new WorkspaceLayout layout manager to allocate the window
clones of the overview properly using Clutters layouting mechanisms.
Since we now no longer make use of the fullGeometry, we can remove the
setFullGeometry() function from the Workspace class. Also we can stop
setting the actualGeometry on the Workspaces and WorkspaceViews and
instead just set the fixed position and size of the views to their
full or actual geometry. This also has the benefit that we no longer
have to set a custom clip, but can simply enable clip_to_allocation.
The geometry needs to be set inside a BEFORE_REDRAW later because
_updateWorkspacesActualGeometry() is called from a notify::allocation
handler.
This isn't doing any animations when showing/hiding the overview yet,
we'll add that in the next commit.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1305
Add a new ClutterLayoutManager for layouting the workspaces of the
overview, WorkspaceLayout.
This layout manager integrates the existing LayoutStrategies used to
layout the window clones of the overview and supports freezing the
layout, animating between layout changes and adjusting the spacing for
the width and height of the window chrome. It also adds support for a
layout of the windows that looks the same as the actual workspace,
transitioning between that layout and the LayoutStrategy can be done by
setting the value of an StAdjustment, available using the
stateAdjustment getter function.
This will replace the current static-positioning based layouting of the
window clones in the next commit.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1305
We're going to use fixed position for positioning workspaces when
they're allocated by their own layout manager, using those positions to
scroll between different workspaces interferes with that, so do that
using translations instead.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1305
In portrait orientation, we set the height to the preferred height
for the monitor width (or, if smaller, a third o the screen height).
However as the forWidth currently doesn't make a difference, the height
is effectively controlled by the natural height of the keys - which is
rather small.
Address this by making AspectContainer request an appropriate preferred
size based on the fixed ratio.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2349
Currently our heuristics for matching a window to its app check
for the application ID before the WM_CLASS, as the ID is more
reliable in so far that it is outside the application's control
and so it cannot use it to spoof a different application.
However this also prevents applications with multiple .desktop
files like LibreOffice from matching any .desktop files other
than the one under the main ID.
Since we now no longer allow the WM_CLASS to match a .desktop
file that doesn't belong to the sandboxed application, we can
fix that issue by checking the WM_CLASS first, without opening
the door to spoofing.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/219
At least flatpak (no idea about snap, sorry) enforces that all .desktop
files exported by a sandboxed app use the application ID as prefix.
Add the same check when trying to find a match based on the WM_CLASS,
to prevent sandboxed apps from matching a .desktop file they do not
own.
At the moment this is unlikely as we check for a match on the
sandboxed app ID first, but we are about to change that.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/219
The previous commit implemented a new CredentialManager interface to
facilitate adding additional providers for pre-authenticating the user
at the login screen.
This commit implements a new credential manager using that interface
for vmware deployments.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/1983
Commit 4cda61a1 added support for pre-authenticated logins in
oVirt environments. This feature prevents a user from having
to type their password twice (once to the oVirt management machine,
and then immediately again in the provisioned guest running gnome-shell).
That feature is currently oVirt specific, but a similar feature would
be useful in non-oVirt based virt farm environments.
Toward that end, this commit generalizes the various aspects of the
oVirt integration code, so that it can be reused in a subsequent
commit for adding single sign on support in vmware deployments, too.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/1983
Now that we can always associate a GIcon with the app, add a method
to access it. While create_icon_texture() is still likely to be more
convenient in most cases, exposing the icon can still be useful, for
example to add it to a different kind of actor or to compare it with
other GIcons.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1342
We still load the surface into an StImageContent, but instead of
adding the content to an actor we hand out, return the content
itself (as GIcon).
That means we lose the ability to specify an icon size, but as we
get the pixel data from a fixed-size surface anyway, that shouldn't
matter much in practice.
Not to mention that the function is only used for fallback X11 icons,
which are already shit more often than not.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1342
On the one hand, this is a bit of a stretch: StImageContent is what
we create from GIcons.
But on the other hand, there's some justification: StImageContent does
represent an image (and likely icon) after all, and there's some
precedent with GdkPixbuf.
In the end as we don't care about serialization or loading from other
API, we can go with a very crude implementation that allows us to
pass out a content as GIcon and use it directly when "loading" it.
We will use that soon to represent X11 window icons as GIcons, which
in turn will allow us to unify app icon handling.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1342
ClutterActor provides the same function, but with a different return
value. So since we already switched to the ClutterActor implementation
in our C code, we can now safely remove st_widget_get_resource_scale()
and update the JS code that's still using the old API.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1287
Instead of using the "notify::resource-scale" signal and StWidgets
"resource-scale-changed" signal, use the new "resource-scale-changed"
signal of ClutterActor, which replaces its "resource-scale" property.
Since we'd now have two "resource-scale-changed" signals, one on
ClutterActor and one on StWidget, remove the StWidget one in favour of
the new one.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1287
The blur effect needs to take the scale-factor into account, so we
listen for scale changes. However we set up the signal handler when
creating a background, which is repeated for each monitor, and every
time the monitor configuration changes. But we only disconnect the
last handler that was connected, and only when we are destroyed,
not when recreating backgrounds.
Fix this by splitting out updating the effect parameters to a separate
method that iterates over all backgrounds, so we can simply set up the
handler from the constructor.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1341
The arrow of the removed app was still left in the list with the
visibility of the arrow still depending on the original list order. This
could either lead to apps with just one window now suddenly having a
down arrow or apps with multiple windows not having one. If the last
window in the list had a down arrow, it would have been displayed
outside the window switcher.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2935https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1340
As usually with GObject setters, we should check whether the property
actually changed before setting the value and notifying the property. So
check whether the title or description text actually changed before
setting it.
This fixes a bug which makes the title flicker and change its size,
because when updating the title we remove the "leightweight" css class
and reapply it inside a later, which makes the title appear larger for
one frame.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2574https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1336
When scrolled, the container's allocation is smaller than the allocation
of the content. To account for that, commit 2717ca9d08 added the
additional size reported by the layout manager to the content allocation.
However as it did so unconditionally, we now allow children to extend
outside the parent even when *not* scrolled, which breaks any constraints
set on the container (like "width" or "max-height").
Fix this by only extending the child allocation in scrollable dimensions.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2491
The performance of the icon grid was being hindered by a large number
of primitives (a few hundred) being copied from the CPU to the GPU on
each frame. This was first noticed in mutter#971 but we failed to
investigate all the issues at the time.
You can also see the high number using `COGL_DEBUG=batching` or
`COGL_DEBUG=disable-texturing`. So now it's obvious that high number is
every letter of every label being uploaded as a separate quad. Let's not
do that and instead treat the whole label as a single quad/texture.
Measured performance on an i7-7700 at UHD 3840x2160:
Journal entries per frame on the icon grid:
* Before: 288 (18 KB copied from CPU to GPU)
* After: 73 ( 4 KB copied from CPU to GPU)
Spring animation:
* Before: 20-30 FPS, avg 22/peak 45 milliseconds per frame
* After: 30-40 FPS, avg 14/peak 28 milliseconds per frame
Scrolling the icon grid:
* Before: 15 FPS, 50 milliseconds per frame
* After: 30 FPS, 28 milliseconds per frame
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1329
Noticed while working on customizable folders. Calling GrabHelper.ungrab()
ends up calling FolderDialog.popdown(), but at this point the '_isOpen'
field isn't updated yet, so we end up calling popdown() twice.
Update the '_isOpen' field before ungrabbing.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1332
Overview has signals to notify about starting, cancelling, and
finishing icon drags, but none of these signals pass the dragged
item to the callbacks.
Pass the dragged items to the 'item-drag-*' overview signals.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1332
Commit c7e597cf72 tried to improve the slide animations when entering
the overview by using the same time as the overall overview animation,
but in fact broke the animation most of the times.
That is because the Overview imports OverviewControls before defining
the ANIMATION_TIME variable, so any javascript code that is evaluated
during that import will see the value as "undefined" (which is converted
to 0 for the animation).
Fix this by moving the ANIMATION_TIME variable before the imports instead
of the usual placement.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1331
When you tap Super and see the sidebars and windows slide, it looks more
cohesive if those animations complete at the same time.
Previously there were 0.09 seconds difference between the two animations
which was enough to make it look slightly buggy. Now it doesn't.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1289
We now found the underlying bug: The ControlsManager (which causes the
bad call to `_updateWorkspacesFullGeometry()`) is getting (re-)allocated
while we add the view to the overviewGroup actor because the
overviewGroup is already visible and the view is immediately getting
mapped by `clutter_actor_add_child_internal()`. That causes a
resource-scale calculation and that indirectly causes a call to
`_clutter_stage_maybe_relayout()` (explained more detailed in the last
commit).
So now that we got rid of the immediate relayout happening when mapping
the view, we can revert this fix.
This reverts commit 6cc19ee6f0.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1315
When the bounding box size is 0 during allocation (which happens right
after creating a window for example), we're doing a division by zero and
end up with a NaN scale. This ends up making the childBox NaN, which
triggers an error in Clutters allocation machinery.
So fix that and fall back to a scale of 1 in case the bounding box is
empty.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1320
The current microphone indicator only indicates if the microphone is in
use. Users might be also interested if their microphone is recording
or is muted, this commit enables that without opening the pop-up
menu. The microphone icon changes itself, depending on the sensitivity
of the microphone. It behaves similar to the already existing volume
indicator.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2902
In the past, the icon grid would update the number of pages
during the call to adaptToSize(). However, after the new grid
layout landed, the number of pages is updated by the time an
item is added or removed.
Instead of comparing the old and new number of pages in the
icon grid, compare the pages shown by the indicator, and the
grid pages.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1271
Now that we don't have the Frequent tab anymore, and subsequently
the buttons to switch tabs, the app grid fill all the way to the
bottom, leaving no room for drag overshoot.
Add a 20px (i.e. OVERSHOOT_THRESHOLD) area at the bottom of the
grid where dragging actually scrolls to the next page.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1271
The two BaseAppView subclasses now share a lot in terms of
widgetry: they both have a scroll view, pagination dots, swipe
management, etc.
Move this shared code into BaseAppView. Notice, however, that
BaseAppView only creates the widgetry, but it doesn't add them
to any specific layout. FolderView arranges the widgetry in a
vertical box, while AppDisplay arranges it in a ShellStack.
Add a new 'orientation' parameter to BaseAppView and use it
to determine the orientation of the pagination dots, the swipe
tracker direction, and the scroll event handling.
It is worth noticing that the scroll event is a bit more
sophisticated now: when the orientation is horizontal, it
handles all directions since mice wheels usually only generate
up/down events.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1271
When FolderIcon is destroyed, it destroyed the FolderView and, if
there's a folder dialog present, it destroys the dialog as well.
Turns out, the folder dialog adds the icon's FolderView to itself.
The view becomes part of the dialog's actor tree. When the dialog
is destroyed, it also tries to destroy the view - but the folder
view was already destroyed by FolderIcon!
Fix that by letting the dialog destroy the folder view if it exists,
otherwise destroy the folder view directly.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1271
Add app icons to the exact page and position they're located
instead of always appending. This will be useful later when
custom icon positions are in place.
For now, it assumes pages are always filled, which is true,
but this will also change with custom icon positions.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1271
AppDisplay currently adds all icons, and hides the ones inside
a folder. Change that to only add the icons that are not inside
folders. Adding an icon to a folder removes the icon from the
main grid.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1271
When filtering out the app icons, AppDisplay calls FolderIcon.getAppIds(),
which then calls FolderView.getAllItems(). This last function reads the
already added app icons inside the given folder, and return their app ids.
So far, so good.
When the GSettings backing a folder changes, FolderIcon emits 'apps-changed'
to notify AppDisplay that the folder changed.
Cool.
When AppDisplay receives this signal, it first recreates its own icons, then
updates the folders, and finally hides the icons that are inside folders.
This series of events is unfortunate. Future patches will need the folder
to be updated *before* AppDisplay updates its own icons.
Update folder icons before chaining up to BaseAppView._redisplay().
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1271
The icon grid is always paginated, so the app grid code doesn't need
to behave differently in the FolderView and AppDisplay.
Move the keyboard handling to IconGrid itself, and remove the now dead
code from AppDisplay.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1271
The new icon grid layout operates based on rows and columns, and
doesn't try to dynamically adapt it to fit to the container. In
this case, it is better to have a pre-defined set of well-known,
well-tested rows and columns, and switch between them based on
the aspect ratio of the screen.
Introduce a set of modes to the icon grid, and select the mode
that is closest to the aspect ratio.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1271
IconGridLayout is a new layout manager that aims to replace the
current paginated layout algorithm implemented by the icon grid.
There are a few outstanding aspects of this new layout manager
that are worth highlighting. IconGridLayout implements all the
mechanisms necessary for a paginated icon grid, but doesn't
implement any policies around it. The reason behind this decision
is that this layout manager will be used by other places (e.g.
the login dialog) that demand different policies to how the
grid should look like.
Another important aspect of this grid is that it does not queue
any relayouts when changing its properties. If a relayout is
required, the actor should manually queue it. This is necessary
to avoid layout loops.
Add the IconGridLayout class. Next commits will do the surgery
to IconGrid and any related code to use this new layout manager.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1271
For drag actors which get reparented to the uiGroup, we currently wait
until the next input event to set the fixed position of the actor, until
that they will just be allocated their old fixed position, which is 0,
0.
So avoid drag actors flickering at the top left for one frame and
position them correctly right after reparenting.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1310
Properly adjust for drag actors which were allocated using a custom
vfunc_allocate() and might not have gotten allocated their preferred
size. When DND reparents the actor to the uiGroup, the drag actor will
get allocated its preferred size, so we also need to take the difference
between the old allocation size and the preferred size into account
before reparenting to the uiGroup.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1310
Properly handle drag actors which are not allocated using a fixed
position and disable the fixed position we were using to move the actor
around before we reparent it again to its original parent.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1310
As the view now scrolls from right-to-left in RTL locales, the
scroll bar handle should reflect that.
Likewise the event handling needs adjusting as well: Scrolling
left should increase the adjustment value, and clicking the
trough to the left of the handle as well.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1318
The workspace.js file is quite large and is a bit confusing when it
comes to the term "window" in there, because it can either refer to a
WindowPreview of a complete window or to an individual window like an
attached dialog.
So try to avoid that confusion and split the new WindowPreview class and
its WindowPreviewLayout layout manager out into a new windowPreview.js
file.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1307
MetaWindow is Mutters representation of a window and provides all the
APIs about it, MetaWindowActor is just the ClutterActor that's drawing
that window. So use a MetaWindow to create a WindowPreview instead of
the window actor.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1307
We want to stop using the MetaWindowActor for things which are actually
related to the MetaWindow, one more thing where we can change that is
the overviewHint, which is currently added to the MetaWindowActor.
So move that hint to the MetaWindow and stop calling
get_compositor_private() in a few more places.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1307
We can simply get the MetaWindowActor by calling
MetaWindow.get_compositor_private(), so stop accessing the realWindow
property of WindowPreview. For this we also have to make _isMyWindow()
and _isOverviewWindow() take a MetaWindow as an argument instead of a
MetaWindowActor.
Since the WorkspacesThumbnails are also drop targets for WindowPreviews
and their WindowClones also have the public metaWindow property, switch
to using the metaWindow property there, too.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1307
Since the WindowPreview class rarely needs to handle the actual actor
painting the window preview, refactor the WindowPreviewLayout a bit to
only pass a MetaWindow to its addWindow() and removeWindow() functions.
Also make the getWindows() function return an array of MetaWindows,
which makes the getMetaWindow() function obsolete, so remove that.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1307
We're going to remove ClutterClones, so call the parameters to
addWindow() and removeWindow() "actor" instead of "clone". Also make the
destroyIds less confusing and rename the actual actor destroy id to
"destroyId", and rename the window actors destroy id to
"windowActorDestroyId".
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1307
Since ClutterClones are going to be removed, let's switch the
terminology here to something that's more understandable and rename the
WindowClone class and its layout manager to
WindowPreview/WindowPreviewLayout.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1307
Now that we properly notify mutter about when a size-change animation
has ended, it should never happen that a new size-change animation is
started without the last one being cancelled (ie. 'kill-window-effects'
being emitted).
This means there should also never be an old animationInfo attached to a
window actor, so warn in case we still find one when starting the
animation.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1251
We're currently using the hack of telling mutter that our effect is
completed (even though it isn't) in order to unfreeze updates of the
window actor.
This causes a bug with detecting the wl_outputs a window is
visible on, because the MetaWindowActor emits its "effects-completed"
signal too early, making Mutter update the wl_outputs while we're doing
the animation.
Now since meta_wayland_actor_surface_is_on_logical_monitor() uses the
transformed position and size of the MetaSurfaceActor and is being
called right after we setup the animation (but before it actually
starts, that happens at the next paint cycle) it will use a "very wrong"
rectangle: The transformation has been set to move the actor back to its
old position, and while we did already unfreeze updates and called
clutter_actor_set_position() in meta_window_actor_sync_actor_geometry(),
the actual allocation is not updated yet; this makes
clutter_actor_get_transformed_position() return a position including in
the new transformation, but not including the new allocation, and the
rectangle ends up being moved to the next monitor or completely out of
the stage.
To fix this issue properly, we need to decouple unfreezing actor updates
from emitting the "effects-completed" signal, which is now possible with
the new meta_window_actor_freeze() and meta_window_actor_thaw() APIs. So
use those new methods to freeze and thaw actor updates ourselves and
make sure to call shellwm.completed_size_change() only after the
animation has finished.
Mutter MR: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1250
Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/513https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1251
It might be that we receive a "kill-window-effects" signal between the
emission of the "size-change" and the "size-changed" signal.
In this case we already have the animationInfo attached to the window
actor, so we should also remove it.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1251
Using CSS to center the title actor on the border is a bit ugly, because
it requires the CSS to match the calculations used in chromeHeights().
Also it is not possible to use CSS margins for cases where the position
of the actor is determined at run time, such as for the close button.
Instead use an invisible actor that spans between the horizontal and
vertical center lines of the border as guide when aligning the title
actor.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1313
Commit 1ea22a5281 broke the window reposition animation when it
based the ::size-changed signal on the layout manager's bounding box
instead of the MetaWindow::size-changed signal.
That's happening because of the combination of:
1. we adjust to window size changes immediately without animations
2. closing a window triggers a change to a 0x0 bounding box which
is not treated as a size change
Fix this by addressing the 2nd factor, and don't treat a change to
a 0x0 bounding box as size change.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2901
Animating the window clones of the overview requires the fullGeometry
and the actualGeometry to be set, which they won't be when showing the
overview for the first time. So don't even try to animate the window
clones in that case because the geometries will still be null and
accessing them in workspace.js will throw errors.
The workspace views will still get the correct layout as soon as the
allocations happen because syncing the geometries will trigger updating
the window positions. Since animations are disabled for position changes
when syncing the geometry though, we won't get an animation and the
clones will jump into place. That's not a regression though since before
this change we also didn't animate in that case because the geometries
used were simply wrong (the actualGeometry was 0-sized as explained in
the last commit).
If we wanted to fix the initial animation of the overview, we'd have to
always enable animations of the window clones when syncing geometries,
but that would break the animation of the workspace when hovering the
workspaceThumbnail slider, because right now those animations are "glued
together" using the actualGeometry, so they would get out of sync.
The reason there are no errors happening in workspace.js with the
existing code is that due to a bug in Clutter the fullGeometry of
WorkspacesDisplay gets set very early while mapping the WorkspacesViews
(because the overviews ControlsManager gets an allocation during the
resource scale calculation of a ClutterClone, see
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1181), so it
won't be set to null anymore when calling
WorkspacesView.animateToOverview().
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1119
The fullGeometry and the actualGeometry of the WorkspacesDisplay are set
from the allocation of the overviews ControlsManager and the
WorkspacesDisplay, that means they're only valid after those actors got
their allocations during Clutters allocation cycle.
Since WorkspacesDisplay._updateWorkspacesViews() is already called while
showing/mapping the WorkspacesDisplay, that allocation cycle didn't
happen yet and we end up either setting the geometries of the views to
null (in case of the fullGeometry) or to something wrong (a 0-sized
allocation in case of the actualGeometry).
So avoid setting invalid geometries on the views by initializing both
the fullGeometry and the actualGeometry to null, and then only updating
the geometries of the views after they're set to a correct value.
Note that this means we won't correctly animate the overview the first
time we open it since the animation depends on the geometries being set,
but is being started from show(), which means no allocations have
happened yet. In practice this introduces no regression though since
before this change we simply used incorrect geometries (see the 0-sized
allocation mentioned above) on the initial opening and the animation
didn't work either.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1119
Start using the new overlays we introduced in the last commit and remove
the WindowOverlay class and the objects for keeping track of them in the
Workspace.
The new layout which doesn't use the -shell-close-overlap CSS property
anymore sligthly changes the position of the close button to be a bit
further away from the actual window.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1298
So far we allowed the titles of window overlays to expand their width to
be larger than the actual WindowClone, they could expand to the full
size of the Workspace.
Since we're now going to implement those titles as part of the
WindowClone itself, having this feature is no longer possible as easily
as it was before. That's because the clones are stacked according to the
stacking of the actual windows, and since the overlay-elements are
attached to those clones, they will also be shown underneath other
clones.
So stop allowing the titles to expand and limit their size to the width
of the clone, which makes sure titles never get shown above or
underneath other clones.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1298
Add the window overlays we're currently showing using the WindowOverlay
class to the WindowClone class and implement them using
ClutterConstraints instead of the old fixed position/size layout, which
had to be used because the workspaces were scaled, and the title and app
icon were kept unscaled using a separate layer.
Specifically, this is done by adding the ClutterClones to a static
container owned by the WindowClone and adding the elements of the
overlay as children to the WindowClone itself. That way the
overlay-elements can use the container as a source for their constraints
and we avoid having to make sure the overlays remain visible above the
ClutterClones.
We're not using the new overlays yet, they're hidden by default and
showOverlay() isn't called anywhere yet.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1298
Now that we have a new API to get all the windows and metaWindows from
our layout manager, implement the deleteAll() method of the window clone
using that API instead of looping through the children of the actor and
using the source of the ClutterClone.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1298
Now that the folder dialog covers the whole primary
monitor, it eats all input events, and doesn't allow
the event blocker to detect clicks.
Move the click action to the folder dialog itself, and
popdown the dialog if a click is triggered on the dialog
(but not on any children).
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1301
Future commits will improve input handling of the folder
dialog, and they'll require the dialog to cover the whole
primary monitor.
Add another internal, center-aligned container to the
folder dialog, and make it cover the whole available area.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1301
Right now, the app folder dialog isn't really a dialog,
since it is actually added to the AppDisplay. Furthermore,
having it added in AppDisplay may mess up with its sizing
calculations, since AppDisplay has a ClutterBinLayout and
the folder dialog has a fairly large minimum size.
Add the folder dialog to the overview group. Next commits
will adjust various actors to be able to better handle it.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1301
clutter_text_get_selection() creates a copy of the selected text which
gets passed to st_clipboard_set_text() which creates its own copy. The
copy returned by clutter_text_get_selection() however never got free'd.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1306
Events have a clear and obvious connection to the calendar, and similar
to the Clocks and Weather sections there's a strong link to a particular
application.
Adding them as another section to the right-hand side of the calendar
therefore presents a viable alternative to the old events section.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1282
The idea behind hiding the notifications and media section on days
other than today was that they represent present activity together
with today's events, in contrast to past and future events from
other days.
After events were moved out of the message list, that behavior is
no longer useful: We just guarantee that the left-hand side of the
calendar will always be empty when browsing the calendar.
Adjust to that by removing the limitation by date.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1282
While treating notifications as a type of present event was a neat
concept, there are some issues with it that we never managed to
address (not least the inability to "open" an event).
So remove the current events section from the message list; we'll
bring back events in a different form later.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1282
The HasCalendar property reflects whether there are any views, and views
change either when clients appear/disappear or when the time range changes.
However we currently only emit the PropertiesChanged signal for the former,
fix that.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1300
The shell mime sniffer goes through all the files in a directory,
however in case a file content type is not recognized, the GIO function
g_file_info_get_content_type() may return NULL, causing a crash when
looking up into the content type tables, as they are supposed to contain
strings only and they use `g_str_hash` has func, which doesn't support
NULL values.
So, in case we get an invalid content type, let's just ignore it,
without adding it to the cache as we do in the nautilus code that was
inspiring the sniffer.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2643
This comment is no longer correct, we're not inserting any actors here
to adjust for the window border, but we're modifying the allocation of
the children to adjust for that border.
Since that happens in the layout manager anyway, remove the comment
here.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1297
Now that we handle all ClutterClones belonging to the WindowClone pretty
much the same, we can add a generic _addWindow function to WindowClone
which creates the ClutterClone and adds it to the layout manager.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1297
This isn't quite the same as the allocation, but it's what the workspace
actually wants to use given that we use the bounding box of the
WindowClone for all the layout calculation.
So instead of calculating the windowCenter in the WindowClone, make use
of the bounding-box property of the layout manager and return the center
point of that.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1297
Make use of the new bounding-box property we introduced for the
WindowClones layout manager in the last commit.
With this we can remove all the bounding box calculation code from the
WindowClone class and simply use the "notify::bounding-box" signal to
notify changes to our size. To make sure users of the WindowClone don't
break, we now have to convert the layout managers ClutterActorBox in our
getter function to a JS object.
Since we now also don't have to connect to the "destroy" signal of the
attached dialogs anymore, we can remove _disconnectSignals() and only
listen to "destroy" of the toplevel window.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1297
Move the tracking of the bounding box and all the layout related things
out of the WindowClone class and into the layout manager. This allows
the layout manager to keep track of its windows itself and simply notify
the new bounding-box property in case that box changes.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1297
WorkspacesDisplay is a ClutterActor subclass, and overriding
the show and hide methods require chaining up, otherwise the
actor isn't actually shown or hidden.
To avoid clashing with the pre-existing show method, rename
to animateToOverview.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1295
Unlike the desktop-entry hint, the app name is not optional. That
doesn't mean that we'll be able to match it to a .desktop file,
but we can at least try if we fail to match on PID or desktop-entry.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1291
Since we now have a layout manager for the WindowClone that allows
allocating it a size that isn't the absolute size of the window, we can
now give the WindowClone an artificial size and it will get scaled
accordingly.
So make use of that and stop positioning WindowClones using fixed
position and scale and use a fixed position and fixed size instead. This
will make it easier to use a ClutterLayoutManager to allocate the
WindowClones, because layout managers should only set the allocation of
their children, not the scale.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1294
Since we're going to override the fixed width and height of the
ClutterActor the WindowClone is subclassing, remove those confusing
getter methods for width and height and switch to the public boundingBox
for getting that information.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1294
The getOriginalPosition() API of WindowClone can easily be replaced by
using the existing boundingBox property, which reflects the windows
bounding box in absolute coordinates. This property is also used
everywhere else in the Workspace object, so we can use it here, too.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1294
Change the preferred size functions of the layout manager of window
clones to allow allocating smaller sizes, too. Also scale down the
allocation sizes of the ClutterClones our allocate implementation so
the ClutterClones will scale their texture accordingly.
This will enable us to position the window clones using their allocation
size instead of their scale, which is necessary when introducing a new
ClutterLayoutManager that positions the window clones.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1294
We're going to add a ClutterLayoutManager responsible for allocating the
WindowClones. Since layout managers should only set the allocation of
actors, not the translation or scale, we need to position the
WindowClones using their x, y, width and height properties.
The first step for this is to revert this commit, which switched from
setting fixed positions on WindowClones to using the translation
properties.
This reverts commit 8929c89d1f.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1294
Being able to visualize the actor tree is a handy feature
to have, specially when debugging the hierarchy.
Add a new "Actors" tab to the Looking Glass with the actor
tree inspector. The tree is cleared on unmap to not get
heavy on the number of actors.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1292
As explained in the comment in _init() of WindowClone, we hide the
actual clone from picking so it doesn't interfere with XDND.
This description applies to the clones of the attached dialogs just as
well though, so hide the clones of attached dialogs from picking, too.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1293
We currently only remove the screenshot operation from the shooter
map if the color pick operation completed successfully, but not if
it was cancelled. As a result, we now reject any further requests
from the same sender because we assume that there is an ongoing
operation.
Fix this by moving the cleanup to a finally clause that runs for
both code paths.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1288
Right now _createScreenshot() returns a tuple that indicates failure
when a sender requests a screenshot operation before a previously
started operation finished.
However that doesn't work for the PickColor() method, as it uses a
different return type than the other methods.
Address this by returning an error instead, which works in any case;
arguably trying to start multiple operations in parallel is an error
by the caller more than it is a failed operation anyway.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1288
Now that the only user of the IconGrid is AppDisplay, and
it only uses the paginated icon grid, there's no point in
having the two classes split anymore.
In addition to that, future commits will introduce a layout
manager that will extend current icon grid features, and
merging PaginatedIconGrid and IconGrid in the same class will
vastly simplify this transition.
Merge PaginatedIconGrid into IconGrid, and adapt AppDisplay
to this change.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1267
Now that AllView is the only actor that AppDisplay creates,
we can actually merge them together.
Merge AllView in AppDisplay, remove what used to be AppDisplay,
and rename AllView to AppDisplay.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/880
The Frequent apps grid has a few problems:
* On a fresh install there would be no history of app usage so the
applications shown in the grid have no relevance it takes time
to be useful instead of being useful from the start;
* The grid has far too many items in it to be relevant; 24 apps is
well beyond the average use case as most people don't frequently
use that many, so it gets populated with several apps that are
single use (hello xterm);
* The position of items in the grid are always changing based on an
unknown frequency metric (and not by user-intended input) which
makes it a poor way to quickly launch apps as one would have to
constantly learn the positions of the items in the grid;
* Having two app grids is a bit superfluous and needlessly complicates
the app launching navigation: you have to spend time checking the
frequent grid and if it's not there you have to switch over to another
grid and find the app you need in there it's not straightforward.
Remove the Frequent tab and simplify the related code.
Related: https://gitlab.gnome.org/GNOME/gnome-shell/issues/1425https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/880
As outlined in commit 36b8dcbe07, we can end up with wrong icons
if the icon theme changes right after a GTK theme change to/from
HighContrast triggered a theme reload.
That's because when we reload icons for the new icon theme, there
are already pending requests due to the icon-style change; those
requests are simply re-used for the new icons, with the existing
icon infos from the old theme.
The above commit applied a simple work-around by changing the
icon theme before the GTK theme, but that only works for the
HighContrast switch in our own UI.
It turns out that Settings also uses the "wrong" order, so the
issue still reproduces with the Universal Access panel.
So instead of relying on everything changing the settings in the
order we expect, cancel all ongoing requests on icon-theme changes.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1277
With color picking implemented in the compositor, we
can do better than letting the user pick a pixel with
the crosshair cursor, and present them with a preview
of the color that will be selected.
Do this by replacing the cursor with a custom icon and
apply a recoloring effect, where we replace a given color
with the color of the currently hovered pixel (similar
to a green screen).
https://gitlab.gnome.org/GNOME/gnome-shell/issues/451
Since the `MetaSelection` of the global `StClipboard` is private (and
should be), there is no reasonable way for extensions or external code
to query the supported mime-types.
Add `st_clipboard_get_mimetypes()` so this can be queried without
poking around in private code.
closes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2819
Currently there is no indication that an extension had an error except
for the sensitivity of the switch (which may have a different cause).
This is useful information to users, so add a small error indicator
alongside the updates icon and show the actual error in the details.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2337
logExtensionError() currently saves the error message by calling
toString() on the passed error. That's convenient as it allows to
pass a string instead of a "proper" error, but the result isn't
great for the common Error case: Its toString() method prefixes
the message with the error name, which usually is just "Error:".
The plain message is more suitable for displaying it to users,
so use that for Error objects.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2337
Currently the switches handle position reflects the requested
extension state (as in: the user (de)activated the switch),
while the actual extension state is reflected by the underlying
state.
That doesn't work well when the switch is insensitive though (for
example on error), because the desaturation neuters the color
that reflects the state.
Address this by resetting the switch handle to the state when
making it insensitive.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1263
Since e06109c23c we keep old theme nodes
valid during the emission of the "custom-stylesheets-changed" signal.
It turns out that we might still look up the file of a stylesheet using
the files_by_stylesheet hashtable during the emission of that signal,
causing a crash because the assertion in _st_theme_resolve_url() fails.
So fix that and remove the stylesheet entry from the files_by_stylesheet
hashtable after emitting the "custom-stylesheets-changed" signal. And to
be consistent, also remove the entry from the stylesheets_by_file
hashtable after emitting the signal.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2757
`StBoxLayout` has a couple properties (`vertical` and `pack-start`)
improperly referenced as signals, and is somewhat unclear these
properties are wrappers around the underlying `ClutterBoxLayout`
properties.
Fix these up and add references to the underlying properties, rather
than redescribing them.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2816
Replace the usage of IconGrid in the grid search results by
a custom layout manager that only allocates as many children
as the actor can fit.
This new layout manager does not implement changing the icon
size depending on the screen size.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1265
This is a small convenience method for using ClutterActor's iterator API
with javascript's built-in iterator protocol, for example as:
for (let child of container.iterate_children())
doStuff(child);
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1268
For fd.o notifications, we are taking the sender's PID into
account when associating notifications with sources (mainly
to deal with notify-send).
This broke when the implementation under the well-known name
was moved into a separate service, as the implementation in
gnome-shell will now always see the public notification-daemon
as sender.
Restore the old behavior by resolving the sender PID in the
separate service, and pass it as hint to the implementation
in gnome-shell.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2592
Spidermonkey caches imports, which means that uninstalling an
old extension version and installing a new one doesn't work as
expected: If the previous version was loaded, then its code will
be imported instead.
For the last couple of releases this has been a reliable source
of extension bug reports after major GNOME updates. Thankfully
chrome-gnome-shell removed its update support in favor of our
built-in support now, but users may still use older versions
or perform those actions manually, so it still makes sense to
catch this case and set an appropriate error.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1248
The do-not-disturb button and the contained switch are
tied together via a bidirectional property binding.
However it still matters which objects are used as source
and target, as that will determine the initial state: Right
now the (unchecked) button is used as source, which means
that do-not-disturb is turned off on startup.
We want the state to be preserved, so swap source and target
to let the switch (that is bound to the underlying GSetting)
control the initial state.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2804
Sliders can be operated by mouse scroll, but the mouse has to be over
the slider control. Make the brightness and volume system menu entries
forward scroll events to the sliders they contain so that scrolling
anywhere on the menu item operates the slider.
Closes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2795
Whether or not an extension has errors influences the 'canChange'
property, but so far we only update it for errors that occur when
initializing the extension, not when an extension is enabled later.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1249
Soup.SessionAsync by default sets timeout and idle_timeout to 0. This
causes connections to hang around in state CLOSE_WAIT forever after the
remote host has closed the connection.
To fix this, we could set timeout and idle_timeout manually. However,
Soup.SessionAsync is marked as deprecated anyway and should be replaced
by Soup.Session. Doing so also sets a default timeout of 60 seconds.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2774
Removing a stylesheet from the theme will trigger a style update. There's
little point in updating the extension actors that are about to be destroyed
(hopefully), so call the extension's disable() function first.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2757
Sometimes an MPRIS media player will create and then destroy an object
before the signals that handle the object's destruction can be created.
This verifies that the object still exists after the necessary signals
have been created.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2776
Since commit 0ecddafc20 gsd-xsettings startup has been made conditional
on the systemd user instance being available at runtime. While that is
correct, it means that completing xwayland startup is also conditional
now.
We always want xwayland startup to go ahead, so wait for the XSettings
plugin to appear on the bus when gsd-xsettings is launched by gnome-session
and complete the task immediately if startup fails.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1252
Changing the icon to 'system-log-out-symbolic' has no visual
change in a default GNOME setup since both 'system-log-out-symbolic'
and 'application-exit-symbolic' are the same in adwaita-icon-theme
(at the time of writing), however, other icon themes differentiate
between the two icons so pointing to the appropriate icon name
is the right thing to do.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2751
Avoid starting/stopping the gsd-xsettings systemd unit if the shell itself
was not started via systemd. In the lack of a user session manager, we
have no means to neatly start/stop services, so should rely on the good
ol' gnome-session to do this for us.
This changes the return value meaning slightly, TRUE means "service did
start", FALSE otherwise. The error is only raised if we ought to start,
but it produced an error somehow.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1238https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2755
Commit 764527c8c9 not only ports this file
to Promises but also changes the behavior of _initPanelService method.
Instead of always calling _updateReadiness when _panelService is ready,
it only calls it when get_global_engine_async succeeds.
The only callers of _updateReadiness are _initEngines and
_initPanelService. Assume that _initEngines completes first. Its
_updateReadiness call keeps _ready as false and it is expected for
_initPanelService to change it to true. However, since
get_global_engine_async fails because there is no active engine,
_initPanelService never calls _updateReadiness. Therefore, all setEngine
calls do nothing because _ready is false, and the input method panel
never shows. Users are unable to use any input method even if they can
see that ibus-daemon is already running.
Fix the issue by changing it back to the old behavior.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1235
Since we now remove all theme nodes on a stylesheet change (ie.
StTheme's "custom-stylesheets-changed" signal) instead of only
invalidating them, those nodes may not be accessed anymore as soon as
"custom-stylesheets-changed" is emitted.
It turned out though that when comparing them to the newly generated
nodes in `st_widget_recompute_style()` using the
`st_theme_node_paint/geometry_equal()` functions, the properties of the
old nodes will still be accessed, causing a crash since the
CRDeclarations are already freed.
To fix that, keep the reference to the CRStylesheet, which owns the
CRDeclarations used by the theme nodes, around a bit longer, so it's
still possible to access the CRDeclarations inside the
"custom-stylesheets-changed" signal handler. This allows us to compare
the old theme nodes to the new ones since the CSS properties of both are
still valid.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2709
gjs has gotten less forgiving about missing getters/setters, and
commit 6aa1b817 missed the missing getter in the base policy class.
Most notifications use a policy subclass that already provides a
getter, but at least Main.notify() and friends don't; unbreak them
by fixing the base class.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1229
When a modal that's not on top of the modalActorFocusStack gets popped,
we shift the focus stack as described in popModal() to ensure the chain
remains correct. That however destroys the association of a modal actor
and its prevFocus actor on the focus stack, because the prevFocus actors
are now moved to different entries of the stack.
Now when a prevFocus actor gets destroyed, we don't handle that case
correctly and search for the modal actor that was associated with the
prevFocus actor before the stack was shifted, which means we end up
unsetting the wrong prevFocus actor.
So fix that and search the stack for the prevFocus actor which is being
destroyed instead to unset the correct entry.
Thanks to Florian Müllner for figuring out the actual issue and
proposing this fix.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2446
StThemeNodes are built around the assumption that they're "immutable",
that means they are created once with certain parameters (that resolve
to certain css properties) and then replaced with new ones in case those
parameters changed.
Changes to the internal information stored by theme nodes (i.e. the css
properties, font names or the cached scale-factor) are not all handled
the same though: For changes to the font or the scale-factor we remove
all theme nodes from the cache and let the widgets which are on stage
generate new theme nodes. For changes to the css properties/the
stylesheet, we invalidate the properties of all theme nodes but keep
them in the cache using `_st_theme_node_reset_for_stylesheet_change()`.
So be a bit more consistent and handle changes to the css-properties/the
stylesheet stored by StThemeNodes the same way as changes to the font or
scale-factor.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1218
Theme node invalidation stops at unmapped widgets, and widgets
that forget to chain up to the default ::style-changed implementation.
This may leave stale nodes that were invalidated on
StThemeContext::changed, but are still set on widgets, and maybe
used for CSS property lookups.
Make sure that theme node invalidation happens always by moving
propagation outside the vfunc, and ensure the theme nodes are reset
across the full actor tree. Emission of ::style-changed, and obtaining
a new theme node may be delayed till when the actor is mapped.
The theme node is also cleared after unparenting an actor to avoid
stale references.
This ensures that all widgets get their theme node cleared after
stylesheet changes, instead of maybe being left with a theme node
that's been cleared of all its properties.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2541https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1223
The workspace switcher blocks state updates while the indicator is
animating. Since commit 9c1940ef9d the indicator is considered to
be animating when the workspace adjustment's value doesn't equal the
active workspace.
There is one case though where this breaks badly: When a workspace
is inserted before the active one, the adjustment's upper and value
properties are changed without transitions. But if that change happens
while there's an ongoing transition to the previously active workspace,
the value gets out of sync with the active workspace and we end up
blocking state updates indefinitely.
Fix this by removing any transitions before setting the adjustment
value.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2625
Commit d76162c1c0 removed the ability to pass an extension UUID to
the Extensions app, when we moved the dialog to a portal and made
gnome-shell use it instead of spawning the extensions app.
However that missed that many extensions called out to the app to
open their own prefs.
While extensions are encouraged to switch to the new openPrefs()
convenience method added in commit 8030d9ad32, restore the old
behavior with a small script under the old gnome-shell-extension-prefs
name that either calls out to the portal or launches the app.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1220
We kept the old binary name when overhauling the tool for the Extensions
app to avoid unnecessary churn for packagers/distributors.
However we now have a reason to "free" the old name, so rename the binary
to match the (sub)project name.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1220
We override the :visible property for the keyboard actor, but don't
provide a corresponding setter. The property is therefore read-only
on the javascript level, and any attempt to set it will fail.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2691
Just as with the last commit, we should not break the assumption made by
Clutter that parents have their allocation set before their children get
allocated, so fix that here, too.
In this case we have to fix it by chaining up to the parent vfunc
override and updating the allocation once more before allocating the
`this._label` child.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/1615
It's important to update the allocation of the parent before allocating
its children, it's an assumption we make in a lot of places.
This broke resource scale calculation for boxpointers and their
children when multiple monitors with different scales are used and the
primary monitor is not positioned at x=0, y=0.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/1615
The session mode determines whether the screen casting should work or
not, but until now only dealt with the built in screen cast, not the
ones using PipeWire. Add the newly added API for inhibiting remote
access when the session mode says screencasts are not allowed.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1210
The template has been updated to rewrite the manifest to use the
checked out tree, so it's no longer necessary to pass additional
build arguments (which are now ignored) or generate translations
before the build (it's already in the manifest).
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1217
As of mozjs68 (gjs-1.64) `globalThis` is recommended over `window` and
it makes more sense in this context anyways. Migrate the few instances
of `window` we use and adjust the eslint configuration.
`window` will continue to resolve to `globalThis`, so this won't affect
extensions or other downstream users.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2322closes#2322
getEvents() filters all events for the given range and sorts the result.
That's more than we need when checking whether there are any events,
where we only care that there's at least one event in the range.
Address this by splitting out the event filtering into a generator
function, so hasEvents() can return after at most one iteration.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1192
We track messages so that we can account for just added and removed
events instead of having to rebuild the entire list, however it's
also possible that the time or summary of an existing event changed.
Account for that by updating existing messages in-place.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1192
We currently let the entry of the autoPrompt grab the key focus inside
setQuestion(), which is called from _onAskQuestion(), which is the
callback of the "ask-question" signal.
It seems that the "ask-question" signal isn't emitted again right after
the password-check failed, but a few seconds after that. Since we get
the "verification-failed" signal earlier than "ask-question" (right
after we know the check failed) and we also get a hint whether the entry
should be usable again with the canRetry argument, we can also grab key
focus to in the same step.
So do that by grabbing key focus when making the entry sensitive.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2655
The additional function UnlockDialog.addCharacter() is only used at one
place, so we can simply remove it and call AuthPrompt.addCharacter()
directly. The AuthPrompt is shown right before that anyway.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1209
Normally, we inhibit suspend while locking the screen. But in the
session mode used for gnome-initial-setup locking is not supported, so
in that case this inhibit call is pointless and should be avoided.
Without this patch you get the following error when you suspend and
resume during initial setup:
JS ERROR: Error getting systemd inhibitor: Gio.IOErrorEnum:
GDBus.Error:org.freedesktop.login1.OperationInProgress: The operation
inhibition has been requested for is already running
_promisify/proto[asyncFunc]/</<@resource:///org/gnome/gjs/modules/core/overrides/Gio.js:435:45
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1213
On Fedora 32 if you close the laptop lid during gnome-initial-setup,
gnome-shell hits this error:
JS ERROR: Exception in callback for signal: prepare-for-sleep: TypeError: this._dialog is undefined
_resetLockScreen@resource:///org/gnome/shell/ui/screenShield.js:434:9
activate@resource:///org/gnome/shell/ui/screenShield.js:571:14
lock@resource:///org/gnome/shell/ui/screenShield.js:617:14
_prepareForSleep@resource:///org/gnome/shell/ui/screenShield.js:219:22
_emit@resource:///org/gnome/gjs/modules/core/_signals.js:133:47
_prepareForSleep@resource:///org/gnome/shell/misc/loginManager.js:198:14
_emit@resource:///org/gnome/gjs/modules/core/_signals.js:133:47
_convertToNativeSignal@resource:///org/gnome/gjs/modules/core/overrides/Gio.js:169:19
This is because _ensureUnlockDialog() hit its first early return. So
return early from activate() in that case, so this._dialog doesn't get
used while it's null.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1213
StButton returns CLUTTER_EVENT_STOP in various circumstances, but
AppIcon throws that away and returns CLUTTER_EVENT_PROPAGATE even
when it should stop.
Return the parent class' result instead of CLUTTER_EVENT_PROPAGATE.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1211
I noticed the following warning while building the .deb package for
gnome-shell on Endless OS:
../src/st/test-theme.c: In function ‘main’:
../src/st/test-theme.c:549:3: warning: ignoring return value of ‘chdir’, declared with attribute warn_unused_result [-Wunused-result]
chdir (cwd);
^~~~~~~~~~~
(Of course this is very unlikely to fail in practice.)
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1208
These properties are never written; in the base class they are always
their default values, and in the subclasses the getters are overridden.
This will be necessary because GJS is adding checks to make sure that
readable properties always have a getter, writable properties always
have a setter, and that the variations of camelCase/snake_case are
handled correctly. It's supposedly backwards compatible, but that
assumes that code is not doing things like forgetting a setter on a
writable property. (If the missing setter had ever been called, it might
have led to a crash, which is why we've made this change.)
This is the minimally invasive patch which should work with both older
and newer versions of GJS. If you decide to require GJS 1.65.2, then
you'll also be able to remove the getters from NotificationPolicy as
well.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1205
We want the spinner to be centered with regard to the entry, but
constraining the height breaks that:
1. clutter_actor_allocate() is called with the available size
2. clutter_actor_update_constraints() then adjusts that according
to the constraints
3. clutter_actor_adjust_allocation() applies the margin/expand/align
properties.
The issue there is that 2. reduces the allocation to the desired size,
so there is no more extra space to distribute in 3.
We can fix this by either constraining everything (and rely on the
cancel button's alignment) or limit the constraint to the width. The
latter seems more appropriate, given that the constraint is only used
to center the entry horizontally.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2628
When handing the resetDialog request we're leaving a source ID alive,
leading this error:
(gnome-shell:22464): GLib-CRITICAL **: 17:46:11.065: Source ID 12934 was not
found when attempting to remove it:
== Stack trace for context 0x55c9246916c0 ==
#0 55c9249151b8 i js/ui/components/polkitAgent.js:391 (11f71fd544c0 @ 100)
#1 7ffc55140aa0 b self-hosted:1009 (3062ba49af88 @ 423)
#2 55c924915120 i js/ui/modalDialog.js:167 (1c9e50ae9880 @ 62)
#3 55c924915098 i js/ui/modalDialog.js:186 (1c9e50ae9970 @ 12)
#4 55c924915008 i js/ui/environment.js:75 (1c9e50a8d5b0 @ 98)
#5 55c924914f78 i js/ui/environment.js:149 (1c9e50a8d9e8 @ 14)
So, reset the source handle to avoid trying to remove it.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1203
Clutter.Animation doesn't contain any animation modes, they live in
Clutter.AnimationMode. The places we did `Clutter.Animation.WHATEVER`
just evaluated to `undefined`. Thus, use the correct namespace for the
animation mode enums.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1199
Translations are provided by .directory files, so trying to look
up a category name without the suffix will always fail.
Commit 343b3351f1 tried to fix this previously by changing the
saved keys, but that broke existing translatable folders.
Appending the .directory suffix for the lookup instead fixes the
issue without regressing non-custom folders.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2623
Right now, the actor hierarchy is such that the scroll view
does not contain the actual grid. It looks as follows:
StScrollView
↓
StBoxLayout
↓
ShellStack
↓ ↓
PaginatedIconGrid StWidget
This hierarchy can be slightly reorganized by changing it to be as
follows:
ShellStack
↓ ↓
StScrollView StWidget
↓
StBoxLayout
↓
PaginatedIconGrid
This will simplify future work where the PaginatedIconGrid will be
an implementation of StScrollable, in which case we'll be able to
simply remove the StBoxLayout from there.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1191
We currently always ignore the minimum width of the hint actor and
request/allocate the preferred width. This can be problematic with
labels with long text, where we should rather ellipsize the text
than allow the entry to grow indefinively.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2607
When creating an extension interactively, we currently always use
the default template unless the --template option is used.
Instead, display the list of available templates to the user and
prompt them to pick one if it wasn't specified.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/812
When we allow users to choose between different templates, we should
provide some context for each template to facilitate that choice.
Add that metadata in the form of a .desktop file, which allows us to
specify name and description, and is well supported by our translation
infrastructure.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/812
The template used when creating a new extension is intentionally
minimal, as the sample code in the old extensions-tool proved to
be annoying more often than not.
However as we support per-command options, we don't have to limit
ourselves to a single template, and can offer alternatives for
common use cases.
To prepare for that, namespace the existing template by moving it
into a subfolder.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/812
When using the create command's --interactive option, we prompt for
any metadata that wasn't passed on the command line. As every prompt
is preceded by a short multi-line description, it is hard to follow
when everything is lumped together.
Improve legibility by separating all prompts by newlines.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/812
If a search provider is installed by an app which is blacklisted for the
current user by their parental controls, don’t show it or results for
it.
Currently, this only filters ‘remote’ (not built-in to the shell) search
providers. This seems fine for now; in future it could be expanded to
also filter built-in search providers, if any of them end up needing to
be filtered.
No corresponding changes need to be made `remoteSearch.js`, because the
results of `loadRemoteSearchProviders()` are filtered in `search.js`.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/465
Filter the apps shown on the desktop and in search results according to
whether they are blacklisted by the user’s parental controls.
This supports dynamically updating the filter during the user’s session.
This adds an optional dependency on libmalcontent. If that’s unavailable, no
parental controls filtering will occur.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/465
While we now deal more gracefully with adapter removals, we can
still mess up the hadSetupDevices tracking:
As adapters become available before any devices, we'll always
reset the setting to false when Bluetooth is turned on. And if
no set up device happens to be in range, it will still be false
when Bluetooth is turned off again.
To address that, only update the setting if we have an adapter
(like we do now) and we had one before (so it wasn't the adapter
itself that changed).
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1174
Our intended behavior when bluetooth is turned off is to keep
the menu visible if devices had been set up previously.
However since gnome-bluetooth@c437c729, devices are removed
first before removing the default adapter, so we now end up
always setting the property to false before checking for it.
Fix this by deferring all model changes to an idle, so that
we can process them as a unit. Do the same for proxy property
changes, as those may trigger a row-removal.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1174
Since commit 26c2cb9f65, nDevices is always the actual number of
paired/trusted devices. So when bluetooth is turned off, it is
now 0 rather than forced to 1 if devices were set up previously.
Fix this by checking the property that tracks set up devices instead.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1174
When building the list of window PIDs, it's possible Mutter doesn't know
about the PID the client has and meta_window_get_pid() will return 0. We
should handle this case by not adding the PID to the list of PIDs
instead of adding an invalid one to it.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1184
MetaWindows get_pid() API changed to use the client PID, which also
works for Wayland clients instead of only X11 clients now. This API
returns 0 instead of -1 for invalid PIDs, so update our check according
to that.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1184
Pretty much the same case of the previous commit: we want this size
to be scale-dependant, and using the width and height properties of
ClutterActor doesn't automatically update.
Use CSS to set the width and height.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1176
Each node stores the scale factor in place when it was created.
Creating nodes with the same style, but with different scale
factors, yields different nodes.
Use the node's scale factor instead of retrieving the context's
one.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1176
Since commit 6a42d77261 we invalidate the
cached properties for each theme node on stylesheet changes by iterating
over the hashtable of the theme context instead of listening to the
signal in each individual theme node.
That commit forgot one particular node though that's not stored in the
hashtable, but using the `priv->root_node` property instead: The theme
node that belongs to the stage.
So make sure we also invalidate the cached properties of the stage theme
node on stylesheet changes. This fixes various crashes that happened
with extensions providing custom stylesheets (emitting the
"custom-stylesheets-changed" signal on every extension enable/disable),
trying to access an already freed CSS property of the stage.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2584
Just like StIcon does, we should use a container widget for the fallback
app icon that we get using the cairo surface property. It's needed
because the widget returned by shell_app_create_icon_texture() can be
resized freely, while we want the aspect ratio of the actual texture to
remain the same.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2578
Now that the extension preference dialog is opened by a separate
D-Bus service rather than the Extensions app, it can be opened
without a parent window that provides name and icon.
Fix this by adding back a hidden .desktop file.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2562
Commit 4589da957 added D-Bus API for enabling/disabling extensions,
use that if possible to provide better feedback and not clutter the
settings with non-existent UUIDs.
The old code path is preserved as fallback to keep the commands
working from outside a running shell session.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2391
UninstallExtensions() only returns whether the operation was successful,
not why it failed. However we know that only user extensions can be
uninstalled, so check that first to provide a more meaningful error.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2391
For the prefs command, we first fetch the extension info to check
whether the extension exists and actually has preferences. This
pattern can be useful for other commands and properties, so split
out a generic helper function.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2391
Error reporting is useful when used interactively, but often undesirable
when used in scripts. Account for that with a common --quiet option,
which is more convenient than redirection stderr to /dev/null.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2391
Predefined categories aren't a great way for organizing installed
applications, but they have their use in "stores" like Software
or flathub.
Not listing any category means we fall through the cracks, so
pick the (hopefully) least inappropriate one ...
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1160
Commit 7ff7fb5d3b forgot to clear the
`priv->icon_texture` actor when returning from st_icon_update(), which
means we don't always switch to an empty icon if both gicon properties
are set to NULL.
Fix this and destroy the actor before returning early from
st_icon_update().
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1178
The return value of st_theme_node_lookup_length() is scaled according
to the scale factor. IconGrid.ICON_SIZE is not. However, when BaseIcon
tries to fetch the CSS value for "icon-size" (which returns a scaled
value), it uses it as-is, mixing the two coordinate systems.
Use a single coordinate system (unscaled sizes) in IconGrid.BaseIcon.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1175
Usually the screen is woken up before the shield is deactivated, but
it is also possible to unlock the session programmatically via the
org.gnome.ScreenSaver D-Bus API.
The intention is very likely not to unlock a turned off screen in
that case. Nor does it seem like a good idea to change the lock
state without any indication.
Waking up the screen is more likely to meet expectations and is
more reasonable too, so do that.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1158
Commit c89d6a633 introduced a default fallback icon that would be displayed in
case the main gicon or the fallback gicon wasn't set or failed to load.
This broke the use case where a StIcon is created but no main icon or
fallback icon are set on purpose, for example the appindicator extension
which always creates a StIcon to represent icons in menu items but the
actual icons are only set if the application provides one, leaving the
menu showing the default fallback ("image-missing") icon for all menu
entries that don't actually have an icon provided by the application.
Fix that by only using the default fallback icon if the provided one
failed to load.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1173
Extension that want to expose their own preferences (for example as menu
items) do that by passing their UUID to gnome-shell-extension-prefs.
But since 3.36.1 the app is optional and no longer accepts arguments on
the command line. To adjust, extensions now need to make a D-Bus call
the extensions portal, just like the app and gnome-shell.
We will add a convenience method for that purpose, so it makes
sense to share the existing code. As it's extension-related, the
extension manager looks like the right place ...
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1163
A promisified method expects the callback parameter to be either
a function (in which case the original method is called normally)
or omitted altogether (in which case a Promise is returned).
The call to open application details in Software does neither and
passes null instead, which will result in a warning (because no
function argument means a promise will be used, but not omitting
the parameter means we end up with too many arguments).
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2551
The app-cache code currently stores the folder translations in a hash
that can be accessed via shell_util_get_translated_folder_name().
This hash uses the filename (inc. extension) for the "desktop-directory"
as key which causes an issue when trying to find the translation
on AppDisplay._findBestFolderName() which gets categories (folder names)
from the app info which doesn't contain the ".directory" extension.
Fix that by storing the filename without extension as the hash key for
the cached folder translations.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1168
In case where only one device is connected, we want to display its name
in the menu. For that we will need more than the number of known/connected
devices, so change the function to return an array of device infos instead.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2340
During the shell initialization we call the (deprecated) function to
override the Desktop environment in Gio DesktopAppInfo to make sure that
applications are correctly shown (as per commit b2fbf5a2), however this
might break the cases in which $XDG_CURRENT_DESKTOP is already set and
contains GNOME (given that is now a list).
In Ubuntu this is in fact set to: ubuntu:GNOME.
Now, if an application contains NotShowIn=ubuntu, the key will be ignored by
the shell, and the application is still listed everywhere.
So, override the DesktopAppInfo desktop environment only in the case that
the current desktop is not already GNOME.
At the current date I think we could just safely get rid of this override at
all, but there could be still cases where it still might be useful, like when
running as nested in some other environment, so keeping it.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1156
In some situations we could end up not with lingering 'view-loaded'
handler. This could result in delayed spring animate-in being initiated,
e.g. after a minute after the activities overview was already closed.
Fix this by removing any lingering signal or later handlers when
unmapping.
Fixes: 5c33fe4a0ahttps://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1155
Promises make asynchronous operations easier to manage, in particular
when used through the async/await syntax that allows for asynchronous
code to closely resemble synchronous one.
gjs has included a Gio._promisify() helper for a while now, which
monkey-patches methods that follow GIO's async pattern to return a
Promise when called without a callback argument.
Use that to get rid of all those GAsyncReadyCallbacks!
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1126
Starting the animation from the actor 'paint' signal has various
unwanted consequences, such as sometimes trigger a
clutter_actor_queue_relayout() during the paint phase. One unwanted
consequence was that an offscreen actor effect was disabled during
painting, meaning the effect would begin being active, but later during
the post-paint processing being disabled. The caused said effect to push
an offscreen framebuffer to the paint context, but then just destroy it
instead of popping it. When this happened, we'd end up trying to operate
on a framebuffer that may had been finalized, or not, depending on the
garbage collector. Sometimes, for some users, this caused a segmentation
fault when trying to pop a matrix from the framebuffer matrix stack.
Deal with this more properly, by using the 'view-loaded' signal to wait
with animation until the view is loaded, as well as using MetaLater to
schedule the start of the animation.
For when a view was signalled to be ready, we're in a state where we can
start animation before the next frame as the layout is ready, but when
not, we have to add back the "hack" where we must wait for one frame for
the target icon positions to be up to date. Do this by adding a
MetaLater IDLE callback that starts the animation *after* the next
frame. This also needs the old 'opacity = 0' work around to not show an
incorrect first frame.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2418https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1154
It seems reasonable that an entry shouldn't allow entering text when not
reactive. The same could be achieved by changing the text's :editable
property, however that will disable scrolling if the text doesn't fit,
which may result in an unwanted size change.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2423
The text is part of the entry, so it is surprising that it can
still be edited when the entry itself isn't reactive. Address
this by setting up a binding instead of expecting all consumers
to handle the case themselves.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2423
Set the do not disturb label as the label actor for the do not disturb switch,
so that Orca speaks the do not disturb label when the user moves
keyboard focus to the do not disturb switch.
Also enable toggle mode for the "Do Not Disturb" button and bind it's checked
state to the state property of the switch. This makes sure that Orca presents
thecorrect state of the do not disturb switch to the user.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2508
It seems there is a weird race condition between Clutter trying to
destroy the keyboard actor and Clutter trying to hide the keyboardBox
container actor: If the keyboardBox is hidden before destroying the
keyboard actor, Clutter doesn't repaint anything and the keyboard
remains visible until something else draws over it.
To fix this issue until we find the underlying Clutter bug, simply
destroy the keyboard actor before hiding the keyboardBox. The order in
which we call these doesn't matter anyway since hideKeyboard(true) hides
the keyboard immediately without an animation.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/1736https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1142
We're dealing with attached keyboards now using the touch_mode property
of ClutterSeat: If a device has a keyboard attached, the touch-mode is
FALSE and we won't automatically show the OSK on touches, also the
touch-mode gets set to FALSE when an external keyboard is being plugged
in, so that also hides the OSK automatically.
With that, we can now ignore keyboard devices when updating the last
used device and no longer have to special-case our own virtual devices.
Because there was no special-case for the virtual device we use on
Wayland now, this fixes a bug where the keyboard disappeared after
touching keys like Enter or Backspace.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2287https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1142
Since commit 2894085c45 we omit sound feedback on volume changes
if something is already outputting sound. Unfortunately that
"something" may be our own feedback (from a previous volume
change).
In that case we do not want to omit the new feedback, so instead
cancel the previous one.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1147
This is documented as a value between 1 and 65536. However we were passing
a 0 value for 100% transparent colors, which is interpreted as "system
inherited" in pango_renderer_get_alpha() docs.
Ensure we respect this range by specifying the minimum allowed alpha (1)
if the color is fully transparent. If someone notices this 1/65535th change
I'll ask him how many pleiades can he count.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2504
(yes, again).
The offset argument is changing from uint to int. Which means we
might would pass a negative offset and trigger an "out of bounds"
error. Make it work more or less alright with older mutters, by
clamping the offset to 0.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1146
Since commit 784c0b7e4 we use the name of the nearest city rather
than the weather station, as the latter tend to have unwieldy
and weird names.
However the nearest city may not be that near after all, in which
case the result is again surprising.
Address this by not using the nearest city name unconditionally, but
only if it appears in the station name.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2468
AuthPrompt is created on demand, and this._authPrompt is
expected to be null except on very strictly controlled
occasions. The idle monitor callback isn't one of them.
Check if AuthPrompt exists before cancelling it.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2371
We finally have everything in place for distributing the Extensions app
as flatpak without jumping through too many hoops. Add a manifest that
can produce a nightly build like other GNOME modules, and can serve as
a template for a stable manifest on flathub.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1133
The Extensions app code is now independent enough from the rest of the code
base to move it to its own subprojects, like we did for the extensions-tool.
This allows for stand-alone builds of the app, which we are about to use
for distributing it as flatpak.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1133
We include config.js because it is a dependency of ExtensionUtils,
but it's not actually used in the code paths we exercise.
As we want to allow stand-alone builds of the app, it is much easier to
fake the module than to either include a generated file from elsewhere
in the tree or generate it ourselves.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1133
Instead of adding a dragMonitor for every icon in the grid as soon as
one icon is getting dragged, only add a dragMonitor for the icon that is
currently being dragged over (ie. the current drag-target). With a large
number of icons in the iconGrid, this should significantly reduce lags
while dragging.
We can do this by detecting the DnD-entering of an icon or folder using
the `handleDragOver()` callback of drag-targets, adding the dragMonitor
because we know an icon is hovering above the drag-target and then
detecting the DnD-leaving of the drag-target by using the `dragMotion()`
handler, where we remove the dragMonitor again as soon as the
targetActor is no longer our actor (ie. the drag-target).
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/849
While it should be impossible to destroy a FolderIcon while a DnD action
is still going on, there might still be rare cases where this happens
(ie. when a folder is removed because an app got deleted during DnD).
So make sure we're on the safe side here and don't potentially leave
dragMonitors around after the icon is destroyed by removing the
dragMonitor inside the onDestroy handler of the FolderIcon, just like we
do for AppIcons.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/849
We want to completely clear the background framebuffer when switching
back to ACTOR mode to make sure the `background_fb.framebuffer` check
will fail in `update_background_fbo` when switching to BACKGROUND mode
again. Otherwise the checks in `update_background_fbo` will return TRUE
and we will keep using the background framebuffer that was created
before switchig to ACTOR mode.
While at it, also clear the background framebuffer completely when
changing the actor to avoid the same issue here.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1000
When blurring only the actor (ACTOR mode), we don't want to apply any
scale, it looks fine without using the resource scale and it also seems
like `clutter_actor_continue_paint` in `paint_actor_offscreen` only
draws an unscaled texture anyway (ie. if the resource scale is 2, only a
quarter of the framebuffer is being drawn to).
In BACKGROUND mode though, we need to scale the framebuffer using the
scale factor of the stage view (ie. the final scale factor for the
monitor) because the content of the framebuffer we blit is scaled using
that factor. Also, since the framebuffer we blit belongs to a stage view
and only includes the contents of this view, we need to adjust the
stage-coordinates of the actor to be relative to the stage-view.
To make sure we don't have to get the transformed actor size or position
multiple times during one paint-run and don't have to carefully floor()
or ceil() widths and positions, store the size of the actor (which is
also the size of the framebuffer) and its position relative to the stage
view inside a ClutterActorBox.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1000
A ClutterEffect is being painted as part of the paint cycle of
ClutterActor, where _clutter_effect_paint() is called before painting
the actual actor. With that, it's impossible that an effect gets painted
while it's disabled, so remove the check whether the ClutterActorMeta is
enabled before painting.
Also if everything works fine in Clutter, the ClutterActorMeta should
have an actor set and we've been notified about that actor in
shell_blur_effect_set_actor(), so assert that our cached actor is set
when painting the effect.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1000
Forward the arguments at the 'delete-surrounding-text' signal
from IBusInputContext to clutter_input_method_delete_surrounding()
so that ibus-typing-booster use the deleting surrounding text function.
Input method engines can delete the output text in applications
with this function.
This change will require a change of mutter of mutter!517
because the first arguemnt of the 'delete-surrounding-text' is INT
to express the offset of the current cursor position but
the first one of clutter_input_method_delete_surrounding() is UINT
since the Wayland spec accepts UINT in delete_surrounding()
mutter will change the type of the first one to INT in
clutter_input_method_delete_surrounding() to work with this change.
https://gitlab.gnome.org/GNOME/mutter/issues/539https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/477
We had various requests to improve existing OSK layouts, but
haven't accepted them so far as any changes would be overridden
when regenerating the layouts.
However as the upstream layouts at http://www.unicode.org are
extremely slow to update(*), we shouldn't block all improvements.
So instead of letting the update script override all existing
layouts, just make it import new layouts.
(*) not their fault, as the android layouts are a downstream to Google
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1136
The module was imported into the toplevel in !424, but that's at
least a bit weird:
- it's a helper script for one particular aspect (OSK layouts)
- it adds a README.mdwn to our own README.md, and a test/ directory
to our tests/
Move the whole thing to a subdirectory under data/, which is more
appropriate.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1136
Use a brighter color and increase the contrast of the selected/active
items in the switcher popup.
Since a bright color doesn't go well with a box-shadow, remove that
shadow, an effect like should only be used for elements clicked with a
mouse anyway.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1135
While we don't technically need the app to download and apply
updates, we do require it for notifying the user about available
updates and listing extensions with pending updates.
So instead of intransparently applying updates in the background
without the user noticing, disable updates altogether if the
Extensions app is not installed.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2346
Blacklist support was added all the way back in commit 1e286e43, but
the code had been defunctional until recently. While uninstalling an
extension that has been blacklisted makes sense off-hand, unfortunately
we don't know if an extension was *actually* blacklisted:
The website returns that operation for any extensions for which it
doesn't find any versions that match the shell version. That is, the
most likely reason is that the user updated to a new GNOME release
which the extension doesn't support yet.
It doesn't look like the website is going to change that behavior any
time soon[0], so drop the 'blacklist' handling for the time being.
[0] https://gitlab.gnome.org/Infrastructure/extensions-web/-/issues/95https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1132
Commit 55b57421d changed signal handlers to the corresponding vfuncs,
but didn't always chain up as necessary. In most places this doesn't
matter, but at the very least the commit broke activating message list
items via the keyboard.
Add all (hopefully) the missing chain-ups to get the expected behavior
back.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2319
Destroying the policy invalidates it, so accessing it from a
Source::destroy handler (for example to disconnect signal
handlers) currently results in warnings like:
Object .Gjs_ui_messageTray_NotificationApplicationPolicy
(0x7f8c7c0a64a0), has been already deallocated — impossible
to access it.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2238
The idea behind commit 3dd8ffc2bb to try harder to avoid empty
icon actors because of missing icons was sound, so implement that
behavior in StIcon itself:
If the main gicon was not found, and the fallback gicon isn't set or
wasn't found either, fall back to the standard 'missing-image' icon.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1127
The commit broke StIcon's :fallback-gicon property, as it relies on failure to load
an icon to determine that the fallback should be shown.
Luckily StIcon is the only user of st_texture_cache_load_gicon() (at least in
regular shell code), so we'll be able to implement the 'image-missing' fallback
there.
This reverts commit 3dd8ffc2bb.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1127
In order to support OpenExtensionPrefs()'s parentWindow parameter,
we will need the ability to make a window transient to an external
window identified by a string handle.
This takes the corresponding code from xdg-desktop-portal-gtk and
brings it into an introspectable form, likewise the counterpart in
libportal to export a string handle for a GtkWindow.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1087
Since PackageKit 1.11.1, the prompt to install updates on the end
session dialog has been (mostly) broken. The problem is that it only
works if PackageKit is running at the time the end session dialog is
opened; otherwise, our GDBusProxy has invalidated all of its properties,
which we read to see if update is possible. We need to autostart
PackageKit before reading its properties to fix this problem. That would
be easy if we were calling a method to see if an update or distro
upgrade were available, but since we're just checking a property, using
cached properties won't suffice. We'll have to manually check the
property value to ensure we autostart PackageKit.
Most of the code is written by Florian. Thanks Florian!
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/2276
Previously we'd show the system background and then wait till the
main loop was idle before beginning the shell startup animation.
This resulted in one initial frame that was always just the system
background.
Now we try to get both the system background and the startup animation
begun on the same first frame.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1102
In telepathyClient we consider messages both Tpl.TextEvents and
Tpl.Messages, and we manually create JS objects to copy the properties we
care for each one. This may lead to objects not matching the interface we
want.
Instead, use an object with construct-only properties and two factory static
methods to initialize it.
Unfortunately we need to use the ChatMessageClass for the class name or
calling the static methods would trigger a gjs error as per [1].
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1113
[1] https://gitlab.gnome.org/GNOME/gjs/-/issues/310
When mutter is acting as a display server it sets a number of
environment variables in the user's session. These variables
tell applications where the display server's sockets are.
When the shell exits at logout time it leaves these environment
variables in the systemd --user environment, which can confuse
subsequent sessions.
This commit clears up the environment on exit.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1129
We now warn on startup if screen locking isn't available, however for
users who choose not to use GDM or logind, repeating the warning on
each login is more annoying than helpful.
Instead, limit the warning to the first login on which the screen lock
became unavailable. That way the notification will still serve the
intended purpose of informing the user, but without being perceived
as nagging.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2432
Add a small helper method to asynchronously "touch" a file and return
whether the file was created or not.
As g_file_make_directory_with_parents() doesn't have an async variant,
we need a C helper to make the entire operation non-blocking.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2432
It's easy to forget to add a new <release> tag to the metainfo when
doing a new release.
Address this with an additional test if appstream-util is recent
enough to include the new validate-version command, so distcheck
fails when the metainfo wasn't updated.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1117
Rely on the Pango renderer handling this properly, instead of tinting
the full ClutterText in the color specified through css.
Also set the caret color explicitly, since it used to be set as a side
effect of clutter_text_set_color(), but no longer is.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/850
Commit da537cda43 moved the Shell.Screenshot API to GIO's async pattern,
but we never set the GError passed to the *_finish() functions and only
indicate failure by returning FALSE.
The expected behavior is to throw an error in that situation, so make sure
we do that.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1123
If a given icon is not available for neither the current theme nor any
of the fallback options (default theme -"Adwaita", "gnome"...), the
call to gtk_icon_theme_lookup_by_gicon() will return a NULL value, which
returned by the Shell Toolkit as is, causing trouble in the Shell's JS
code when calling shell_app_create_icon_texture() to create an icon.
To at least mitigate the chances of this having this issue happening, we
should at least try to load the standad 'image-missing' icon from the
Icon Naming Specification spec when we receive a NULL here, so that
at least we try to show something to the user, even if it's ugly.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1121
While sandboxing isn't a concern for the gnome-extensions command line
tool, using the Extensions proxy directly means that D-Bus methods are
called from the tool rather than gnome-shell, which allows the proxy
to auto-shutdown when done.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1106
As outlined earlier, in order to turn the Extensions app into a properly
sandboxed application, we need to split out the extension prefs dialog
and move it elsewhere.
With "elsewhere" being the new Extensions D-Bus service, effectively
turning it into a shell extensions portal.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1106
Similar to the previously added org.freedesktop.Notifications proxy,
this exposes the org.gnome.Shell.Extensions API and forwards any
request to the real implementation in gnome-shell.
The motivation differs though: We want to be able to package the
extension app as flatpak and distribute it separately, but the
extension prefs dialog is hard to impossible to sandbox:
- filenames need translating between host and sandbox, and we
can only do that in some cases (serializing/deserializing
extensions), but not others (extension settings that refer
to files)
- system extensions install their GSettings schemas in the system
path; the best we can do there is assume a host prefix of /usr
and set GSETTINGS_SCHEMA_DIR in the flatpak (eeks)
- extensions may rely on additional typelibs that are present on
the host (for example because gnome-shell itself depends on
them), but not inside the sandbox - unless we bundle all of
gnome-shell's dependencies
- if gjs/mozjs differ between host and sandbox, extensions must
handle different runtimes for the extension and its prefs
And all those issues occur despite a very permissive sandbox (full
host filesystem access, full dconf access, full org.gnome.Shell
access (including Eval()!)).
This new service will give us an alternative place for handling
the preference dialog:
- it runs outside of gnome-shell process, so can open windows
- it runs on the host, so the extension's prefs get to run
in the same namespace as the extension itself
That is, the service will provide portal-like functionality (albeit
not using the org.freedesktop.portal.* namespace, as extension
management is an inherently privileged operation).
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1106
We are jumping through quite some hoops to support showing only the
preference dialog when given a UUID on the command line.
As gnome-shell is about to stop calling out to us for the prefs dialog,
the reason for supporting this is going away, so remove all the special
handling.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1106
The dialog that contains the extension's preference widget has become
fairly complex over time, mostly due to the error handling.
It therefore makes sense to move it to a template, just like we did
for the main application window and extension rows.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1106
On X11, _onFocusChanged() updates the input region, as well as the
reactive-ness of the dialog's buttons.
That method is not only used as signal handlers (which are correctly
disconnected when the dialog is hidden), it also runs when the "show"
transition completes.
That's a problem if the transition is still ongoing when the dialog is
hidden, as it will then only complete when it is replaced by the "hide"
transition, after the this._dialog has been reset to null, and trying
to access the dialog's buttons results in an error.
Avoid this by explicitly removing all transition on hide before
resetting the dialog.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2467
Commit c1ec7b2ff meant to fall back to the base layout in case
a variant like `fr+oss` is set up, but as we are checking for
'+' on the array rather than the layout name, the fallback only
"works" for a layout that is literally called '+', whoops.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2471
Detailed notifications are meant to be single line, just as unexpanded
notification banners. So handle them the same way as in the message
list, and replace embedded newlines by spaces.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2463
We only show the list of system- and user extensions if corresponding
extensions are installed, however we only update the visibility
after loading the initial list of extensions.
As it's possible for the first user extension to be installed while the
app is open or the last one to be removed, we should also update the
list visibility after extension state changes.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1088
While we only shut down after a method call completed or (if the
interface has signals) the sender disconnects from the bus, services
may need to inhibit auto-shutdown for more specific reasons themselves,
for example when a method call kicks off an operation that should
complete before shutting down.
Add hold() and release() methods like Gio.Application for those cases.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1115
Whether we install bash-completion support currently depends on whether
the corresponding pkg-config dependency is found.
Turning this into a feature option keeps that behavior by default, but
also allows to explicitly enable or disable the support.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1072
I always forget to keep the extension-tool version number in sync when
doing a new release. Given that it's unlikely that I'll do much better
in the future by myself, make distcheck fail when the versions don't
match.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1076
Some timezones, like the one of Kathmandu don't only have hour-based
timezone offsets, but their timezones are also offset by minutes. So
instead of showing weird values like "+5.8", show the minutes properly
in a format like "+5:45".
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/2438
I misremembered that imports.package.start() would set up the correct
gettext domain, but the module only provides a convenience method
for doing that.
Use it to bring back translations in the Extensions app, whoops.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1108
Now that the org.gnome.Shell.Extensions interface exposes the
disable-user-extensions setting on D-Bus, we can use that instead
of the shell's GSettings.
In a future where we distribute the app separately as flatpak, this
will require one less hole in the sandbox.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1081
Using the "regular" loadInterfaceXML() helper means less code duplication,
but it also ties us to the resource used by gnome-shell.
In order to untangle the extension app from core gnome-shell, change that
to load the interface from the existing data resource instead. While that
does involve reimplementing loadInterfaceXML(), it's not too bad actually
with the resource-loading code stripped (as the data resource is already
loaded by the package module).
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1081
We want to make the extensions app code more self-contained to make it
easier to build separately, and ultimately make it available on flathub.
One complication we are facing is that it is currently all over the source
tree:
- js/extensionPrefs for the main code
- src for the launcher process
- data for .desktop file and icons
Switching from a C launcher to the imports.package module allows us to
consolidate the first two, and will also take care of the annoying
setup bits (defining JS search path, extending GI lookup, loading
resources).
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1081
Extension updates are installed at startup, so any errors that bubble
up uncaught will prevent the startup to complete.
While the most likely error reason was addressed in the previous commit
(pending update for a no-longer exitent extension), it makes sense to
catch any kind of corrupt updates to not interfere with shell startup.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2343
When an extension is uninstalled, there is no point in keeping
a pending update: If the update didn't fail (which it currently
does), we would end up sneakily reinstalling the extension.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2343
Doing blocking IO in a graphical UI is bad, doing it in the compositor
is much much worse. So even if handling VPN requests is a relatively
rare event, doing it asynchronously is better.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2386
While we can use the libnm API directly from JS, the call will
synchronously load the VPN service descriptions from disk.
Previously we were lowering the impact by caching the result,
but as we stopped doing that, it becomes more important to address
the issue properly and move it off to a thread.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2386
libnm doesn't only search for plugins in the regular VPN plugin directory,
but also in the legacy location and the directory pointed to by the
NM_VPN_PLUGIN_DIR environment variable (if set).
We don't monitor the additional directories, so it's possible for our cache
to become outdated.
Instead of trying to play catch-up with libnm's internals, do what nm-applet
does and use the appropriate API to look up the plugin on each request.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2386
checkForUpdates() will currently always query the server for updates,
even when passing an empty vardict of installed extensions. We know
there won't be any updates in that case, so avoid a pointless network
request.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1100
There are two ways for applications to provide a high contrast icon:
1. install an icon into the HighContrast theme
2. install a symbolic icon into the default hicolor theme
The latter is preferred nowadays, and implemented in the high-contrast
CSS variant by enforcing the symbolic icon style.
However together with the way we currently enable/disable high-contrast,
this can lead to the following race:
1. the GTK theme is changed from HighContrast
2. we reload the default stylesheet
3. the icon style changes to "regular", so we request a
new icon from the HighContrast icon theme
4. the icon theme is changed from HighContrast
5. we evict existing icons from the cache
6. we reload icons for the new icon theme; however as we
find a pending request (from 3), we re-use it
7. the request from 3 finishes, and we end up with a
wrong icon in the cache
The simplest fix is to change the icon theme before the GTK theme: Unlike the
theme name, the icon style is encoded in the cache key, so we won't re-use
an old (and incorrect) request in that case.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2414
The SignalQuality property is defined on the GDBusProxy, not the modem
JS object.
Fix this runtime warning:
JS WARNING: [resource:///org/gnome/shell/misc/modemManager.js 252]: reference to undefined property "SignalQuality"
JS ERROR: TypeError: this.SignalQuality is undefined
_reloadSignalQuality@resource:///org/gnome/shell/misc/modemManager.js:252:34
_init@resource:///org/gnome/shell/misc/modemManager.js:234:14
NMDeviceModem@resource:///org/gnome/shell/ui/status/network.js:517:34
_deviceAdded@resource:///org/gnome/shell/ui/status/network.js:1755:27
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1097
When launching the default calendar application, we special-case
evolution to make sure it starts up with the calendar component.
This is currently broken in two ways:
- evolution changed its .desktop file to use reverse DNS notation
- as evolution can now be distributed via flatpak, we can no longer
assume that 'evolution-calendar.desktop' exists when evolution does
(even though we ship the .desktop file ourselves, it is considered
invalid if the executable isn't found)
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1093
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
For sandboxed apps, permission to talk to org.freedesktop.Notifications
looks innocent enough. However as all exported services share the same
connection to the session bus, that permission actually grants an app
access to *any* shell D-Bus API.
While we want apps to use the notification portal, it is still common
for apps to use libnotify, raw D-Bus calls or even notify-send.
We don't want to give those apps a way to circumvent most of the sandbox
restrictions, so stop owning the org.freedesktop.Notifications name.
In a next step we will implement a separate notification-daemon that
exposes the API on the well-known address and proxies any requests to
the real implementation in gnome-shell.
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
Commit 88ac339774 changed StEntry behavior so the text hint would
stay visible while focused, as long as the text buffer is empty.
However, IMs that use preedit still should count as "started typing",
while the text buffer is still officially empty.
To fix this, check on st_entry_update_hint_visibility() that there's
indeed no preedit buffer before showing the hint. We can't directly
listen to internal preedit buffer changes in ClutterText, so handle
preedit buffer updates through the ::cursor-changed signal that will
be indirectly emitted.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1084
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
st_texture_cache_bind_weak_notify calls g_clear_signal_handler which
then calls st_texture_cache_free_bind. st_texture_cache_free_bind frees
the bind structure, so by the time g_clear_signal_handler tries to write
bind->notify_signal_id, bind has already been freed.
Fix this by using g_signal_handler_disconnect instead.
This partially reverts 135d178d08
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/2334
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
Some (newer?) GCC versions complain when a g_auto variable isn't
initialized when declared, even when the initialization is guaranteed
to happen before the variable is used or goes out of scope.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2298
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
Now that Xwayland startup is asynchronous, the function may be called
before X11 is available, resulting in a crash.
Fix this by only managing the tray immediately if we already have an
X11 display, and wait for it to be set up otherwise.
Likewise, unmanage the screen when X11 becomes unavailable.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2308
Since support for legacy status icons is implemented by extensions
nowadays, they need to undo the call to manage_screen() when they
are disabled.
Right now that means bypassing garbage collection with an explicit
call to run_dispose() on the Shell.TrayManager. That works, but is
rather ugly.
An explicit unmanage_screen() method is a nicer option, and will be
useful to us as well to deal with X11 going away (once Xwayland
crashes don't bring down the entire session).
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2308
NaTrayManager in particular is deeply tied to X11. We currently assume
that X11 support is always available, but that is already not true
anymore - Xwayland startup is now asynchronous.
It will be even less true once we handle Xwayland crashes gracefully.
Start addressing that by not creating the corresponding resources once
and assume they exist for the lifetime of Shell.TrayManager, but make
sure they exist when actually needed.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2308
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 g_file_replace_contents_async() API can potentially call fsync() from
the thread calling into it upon completion. This can have disasterous
effects when run from the compositor main thread such as complete stalls.
This is a followup to 86a00b6872 which
assumed (like the rest of us) that the fsync() would be performed on the
thread that was doing the I/O operations.
You can verify this with an strace -e fsync and cause terminal to display
a command completed notification (eg: from a backdrop window).
This also fixes a lifecycle bug for the variant, as
g_file_replace_contents_async() does not copy the data during the operation
as that is the responsibility of the caller. Instead, we just use a GBytes
variant and reference the variant there.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1050
Sadly, xgettext's dealing with template strings is abysimal, so we
had to stop using them in files with translatable strings.
Make sure we don't accidentally sneak in template strings again(*)
and enforce that rule in a CI job.
(*) easy "mistake", considering how much nicer they are than
String.prototype.format()
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1016
Also known as "Piotr Drąg Bot".
We will soon make sure that files processed by xgettext don't use template
strings. To make that check as adequate as possible, ensure that no source
code files are missing from POTFILES.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1016
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
While the old merge request URLs still work, gitlab recently started
including an additional /- for merge requests.
Adjust the regex to account for that, so that simply copying the URL
from gitlab works again.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1048
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
Commit 6c6c89c634 added a pill around the default avatar, but
assumed the sizes from the vertical widget used on the lock screen.
In order to fix the horizontal widget on the login screen, move the
size-specific bits to the corresponding .horizontal and .vertical
sections, and half the sizes for the former (which corelates with
the icon sizes).
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2242
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
Implement ClutterActorClass.has_accessible() to ensure that CallyActor does not
recreate accessibles during the removal/destruction of an actor. This relies
on GNOME/mutter!1083 for the ClutterActorClass.has_accessible virtual function.
Running GNOME Shell for about 30 seconds results in a difference between
the two runs.
Before:
ALLOCATED TOTAL FUNCTION
[ 52.2 KiB] [ 0.05%] cally_actor_real_remove_actor
[ 36.3 KiB] [ 0.04%] st_widget_get_accessible
[ 9.8 KiB] [ 0.01%] atk_gobject_accessible_for_object
[ 3.2 KiB] [ 0.00%] g_signal_emit_by_name
[ 2.9 KiB] [ 0.00%] clutter_actor_get_children
After:
ALLOCATED TOTAL FUNCTION
[ 1.8 KiB] [ 0.00%] cally_actor_real_remove_actor
[ 1.1 KiB] [ 0.00%] clutter_actor_get_children
[ 659 bytes] [ 0.00%] g_signal_emit_by_name
Obviously 50KiB isn't a huge savings.
Although fixing things to avoid re-entrancy on destruction can be very useful
from a correctness standpoint.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/2263
We turned both the auth prompt's cancel button and the switch user
button into icon buttons now, which means they are completely cryptic
when using a screen reader.
Just use the previously used labels as accessible names, which has the
nice side effect of lowering the impact of the string freeze break.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2210
The button is hidden on the lock screen, so it shouldn't be allowed to
activate it, be it via click or keyboard. The latter is still possible
by keynaving to the button and hitting space/enter. Fix that by making
the button unfocusable when we make it unreactive.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2210
ShellStack implements custom focus navigation, and will only ever
navigate into its top-most child. That kind of makes sense as long
as that child is actually visible, but not when it is hidden.
Descend into the stack to look for a focusable child instead.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2210
Since commit mutter/a2a8f0cda we force the focus surface of the
meta-wayland-pointer to NULL while the pointer is hidden. This
introduced an issue with the magnifier, where we use
`set_pointer_visible` to hide the real cursor and show our own cursor at
the correct position: Because the meta-wayland-pointer is still used to
communicate with Wayland clients, the UI of the windows will not respond
to mouse movement anymore as soon as the real cursor is hidden.
To fix this, use the newly added clutter_seat_inhibit_unfocus() API to
temporarily disable unsetting the focus-surface while the magnifier is
hiding the system cursor.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/993
If we are transitioning the label from 0 to its natural height, we
must set natural-height-set again after querying the preferred height,
otherwise Clutter would skip the transition.
However when transitioning in the opposite direction, setting the
property to true can go horribly wrong:
If the actor hasn't been allocated before, it will store a fixed
natural height of 0. But as there is no fixed min-height, we can
end up with min-height > natural-height, which is a fatal error.
(This isn't an issue when *actually* setting a fixed height, as
that will set both natural and minimum height)
So instead of always setting natural-height-set to true, restore
its previous value to fix the issue.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2255
repeatCount and autoReverse don't play well with animations disabled:
They cause password entries to wiggle themselves off-screen (by ending
up with some off-scale translation-x value).
While we should handle this more gracefully in the transition helpers,
it also makes sense to handle the case directly in wiggle(): As it
uses a chain of three transitions, we would still end up with a crude
one-frame-per-transition wiggle "animation".
Instead, do no animation at all as you would expect when animations are
disabled.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2236
Now that we apply a strong blur effect to the background, it doesn't
make too much sense to use a separate lock-screen background: It will
be mostly unrecognizable anyway.
The alternative would be to turn off the blur effect if a different
background is used (or have a hidden setting for that), but that would
then imply that we must keep the contents readable without blur.
Let's avoid that rabbit hole and just re-use the regular background.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1001
To bypass offscreening in cases where continuous animation is happening.
Offscreening is slower in such cases so this reduces the render time of
animations within offscreenable actors.
On an i7-7700 this reduces the render time of boxpointers for example by
25-30%.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1025
`-slider-handle-radius` is a floating point value and even in the default
theme it's not a whole number. Regardless of the fractional part that's
still going to occupy a whole extra pixel with antialiasing. So make room
for it. Otherwise it looks clipped, which it is by the Cairo context of
its `StDrawingArea`.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1569
Unused at the moment, but add the plumbing so that default key
definitions may specify symbolic icons that will be shown instead
of the text.
This is intended to replace the use of CSS and background-image
to handle those buttons with an icon.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2214
While the gsetting is available for all who needs it, the Shell might
override it given various hueristics. Expose the decision made by the
Shell via a new property.
Intended to be used by gsd-xsettings as well as xdg-desktop-portal-gtk.
This also add a version property to the API, so that semi external
services (xdg-desktop-portal-gtk) can detect what API is expected to be
present.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/757
For reasons not yet fully understood, `Main.uiGroup.add_actor` takes around
10 milliseconds to complete.
Because of this, each `actor.opacity = 0` has a good chance of falling
on a different frame. And when it does, `_opacityChangedId` also lands
on multiple different frames each incurring a separate relayout cycle.
It is this excessive number of relayouts that causes stuttering in the
icon grid animation (#2065). But it is the slowness of `uiGroup.add_actor`
that causes the number to be excessive when it should be one.
By creating the clones and adding them to `uiGroup` early, we then enable
the existing loop starting the animation to complete within a single frame.
And by completing within a single frame all the opacity changes land within
the same frame interval, thus incurring only a single relayout instead of
many.
This issue went unnoticed until 004a5e1042 (!704), after which the slow
emissions of `notify::opacity` became a more visible performance problem.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/2065https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1002
Now that the bind constraint changes the preferred size of
the actor, a major flaw in the AppDisplay code was exposed:
the folder dialog depends on the preferred size of a parent,
and the parent depends on the preferred size of the folder
dialog.
While we know this is not actually true, we shouldn't rely
on broken behavior to achieve this result. What's interesting
is that the bind constraint used by the folder dialog is a
relic of the development phase; we now control the position
and size of the dialog with a combination of CSS, and alignment.
Remove the unnecessary bind constraint.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1027
Since the design of the notification popup changed with the theme
refactor and there are now boxes around the world-clock and weather
sections, the overlay scrollbar that is shown above them looks rather
bad. So simply hide that scrollbar, we still have the vfade effect to
indicate the container is scrollable and we also depend on that in the
new popup app-folders.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1013
Make sure the stylesheet properties of the window-chrome title are
updated before requesting the preferred width of the title to prevent
size changes of the title after we animated the width.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/58
Remove the default icon size of -1 and always set the container StBin to
a real size. This fixes an error where the "width" and "height"
properties get set to -2 (which is -1 * scaleFactor) in the `_init`
function.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1018
To make sure the GC really disposes the KeyboardController object we
need to remove all references to the object, which means we have to
disconnect signals the object connects to, too.
This also fixes a bug where keys remain pressed forever and thus also
break that key on real keyboards. It happens if the OSK gets destroyed
during an OSK-key is being held so the StButton of the key is not
released. That means the key remains pressed in the
MetaVirtualInputDevice that we are now leaking because
KeyboardController isn't garbage collected.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1015
xgettext gained some support for template strings, and no longer
fails when encountering '/' somewhere between backticks.
Unfortunately its support is still buggy as hell, and it is now
silently dropping translatable strings, yay. I hate making the
code worse, but until xgettext really gets its shit together,
the only viable way forward seems to be to not use template
strings in any files listed in POTFILES.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1014
Since quite a few strings of dialogs provided by external programs are
not updated yet and the string freeze is already in effect, make sure we
don't break those dialogs by stripping aways large parts of the
headline.
To do that, detect if the title label is larger than the available width
and if it is, switch to a smaller font-size of 13pt. This makes sure we
still show about the same number of characters in the headline as we did
in previous releases.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1012
With the old screen shield, we were simply hiding the lightboxes to show
the shield when the user became active after activating the shield but
before locking the screen (that is, when using a lock-delay).
However now that the shield is gone, we end up showing the unlock dialog
even though we are not actually locked.
We probably don't want to add back a shield-like mode (that is, a way to
raise the unlock dialog without authentication when we aren't locked),
so just deactivate the whole shield when the user becomes active again
before the lock kicks in.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2213
The design team discussed the ellipses at the end of the hint text of
our entries and, even though they are present in most mockups, it turned
out they don't like them, so remove them.
It also turned out they don't like the prefixes like "Enter" before it,
so remove those, too.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/977
With the new dialog design the descriptions of entries are now
implemented as hint-text of the StEntry. That means the colon at the end
of the descriptions no longer makes sense and should be removed.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/977
Currently separators get all the padding from regular menu items,
which is excessive for non-interactive elements.
Shuffle style classes around a bit to allow overriding the normal
padding for separators.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1004
Shift, caps-lock and friends change the capitalization of following
key presses. It is unexpected for those keys to have side-effects,
so don't switch to the prompt when they are pressed.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2215
We don't want to show a caps-lock warning when showing a non-password
entry, but we also don't want the layout to jump when changing the
label's visibility.
Achieve that by inserting an empty placeholder label that we can
show whenever the caps-lock warning is hidden.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2215
The promptBox is initially fully opaque, so showing it before the
transition can result in a brief flash before fading in.
Just remove the show() call and let the transition handle the
visibility.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2212
Usually, logging in or unlocking the session is made asynchronously,
and AuthPrompt properly manages which entry is currently visible.
External code don't rely on any specific entry to be set, since it
is AuthPrompt's responsibility to select the correct one to be shown.
However, there's one specific case where AuthPrompt must preserve
the password entry: on reset. The reset code preserved whatever
entry was currently displayed, but after fe69dacaf1, it always
changes to the username entry.
Make sure to show the password entry on reset.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/999
In the past, the session menu button was part of the auth prompt widgetry,
so we didn't have to manually hide it when showing the user list. However,
now it is part of the login screen itself.
Hide the session menu button when the user list is shown.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/999
In the common case where we only have a single unread notification
from a particular app, the count doesn't add useful information.
Reduce clutter a bit by only showing the notification count if we
have at least two.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/997
Instead of alphabetical ordering, sort the widget stylesheets
from more global to more local while grouping related things.
This helps reduce unintended behaviors and ugly overrides and
make styling and debugging easier.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/938
Clicking or typing to reveal the auth prompt are good options for
mouse/keyboard workflows, but awkward on touch devices. Now that
we have SwipeTracker, adding corresponding gestures support is
easy, so do just that.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/972
The current transition between clock and auth prompt uses a simple
crossfade.
"What kind of spatial model is that?!"
T.B.
Root the transition a bit more by adding translation and scale to
the animation.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/972
Hiding the Caps lock warning label changes the layout of
Auth Prompt. This is specially noticeable when logging in
with unlisted users, where we change the visibility of this
label after typing a username, and the whole user widget
moves a bit.
Change the Cap lock label's opacity instead of hiding it.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/922
Currently, when a null user is passed, we don't add any
username label. That makes the layout of user and no-user
cases inconsistent.
Add a ghost label with no opacity to mimic the username
label.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/922
Currently, AuthPrompt is connecting to its own 'next' signal
signal to react to any of the entries being activated, and do
some actions like starting the spinner and answering the PAM
question.
Refactor this code into another method, and don't connect to
our own signal.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/922
Unfortunately, the question that is displayed comes directly
from PAM. It usually is just "Password:", which comes from
pam-unix, but other questions can be set, usually with the
colons, since they are crafted with a CLI workflow in mind.
Manually drop the colons from questions asked by PAM. This
is also done by the PolKit agent, which shows how the stack
is fragile, but it's what we have for now.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/922
This is a regression from the transition to password entry. Both
entries need to be connected to the relevant signals, otherwise
username-based login won't ever work.
Connect both the text and the password entries.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/922
Currently, there is a dedicated label above the entry to
display the question text. According to the new mockups
for the lock screen, this label doesn't exist; instead,
the question is set inside the entry itself, as a hint
text.
Set the questions as hint texts of the entry, and remove
the now unused label.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/922
If username-based login flow is followed, we need a default avatar
for the userWidget. Hence, check if the user passed to userWidget
is (null) which implies a username-based login flow.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/922
Allow vertical orientation for the userWidget so that the user-avatar
can be centered and user's name can be placed below it. The plan
for 3.36 is to use this vertical userWidget layout for both lock
and login screen.
The userWidget is also used while creating the user-selection list
at the login, hence we still need to keep the horizontal layout
for userWidget in place.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/922
Since the blur sigma decides how many pixels get factored in when
blurring and setting a scale factor increases the background texture by
that factor, the sigma value should also be multiplied by the scale
factor.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/991
If we modify the paint volume to make it larger and include the blur
radius, we should also use the gained size and draw something there.
Since the framebuffers are only the size of the actor to blur, we're not
doing that right now anyway, so remove the vfunc override.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/991
Use the shader for linear sampling and incremental calculation of the
gaussian kernel values as it was implemented by Patrick Walton in
webrender.
The sigma value for the blur (the standard deviation) is calculated by
taking the blur radius and dividing it by 3, this value is used by most
implementations of gaussian blurs since it covers a high percentage of
the gaussian shape.
The linear sampling optimization is implemented by skipping every second
texel (i += 2) in the for-loop that's sampling adjacent texels.
https://github.com/servo/webrender/blob/master/webrender/res/cs_blur.glsl38ec7db6f1https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/991
Floor the downscaled size of the new framebuffer to make sure we don't
initialize a framebuffer with a floating point value that might be
interpreted wrong by `cogl_texture_2d_new_with_size` and end up with a
slightly wrong aspect ratio of the framebuffer.
This fixes situations where the widths or heights of downscaled
framebuffers sometimes miss some pixels at the border.
While at it, remove the `downscale_factor` argument from
`setup_projection_matrix` since that function doesn't need the initial
size of the actor anyway.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/991
Now that we support extension updates, it may be useful to list
pending updates from the command line. It's easy enough to support,
so add a corresponding option to the list command.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/988
There is nothing else to be focused in the lock screen itself -- the
top bar is already handled elsewhere, and the dialog manages itself
now.
Remove the lock screen group from the Ctrl-Alt-Tab manager.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/872
AuthPrompt is the set of actors that contain the user avatar,
the username, and the password entry. With the removal of the
screen shield, the unlock dialog (be it UnlockDialog or the
LoginDialog) is always created, and in the case of UnlockDialog,
so is the auth prompt.
This is problematic, though, since for passwordless accounts,
the simple act of creating AuthPrompt authenticates the user,
and lifts the lock screen.
Create the AuthPrompt on demand in UnlockDialog.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/872
As per the latest lock screen mockups, critical notifications must have
a more prominent, solid color.
Add a .critical style class to critical notification bubbles, and make
them darker.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/872
Now that the screen shield is gone (at least, as it used to
be), the corresponding session mode is not necessary anymore
as well.
Remove the 'lock-screen' session mode, and the corresponding
CSS.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/872
Pretty much what the commit title says.
This gives the lock shield actor another role: instead of
being the interactive screen shield, make it the invisible
actor that prevents interacting with windows while the
unlock dialog is sliding down.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/872
Activating a dialog is slightly different from opening it; the
former is about showing the user authentication widgetry, while
the latter is about creating it and pre-allocating the necessary
resources.
Activate the screen shield dialog when necessary.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/872
The 'onPrimary' argument was being passed to dialog.open(). Turns out,
neither UnlockDialog nor LoginDialog use this parameter.
Remove the unnecessary 'onPrimary' parameter, and cleanup the related
code.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/872
The use of the core idle monitor means that focus change events
are also delayed by keyboard interaction. Since the magnifier is
already in the business of pointer tracking, it's easy enough to
fire the pointer rest timeout from here, so focus changes are
accumulated and delayed.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/984
We may get several a11y events setting the caret on the same
coordinates it previously was. Make focus tracking ignore those,
as we're jumping to the same coordinates again during eg. mouse
operation.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/984
If the crosshair is clipped so it doesn't cover the pointer cursor,
the clip rectangle is skewed towards the bottom/right. This was
made so to accomodate the default pointer, but the unevenness stays
on other pointer cursors, and it makes the crosshair look odd on
short crosshair length.
Make all lines clip to an even distance from the center instead.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/984
It is somewhat unexpected that crosshair color and pointer cursor colors
remain the same across changes in color inversion settings, and may lead
to contrast issues. Apply the effect on the common container, so it
applies to these all.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/984
If the icon proper has opacity of zero then that's probably because a
clone of it is animating. So avoid animating the source actor too.
And if there's any other reason for the opacity being zero, still don't
animate it because we can't see it :)
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/2167
So as to guarantee the unmapped state sticks and doesn't get toggled
back to mapped before we return.
Being in a mapped state when `FolderIcon.vfunc_unmap()` returned was
causing an assertion failure in `clutter_actor_set_mapped` and crashed
the shell.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/2170
The inconsistent styling rules "some card styles are nested, but some
are not" and "some card styles are nested, but some of their descendant
styles are defined elsewhere" are very confusing.
This commit stops nesting all card styles to make the coding style
consistent and less confusing.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/957
- Remove bottom blank space on the right column of the calendar popover
so that the weather card is bottom-aligned with the clear button on
the left column.
- Remove top blank space on the left column of the calendar popover so
that the message list is top-aligned with the today button on the
right column.
- Adjust .message-list-controls sizing to align with other card-styled
elements.
- Use regular `spacing` instead of margin for some spacing.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2088
Closes https://gitlab.gnome.org/GNOME/gnome-shell/issues/2120
- Use fewer properties for layout.
- Use .message-body instead of .message-content to change the body
color, and remove some color overrides.
- Fix border-radius for last .message-media-control, not only on hover.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/957
- Remove margin-bottom for StIcon, which is not only ineffective, but
also created a bug in app folders.
- Remove ">" which is invalid for overview icons that are not app
folders.
- Apply spacing to the correct target "StBoxLayout", not the parent
.overview-icon.overview-icon-with-label.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/2129
The used_scales hash table uses g_double_hash and g_double_equal which
try to read a double from the passed pointers. The pointers however were
pointing to a float, leading to an invalid read.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/974
The portal helper is rather sensitive because potentially-hostile Wi-Fi
networks can decide to launch it whenever they want (by blocking the
user's connection to the nmcheck domain) and load whatever web content
they want into it. So having this unsandboxed is really extraordinarily
risky. Previously it was a risk we had to accept, because WebKit did not
have a web process sandbox, but now it does. So let's bubblewrap all the
things!
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/983
- the plan was to drop the frequent/all view switcher, thus sam didn't
pay too much attention to the button styling for those. Sadly the view
switcher remains, so we should keep the old subtle styling intact.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/979
Commit 147a743d8d moved the suspend and power-off actions into
the submenu that contains the log-out and switch-user actions,
but did not update the submenu visibility logic to account for
the additional actions.
As a result, the submenu is hidden when log-out and switch-user
are unavailable (like on the login screen), even if suspend and
power-off are enabled.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2169
While gnome-shell will now check for extension updates, the checks
are performed infrequently. Opening the Extensions app implies that
the user's current focus is on extensions, so it is an appropriate
time to schedule another updates check.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1968
Now that we can download, apply and display extension updates, it is time
to actually check for updates. Schedule an update check right on startup,
then every 24 hours.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1968
Now that we have support for extension updates in the shell, we
need some place to display the updates to the user.
As we are establishing the Extensions app as the primary way for
managing extensions, it's a natural place for that functionality.
Show which extensions have updates available, and offer a log out
button (so gnome-shell can apply the updates when logging back in).
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1968
Until now, it didn't matter whether an extension was installed in the
user's home or system-wide. However with support for uninstallation,
there is now a significant different, as that action is only available
for user extensions.
Account for that by separating extensions by type, so that users don't
have to second-guess which extensions can be fully-managed and which
appear as part of the system.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1968
The newly added expander gives us a place where we can display
more details without cluttering the interface.
Take advantage of that by including the extension website, version
and author.
(Author is in the mockups, but will not actually be shown until
the extensions website is changed to include it in its metadata;
however best to have UI and string in place for the freezes)
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1968
The description can be useful information, but also increases the
visual complexity of the extensions list. Move it into a hidden
details area that can be expanded, which unclutters the interface
while keeping the information readily available.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1968
The current fixed two-line label requires a custom widget, which
make moving to a widget template harder.
As the description will soon move elsewhere anyway, just go back
to a single line with a standard label for now.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1968
Extensions can have a major impact on stability and performance. Now that
the tool will become the main way for users to manage their extensions, it
is an appropriate place to warn the user of that risk.
Add a small info popover to the headerbar to display that warning, together
with the previously removed hint of where to go for finding new extensions.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1968
Currently when the extensions list is scrolled, it is possible to
keynav out of view, as the scrolling doesn't follow the key focus.
Hook up the adjustment to fix that.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1968
Currently the main window is a plain Gtk.ApplicationWindow that is
built and managed from within the application.
As the application becomes more complex, it makes sense to decouple
the two and handle the window from a separate ExtensionsWindow class.
Not least this is a prerequisite of using a widget template for the
window.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1968
GNOME Software will remove its extension support, so we should stop
referencing it in addition to extensions.gnome.org.
In fact, the placeholder is not the best place to hint at where new
extensions can be found, as the user will never see it in case the
distribution includes pre-installed extensions.
So remove the hint altogether, we will add it back in a more prominent
place later.
With the whole placeholder now being much lighter, we can stop dimming
the remaining elements.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1968
If all password entries in dialogs are hidden, there is either an entry
that has visible characters or no entry at all. That means we don't have
to show the caps lock warning at all, so hide it.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/942
Since the headlines of the dialogs now use a much larger font, the
strings need to be shorter so they won't be ellipsized. So use a shorter
strings for those titles and also adjust the title-strings of the
notifications sent by the NetworkAgent to be consistent.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/942
Since the wiggle effect will be used by the redesigned prompt-dialogs
and we always want to use the same parameters, move those as defaults
for the wiggle function to the util.js file.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/942
Since the caps-lock warning adds a lot of spacing to dialogs and the
lock screen, hide it by default and only show it when necessary. To make
the transition smooth instead of just showing the label, animate it in
using the height and opacity.
Also add some bottom padding to the label so we can show or hide that
padding, too.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/952
The caps-lock warning is more related to entries than dialogs and is
also used in gdm, which is not realated to dialogs at all. Rename the
css class to caps-lock-warning-label and move it to the entry
stylesheet.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/952
The Animation class inherits from St.Bin and manages the scale factor
in the image loading, but the widget size doesn't change and doesn't
depend on the scale factor so when the scale factor is different
from 1 the widget size doesn't match the image size.
This patch resizes the Animation widget using the scale factor so the
widget will match the animation images sizes.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1746
Now that we have a way to check for updates and download them, we
should actually apply them as well. Do this on startup before any
extensions are initialized, to make sure we don't run into any
conflicts with a previously loaded version.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/945
While it is possible that an extension has a newer version available
than the previously downloaded update, it's more likely that we end up
downloading the same archive again. That would be a bit silly despite
the usually small size, so we can either use the metadata from the
update, or exclude the extension from the check.
The latter is much easier, so let's go with that for now.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/945
Currently the method installs updates instead of merely checking for
them (or it would do, if it actually worked).
This is not just surprising considering the method name, the whole idea
of live updates is problematic and will not work properly more often
than not:
- imports are cached, so any local modules will stay at their
original version until a shell restart
- GTypes cannot be unregistered
So change the method to only download available updates, and set the
extensions' hasUpdate state accordingly.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/945
The current support for extension updates is half-baked at best.
We are about to change that, and implement offline updates similar
to gnome-software.
As a first step, add a hasUpdate property to the extension state
which will communicate available updates.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/945
Since a11f417cd0, both drag and scroll
gestures are added to Main.layoutManager.overviewGroup actor, while
previously drag gesture was added to Main.overview._backgroundGroup
instead. Since we cannot use 2 different actors for dragging and scrolling
anymore. just disable the swipe tracker while dragging a window.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2151
Since the orientation lock menu entry is a proper menu entry instead of
a icon-only button now, we also show a description-text for that entry,
so update this text depending on whether orientation is locked or not to
better reflect what clicking the menu entry will do.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/964
Since we don't really know what the buttons we're adding to the dialogs
are about, we can't configure a button to "be clicked" when the escape
key is pressed. So add a separate escape key handler to fix that, return
-1 and abort the request.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/961
When updating the buttons of the mount dialogs, compare the new buttons
to the old ones and only create new buttons in case something changed.
This makes sure key focus isn't reset or lost unnecessarily while a
dialog is opened.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/961
Since there is a generic layout for dialogs like that now, use it. Also
remove the functionality of focussing a window when clicking a list
item, it's not discoverable at all and pretty unexpected.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/961
`gnome-shell-perf-tool` is initially designed to run on X11, using the
`--replace` option which does not work when gnome-shell is a Wayland
compositor.
A solution would be to run `gnome-shell-perf-tool` in place of just
`gnome-shell` to run the entire perf session under Wayland, but the
script `gnome-shell-perf-tool` does not spawn `gnome-shell` as a Wayladn
compositor, so that fails as well.
Add a `--wayland` option to `gnome-shell-perf-tool` so that it can
optionally spawn gnome-shell as a Wayland compositor so the whole perf
tool can be starred from a console with:
```
$ dbus-run-session -- gnome-shell-perf-tool --wayland
```
Alternatively, for testing purposes, it can also be started nested with:
```
$ dbus-run-session -- gnome-shell-perf-tool --nested
```
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/2139https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/941
On Wayland, the display server is the Wayland compositor, i.e.
`gnome-shell` itself.
As a result, we cannot spawn `gnome-shell-perf-helper` before
`gnome-shell` is started, as `gnome-shell-perf-helper` needs to connect
to the display server.
So, instead of spawning `gnome-shell-perf-helper` from the perf tool,
start it from `gnome-shell` itself.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/941
For window-backed apps (read: windows we can't match to a .desktop
file), we use the window's icon property as icon. However there is
no such property on wayland (at least in the protocols we support),
so we end up with a blank actor in that case.
Do better than that, and pick a generic fallback icon instead.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1779
Notifying the "text" property inside `st_entry_set_text()` misses all
the text changes done by ClutterText itself, including those that happen
on key-presses. Fix that by notifying that property inside the
"notify::text" handler connected to the ClutterText.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/951
Also show the hint actor of an StEntry while the entry is focused but
has no text inside it. This is part of the new dialog and lock-screen
design where there are no labels before entries anymore and labels are
instead shown as a hint-text of the entry.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/944
set_fallback_icon_name() leaks a GIcon by using the set_icon method
which adds a ref to the GIcon without removing its own ref after calling
the method.
Related to https://gitlab.gnome.org/GNOME/gnome-shell/issues/2146
When do-not-disturb is enabled, non-critical notifications will not
be shown as banners. It therefore makes sense to indicate that state
to the user, so they don't accidentally miss notifications.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/239
Currently the indicator pad requests a size of 0x0 if the corresponding
indicator is hidden. Right now this is enough to balance out the indicator,
but it won't be when we add spacing to the parent container.
Properly hide the pad with the indicator to avoid that issue.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/239
We've had the ability to temporarily disable notification banners
all the way back to 3.0, but we stopped exposing it in the UI with
the 3.16 notification redesign. With the message list being more
concise nowadays and the "Clear" button reduced to a single icon,
we now have space for a "Do Not Disturb" switch again.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/239
We try to make the OSK 1/3rd as big as the monitor. On landscape
layouts we usually get away with it as there's plenty of horizontal
space to enlarge the OSK while keeping the OSK aspect ratio.
In portrait layout, the horizontal space is a lot more scarce so
it means we'll still have plenty of space after making the OSK as
wide as it can possibly be, which will look as odd blank space in
the OSK panel.
In order to fix this, let the OSK panel height be less than 1/3rd
the monitor size if we are dealing with portrait layouts.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/2132
It will happen before next map anyway, and most notably at times
actor sizes produce correct results.
Fixes oddities in emoji pager visibility after showing the emoji
panel, moving to another page, and hiding the OSK with the downward
arrow button. The next time the emoji panel would be shown, panels
had a chance to remain invisible.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/943
It is already scheduled to be set on first map. Doing so here triggers
size and theme node checks the actor tree is not ready for, as the
toplevel actor is not yet attached to the stage.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/943
This functionality always suffered from discoveribility
problems, and now that the folder dialog can rename the
app folders, there's just no reason to keep it.
Remove the rename popup.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/896
Now that the folder dialog handles the adaptToSize workaround,
there is no need to propagate the call throughout the class
hierarchy.
Remove the propagating calls to adaptToSize, and all the satellite
code.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/896
Now the the folder popup behaves like a dialog, it must be
above the app grid, and not be affected by the scroll view
translation.
Add the folder popup to the AllView itself, instead of the
internal Shell.Stack that is inside the scroll view.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/896
Make the AppFolderPopup behave much more like a dialog than a
popup itself. To do that, remove the BoxPointer and replace it
by a StBoxLayout. The dialog is is also bind-constrained to the
view selector.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/896
St has the regular abstractions to handle actors that are bigger
than their parent could handle: StScrollable, StScrollView, and
StAdjustment.
However, the only StScrollable implementation available currently
is StBoxLayout, which forces a ClutterBoxLayout as the layout
manager (and relies on it not being unset).
Introduce StViewport, which is a minimal StScrollable implementation
that doesn't rely on any specific layout manager.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/929
Since the overview search results now have a dark background layer, we
can brighten the background image a bit again. As a factor we use 0.5,
since that ensures the texts in the IconGrid are still readable and the
background image is visible, too.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/2133
If a new SwitcherPopup is created and there are no windows or apps to
switch through found, instead of returning from _init(), still
initialize the SwitcherPopup and let the check in SwitcherPopup.show()
return false to terminate the popup.
In both cases, with or without the return statements,
WindowManager._startSwitcher() will call SwicherPopup.destroy(), which
will try to disconnect signal handlers, destroy actors etc. Now if the
constructor can't finish creating the popup, some of the functions
called from _onDestroy() will fail and throw errors.
One of those cases is when window-switcher is limited to the current
workspace, and a WindowCyclerPopup is initiated on an empty workspace.
Because this._highlight hasn't been created, _onDestroy() will fail when
trying to destroy the actor of this._highlight.
Also, the actor of this._switcherList will not get destroyed in case
show() returns because this._items is empty. For example, this will
happen when a new AppSwitcherPopup is initialized with at least 1
running app, but 0 windows on the active workspace.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/168
Instead of removing all button shadows forcibly with
`box-shadow: none !important`, remove only the drop shadows selectively
with button(). This allows %bubble_button to preserve the focus ring
while eliminating the drop shadows.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2088
- Move the more generic %button style before %bubble_button to reduce
ugly overrides.
- Remove sizing factors from _drawing.scss to reduce ugly !importants.
- Make the %bubble_button style more consistent.
- Add missing focus styling to %notification_bubble.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/931
When pressing the menu key to show the popupMenu inside a ShellEntry,
the menu is currently aligned with the end of the entered text, this
causes a bug in case the text is overflowing the width of the entry: The
menu will be shown outside of the entry field, because it's aligned with
the (invisible) end of the text.
Fix that by simply aligning the popup menu with the cursor of the entry,
which is a behavior that makes sense when pressing the menu-key anyway.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/934
`MessageDialogContent.messageBox` is not really needed and was only
needed to show icons, which is now no longer supported. The styling can
also be done using other CSS classes and this makes it a bit more
straightforward to add actors to the MessageDialogContent.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/886
Since MessageDialogContent.messageBox is going to be removed in a
subsequent commit, move the parts where it's used out of messageBox and
into the contentLayout instead. This will introduce wrong spacings in
some dialogs, which we're going to fix when implementing the redesigned
individual dialogs.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/886
Since the last commit we set the gicon property of StIcon to NULL if an
empty string was given when setting the icon name, this means
`st_icon_get_icon_name()` will return NULL instead of an empty string.
When `getIndicatorIcon()` returns an empty string, the icon_name
property will now be set to NULL, so compare it to NULL here.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/888
Don't try to create a GIcon if the given icon name is empty, it will
lead to failure when loading the icon anyway, instead set the gicon to
NULL just as we do in the `set_gicon()` API when unsetting an icon.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/888
Animating the icon spring using the `translation-x/y` properties instead
of the `x/y` properties avoids relayouts. There are still other non-icon
actors moving, but it's a big improvement.
Before: 595 relayouts per spring
After: 94 relayouts per spring
Reducing relayouts reduces reallocation, which reduces CPU-intensive
JavaScript execution.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/926
String.prototype.substr() doesn't support a negative length value
(to subtract from the full length), so we end up with a filename
of '' when hitting that code paths (a relative filename with '.png'
suffix).
Fix this by switching to String.prototype.replace() instead.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2091
Replace existing panning and touchpad scrolling by SwipeTracker.
Since SwipeTracker only references one actor, redirect scroll events
from page indicators to the main scroll view.
Change programmatic scroll animation to use easeOutCubic interpolator
to match the gesture.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/826
Add a unified swipe tracker supporting dragging, four-finger swipe on both
touchscreen and touchpad, and touchpad scrolling.
The shared logic is largely same as the one in WebKit and libhandy.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/826
Commit 24e631ffe2 changed the shield animation to use translation
instead of position.
However once the shield is raised, only an animation will lower it
again, which means the shield is missing when it's supposed to be
shown without animation (for example after an idle blank).
Fix this by resetting the translation-y property in that case.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/927
The brightness property of ShellBlurEffect is of float type, but
we are calling g_value_set_int() in the GObject::get_property()
handler, which throws warnings when trying to set the property
via g_object_set() and family.
Use g_value_set_float() instead.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/924
Together with the forecast icon, the temperature label is the most
important information in the weather section. To emphasize it more,
reduce its space requirement by removing the temperature unit, then
make the text bold.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1143
- panel fg color was derived from bg color. Not a good idea as it's not
just light/drk, but HC as well.
- deriving from dark theme means contrast for things like popover items
is better.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/904
Since commit 90a08ba0b6, we only open a network secret dialog immediately
in response to user action, and show a notification otherwise.
While for the actual request VPNs are handled separately from other connections,
this isn't true when we show the notification - we need to handle 'vpn' together
with the other types there, or we fall through to the default 'invalid type'
exception.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2008
Now that both ThumbnailsBox and WorkspacesDisplay use single adjustments for
controlling indicator and scrolling, create the adjustment in OverviewControls
and pass it to both objects, effectively syncing indicator to scrolling.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/821
Instead of having a scroll adjustment in each WorkspacesView, and using the
one from primary screen in WorkspacesDisplay, have just one adjustment in
WorkspacesDisplay, and sync the changes between WorkspacesView.
This will allow to share the adjustment between WorkspacesDisplay and
ThumbnailsBox in the next commits.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/821
Instead of using the 'y', which queues a full relayout and
thus forces effects to be reapplied, use the 'translation_y'
property, that doesn't force relayouts and allows a future
blur effect to actually use the cached framebuffers a lot more.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/864
This is a moderately fast two-pass gaussian blur implementation.
It downscales the framebuffer dynamically before applying the
gaussian shader, which cuts down rendering time quite considerably.
The blur shader takes 2 uniforms as input: the blur radius; and
whether to blur vertically or horizontally.
The blur radius is treated as an integer in C land to simplify
calculations. The vertical parameter is treated as an integer by
the shader simply due to Cogl not having proper boolean support
in snippets.
At last, brightness is also added to avoid needing to use an extra
effect to achieve that. Brightness is applied in a different pipeline
than blur, so we can control it more tightly.
ShellBlurEffect also implements a "background" mode, where the contents
beneath the actor are blurred, but not the actor itself. This mode is
performance-heavy.
Related: https://gitlab.gnome.org/GNOME/gnome-shell/issues/1848https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/864
Many of the apps in the favorite apps list have fallen out of favor.
Replacing Rhythmbox with Music and Shotwell with Photos are obvious
moves. Rhythmbox and Shotwell are not core apps, and that means we
assume they are not installed by default. It doesn't really make sense
to have non-default apps in the apps list.
Evolution is also not a core app, and that is not likely to change, so
it should also be removed. Adding Geary might be more controversial. It
is a strong candidate to become a core app, GNOME Mail, in the near
future, but it is not there yet. So this could arguably be considered
premature. But I figure a GSettings
default is a cheap thing; we can always change it later if desired.
Calendar is added at the request of GNOME design team ("replacing" the
calendar functionality of Evolution).
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/907
This is what most GNOME modules now use instead of a shell script,
which makes sense given that the build system itself is written
in python.
This particular copy comes from nautilus ...
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/920
In an earlier iteration of the ease patch set, animatable properties
and easing parameters were different arguments.
This wasn't the case in the final version, so remove the left-overs.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/917
We don't want the icon to fill extra space, so set the alignment
accordingly. Otherwise we get an unexpected result when adding
a background just to the icon part (as far as I can tell: just
system-action-icon).
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/909
StScrollViewFade depends on st-scroll-view-fade-generated.c, but
that dependency isn't expressed to the build system; we just hope
that the custom target runs before compiling the effect.
Instead, add the generated source to the st target so the dependency
is expressed properly.
(The change from .c to .h is to prevent the file from being both
included and compiled, resulting in a duplicated symbol)
https://bugzilla.gnome.org/show_bug.cgi?id=789937
The screenshot code has a fair bit of nested callbacks, which means
that it is a good use case for async functions and Promises.
Most code uses GIO's async pattern, which means it can be easily turned
into promises with Gio._promisify(); first handle the couple of cases
that need custom code though, starting with SelectArea.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/903
Some GrabHelper uses are in the form:
doPreGrabStuff();
this._grabHelper.grab({
onUngrab: () => {
undoPreGrabStuff();
},
});
A promise-based variant allows to write this more cleanly as:
doPreGrabStuff();
await this._grabHelper.grabAsync();
undoPreGrabStuff();
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/903
We currently handle the case where the indicator itself is disabled
(read: hidden), but not when the entire top bar is invisible (for
instance when the primary monitor is in fullscreen state).
It is odd to pop up a top bar menu without the top bar, so check for
the indicator's mapped- instead of visible state.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2002
After creating a new extension, we try to open the main source
file with the default handler, which fails when there is none.
But given that the extension was created successfully, don't treat
a missing handler as failure, and print the path to the new extension
instead.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/905
Epiphany and Evolution updated their desktop IDs years ago. I assume the
rename list in appFavorites.js ensures this is still working properly
despite the obsolete names.
While we can now build gnome-extensions-tool as stand-alone project,
we are currently missing any translations, as those are part of
gnome-shell.
The easiest option for addressing this would be to symlink the toplevel
po directory into the subproject, however that would mean duplicating
the entire gnome-shell message catalogs.
So instead, set up a bare po directory and provide a script to populate
it from the translations in the toplevel po directory.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/877
The gnome-extensions tool code is really independent from the rest of the
code base, and could be used either as part of the gnome-shell build or as
stand-alone project (for example for the extension-ci docker image).
We can actually support both cases by moving the code to a subproject.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/877
The file was generated when importing gnome-extensions-tool from
a standalone repository. It isn't used by the build system, and
really shouldn't have ended up in the repository at all.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/877
Also introduce a "show-peek-icon" property to enable/disable
the peek-password-icon in the password entry. This is useful
in cases where the peeking the password functionality needs
to be avoided.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/619
This frees the entry's secondary icon that for other uses.
Caps-lock-warning feedback has been moved to be shown in
the various dialogs instead in the password-entries itself.
StPasswordEntry can now use a peek-password icon as the
secondary icon to show/hide the password present in the
entry.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/619
Use the new StPasswordEntry for password entry fields
and remove all direct handling of clutter text of the entry
via clutter_text_set_password_char to show/hide the password
text. StPasswordEntry will provides a peek-password-icon which
will allow to show/hide the password present in the field to
the user in subsequent commits.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/619
shellEntry should not need to query the clutter-text directly
in order to know if the entry is for passport-input purpose.
shellEntry can easily determine a password-entry by querying
if it is an instance of StPasswordEntry and use it's API
whereever relevant.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/619
StPasswordEntry will be put to use for password entries
in various shell dialogs. This is done to have a consistent
behaviour for all password entries and introduce a peek
password functionality for these password entries in the
subsequent commits.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/619
This is necessary to make DnD operations work from tablet devices on
wayland, as it's not the same onscreen pointer sprite than mice. Fixes
window DnD in the overview on tablet devices, no longer having them stick
to the wrong pointer.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/897
Use data from switcheroo-control to know which environment variables
to use to launch an application on the discrete GPU. switcheroo-control
version 2.0 or newer should be installed on Linux platforms.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/1810
Since commit 87e60ed97843, geoclue no longer pretends that authorization
is useful for system-installed apps (as they can easily lie about their
ID). Unfortunately this broke our auto-location support in case Weather
is installed non-sandboxed, as we are waiting for an authorization that
will never happen.
Unbreak it by only requiring authorization when installed as Flatpak.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1823
Just like switcher popups, popup menus don't play well together with
system modals, and generally have a lower priority. So just like
switcher popups, close popup menus when a system modal dialog pops
up.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1536
As system modal dialogs may open without user interaction (for instance
polkit or network agent requests), it is possible for them to pop up
while the app/window switcher is up.
The current result of having both up simultaneously is clearly broken,
so we can either dismiss the popup or prevent the modal dialog from
opening. Assume that the dialog indicates a more important action and
should therefore take precedence, so go with the former.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1536
Drawing windows got a lot more involved with the advent of client-side
decorations. Instead of accounting for visible and invisible borders,
titlebar and shadows when necessary, just add an empty child for the
custom drawing.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/887
Since both the `_items` object and the `_allItems` array include the
same items, the difference between those variables seems unclear. The
real difference between them (except the different data type) is that
`_allItems` is ordered in the same order as the visible grid, so rename
`_allItems` to `_orderedItems` which makes that more obvious.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/799
We have three interactions with an extension's prefs module:
- we import the module
- we call its init() hook
- we call its buildPrefsWidget() hook
The first two are one-time actions where we expect most getCurrentExtension()
calls (local imports, initTranslations() etc.).
However it's still possible that the extension will use the utility function
in buildPrefsWidget() as well, either directly or via other functions like
getSettings(): Make sure getCurrentExtension() returns the correct extension
in that case, not the last one whose preferences were initialized.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/873
The icon grid currently sorts icons by their names. When creating new
folders, the folder may end up being in a different page, and that's
confusing since we don't actually move to where the new folder is.
Move the icon grid to the newly created folder.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/883
We want extended keys to have the same size as their parent key,
but this is currently broken and the keys end up with their
parent key's preferred size (which is smaller than its allocated
size).
This is due to the way ClutterActor's width/height properties work,
which only return the "real" (i.e. allocated) size when the allocation
is valid, and fall back to the preferred size otherwise.
As changing an StWidget's hover state involves adding or removing
the `:hover` pseudo class, this is currently always the case.
Creating the extended keys first means the keyButton's allocation
is probably valid, so do that.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1976
Mutter and Clutter was changed to pass around the current target
framebuffer via the paint context instead of via the deprecated Cogl
framebuffer stack.
The framebuffer stack has also been removed from Cogl so change to use
the one in the paint context instead.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/827
While still leaving them unused, pass around ClutterPaintContext and
ClutterPickContext when painting and picking.
The reason for splitting this change up in two is to make it possible to
bisect easier in between the API change and the change to using the
framebuffer passed around with the temporary contexts.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/827
This code didn't even pay attention to the
cur_stmt->kind.media_rule->media_list, and unconditonally considered
each statement in the ->ruleset to be of kind ruleset. That seems
broken.
(The theme doesn't use any @media queries, and they are unsupported
anyway.)
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1979
When commit c6cea277e replaced Shell.GenericContainer, the check
whether the required width exceeds the avilable width was changed
from using the minimum widths of items to the natural width of the
scroll view.
That doesn't work correctly, as the *natural* width may well exceed
the actually used width: SwitcherList bases its width request on
children's minimum sizes to force labels to ellipsize.
Fix this by using the minimum width of the scroll view's child instead.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1834
Since commit 28c535e34, we use the timezone associated with the ICalTime
instead of the default timezone when converting to time_t. However while
that is correct for most events, for ICalTimes that don't have a timezone
associated we still want to fall back to the default timezone instead of
UTC.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1895
It is true that delete is a javascript keyword, but that doesn't
prevent it from being used as method name - there are event built-in
types like Map or Set with delete() methods!
So if that hack was ever needed, this hasn't been the case for years
now; just removed the hack now.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/862
We're storing in the texture cache images and scaled images appending
the scaling factor to the key. When a file changes the cache key
corresponding to that file is removed, but not the keys for the scaled
ones so that images in the cache are never reloaded.
This patch removes all keys from the cache related to the file that
changes, including those with the scaling factor.
A new set (hash table) was added to keep track of scale used to be able
to remove all possible images in the cache.
When the KEY is removed from the cache, we can look now in the scale set
for and each scale we also remove the key "KEY1.000000", "KEY2.000000",
etc.
Assuming that the number of used scales is small (I would typically
expect one or two), the overhead should be negligible.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/567
If the GNOME shell crashes, we run a service that may disable
extensions. This is important so that users will not be locked out of
their own session in case an extension is causing crashes.
As this is a very agressive action, we tried to only do this in the
first two minutes of the session. Unfortunately, the logic was broken
and would result in an unclean session shutdown.
Fix this by using the newly introduced gnome-shell-disable-extensions
file. This is created by the extension subsystem for a period of time to
indicate the extensions may be the cause of a gnome-shell failure.
See
https://gitlab.gnome.org/GNOME/gnome-session/issues/43
for a log of the bug happening and the gnome-session part to fix this.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/858
When the extension system is loaded, create the
gnome-shell-disable-extensions file in the users runtime directory. This
file is automatically removed 60s later. The sole purpose of this file
is to be consumed by the systemd units. If the file exists, the systemd
units will disable extensions when the gnome-shell fails.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/858
The whitelist is a list of well-known D-Bus names, which we then search
for the unique name we get from the method invocation - unsuccesfully.
Fix this by watching the bus for any name in the whitelist in order
to maintain a map from wel-known to unique name that we can use for
matching.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1916
Since the notification message close button had no border, or mouse
over effect, there was no way to determine whether the mouse cursor
were over the button.
Improve this by adding a message-close-button class for the close
button, and a styling for its hovered state, based on media control
button styling.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/855
Increases contrast between normal and hovered states in
message-media-control buttons. Previously there was very little
difference between the two states, making it hard to distinguish
whether the mouse cursor was over the button.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/855
When removing a string from a settings list, we iterate over all
existing entries and copy all strings except the one that's being
removed to a new list, which is then written to GSettings.
However we currently always increment the index, so we end up with
a NULL entry in place of the removed entry, which is then interpreted
as the end of the list. In other words, we also remove all entries
that follow the removed string.
Fix this by looping over the list entries instead of the index, and
only increment the index for entries we copy.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1946
Currently when dragging an icon to the space above or below the appGrid
to switch pages, we do so very quickly without checking when the last
page-switch happened. This makes it hard to move icons to pages which
are not the first or the last one, since the other pages are skipped
very quickly.
To fix this, add a timeout of 1 second that blocks switching pages after
a page-switch using drag overshoot occured.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1693
We currently always switch app pages when a dragged app icon
moves outside the grid boundaries, regardless of any previous
page switches. This makes it too easy to switch multiple pages
accidentally, so add a small threshold that the icon has to
move back towards the grid before allowing another page switch.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1693
There's no need for a `inhibitEventBlocker` interface. Since we connect
to "open-state-changed" of our folders in the AllView anyway, we can
just make the event blocker visible while a folder is opened, and hide
the event blocker during DnD.
This allows keeping the eventBlocker reactive at all times and fixes an
issue where DnD to create a new folder is impossible if no folders are
present because the eventBlocker would not get inhibited.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1652
Emitting ::drag-end after changing the slider value via arrow keys
was a cheap way to make the sound feedback work for keyboard input.
But now that the volume indicator plays the sound on ::value-changed
as well, we can stop doing that - after all, key presses aren't drags.
Besides that, this will make the limiting of feedback to actual volume
changes from the previous commit work for key events as well.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/53
gnome-settings-daemon doesn't play the volume change sound when
the volume stayed the same (that is, it is already at its maximum
or minimum). This looks like the right thing to do, so copy its
behavior.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/53
Commit 8d4855f100 accidentally removed the volume change feedback
for scroll events. Add it back to be consistent again with moving
the slider via arrow keys, slider drags/clicks and gsd's media keys
handling.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/53
While those should be concise enough to fit, they may not where
temperatures drop into double-digit negatives. It seems better
to accept some awkward horizontal scrolling in that case than
shorten relevant information.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1926
Commit b779f6f728 added a check to filter out invalid weather forecasts.
However the check is currently done when creating UI for the forecasts,
which means we end up with fewer forecasts than we could display if any
forecasts are invalid.
We can avoid that issue by checking the validity while collecting the
forecasts, so do that instead.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1927
We currently always start with the current weather info, then append
forecasts. This is slightly confusing, as the only hint that the
first item is special is the past (and potentially "odd") time.
Stop doing that and base all items on forecasts.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1927
As we get closer to midnight, we show fewer forecasts than we could
fit, or none at all. It makes more sense to continue the forecasts
into the wee hours in that case, so only exclude past forecasts,
but not ones from following days.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1927
Weather stations can have unwieldy long names, which don't fit the
limited space we have available. City names are usually more suitable,
so use the name of the nearest city instead if possible.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1927
In case of a very long location name, the label may take up all
available space. Make sure there is at least some spacing between
header and location in that case.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1927
The two labels use different font sizes, so they don't align properly.
Unfortunately we don't have BASELINE alignment in Clutter, but at least
END comes closer than the default FILL.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1927
Commit c899453800 lifted the requirement of switcher keybindings
to contain a modifier, however it is currently only possible to
finish it by letting it time out.
Improve that by also accepting space/enter key presses to confirm the
selection immediately.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1883
The noModsTimeout obviously finishes inside a timeout callback, which
means `global.get_current_time()` might return Clutter.CURRENT_TIME (ie.
0) when called inside it, because it's not called while handling an
event. This means when switching apps or activating a window, the
timestamp passed to `activate_window` may be 0, which is the reason why
the altTab switcher is currently broken when using modifier-less
keybindings.
Fix that by using `meta_display_get_current_time_roundtrip`, which
always return a valid timestamp, instead of
`shell_global_get_current_time`.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/847
Remove setCurrentPage() function, introduce setCurrentPosition() instead,
which allows to have fractional positions.
Make inactive dots smaller, filled and partially transparent, as opposed to
larger and fully opaque active dot. Make dots smaller overall, remove
borders. Interpolate each dot between active and inactive state based on
scroll position.
Make it impossible to "uncheck" the active dot.
Thanks Florian Müllner for parts of the code.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1932https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/843
We slightly delay showing the switcher popup to avoid flashing it
briefly in the common case of quickly switching back-and-forth
between two windows.
However some users perceive this delay as slowness. Address this by
showing the popup immediately when another key press is consumed
(that is, a key like Tab is pressed).
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1928
Since the mpris implementation of the notification tray supports showing
multiple notification (one for each player), it doesn't make sense to
have only one global property to store the message, since that only
allows referencing one message at a time.
Instead, handle the MediaMessages completely inside the scope of
`_addPlayer()`, this should allow showing more than one message again,
which broke with commit 4dc44304df [1].
[1] https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/791https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/833
Because the message actor could also be undefined or a already
deallocated ClutterActor, we sometimes fail to show the error message
and get an error from Gjs instead.
So make sure we always log the proper error message and just leave out
the actor.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/833
It may happen that the app icon is destroyed with a drag
monitor still around, in which case, a load of warnings
will be shown.
Make sure to remove any pending drag monitor on destroy.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/841
When removing the last icon of a folder, FolderView first removes
the folder from org.gnome.desktop.app-folders.folder-children, then
proceeds to reset all its keys, which removes the relocatable schema.
That order of operations turns out to be problematic. Removing the
folder from 'folder-children' destroys the folder icon, which in turn
destroys the folder view, which throws a load of warnings in the
journal.
Fix that by removing the folder after resetting the schema keys. In
fact, what we're doing here is not using 'this' anymore.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/841
The variable that holds the list of application icons is
called 'newApps', but that technically was never true,
since we only create new app icons when necessary.
Rename it to 'appIcons'.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/841
The views (AllView and FrequentView) build a list of all applications
they contain. BaseView then diffs between what's currently added, and
what needs to be added, and removed.
This approach has a problem though: creating an AppIcon or a FolderIcon
connects to various signals, and we confuse the garbage collector.
When building the list of applications, instead of always creating new
icons, try to use already existing icons first.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1610
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1694
GWeather.Info.get_value_update() may indicate that the forecast is not
valid, or it may return a timestamp of 0 to indicate the information has
never been updated. In both of these cases, skip creating a widget for
it, as the information will not be accurate.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/835
If the clock is set to 12h, the AM/PM in the weather forecast times
should be clear from the context, because they are the immediately
following hours. This makes it less likely that the times will be
ellipsized (in which case the AM/PM wouldn't be shown anyway.)
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/835
While we support a reasonable list of layouts nowadays, we don't
include many variants like `fr+oss`. Instead of directly falling
back to the `us` layout, try stripping the variant first, as the
base layout is likely closer to the expectation than `us`.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1907
When cancelling the PolkitAgent session before disconnecting the signal
handlers, we receive a "completed" signal where `gained_authorization`
is set to FALSE, which means we show an error message inside
`_onSessionCompleted()`.
This in turn means we show an error message every time we cancel a
session. In practice this wasn't really relevant so far since we only
destroyed the session when an actual error occurred before. Now that the
dialog supports empty passwords, we also call `_destroySession()` when
the user changes and no longer has a password set, and in this case we
want to cancel the current session without showing an error message.
So to fix this, disconnect the signal handlers before cancelling the
session, which makes sure we don't receive the last "completed" signal
in case we cancelled the session ourselves. This change also allows
removing `this._wasDismissed`.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/829
When a user has no password and a polkit authentication is started,
instead of blindly initiating the admin session, show the regular
"Authentication Requested" dialog (but without the password entry). This
makes sure that the user's admin session is only effectively started
after the user chooses to proceed with the authentication, which
provides an extra confirmation step that can be vital for critical
tasks.
To do this, we show the dialog inside `_onUserChanged()` right after the
dialog was created instead of calling `performAuthentication()` from
`_onInitiate()`. The bug mentioned in `_onInitiate()` is no longer an
issue since we show the dialog in all cases now anyway.
Ideally we should use a different wording than "authentication" when the
user has no password set, and use "confirmation" instead. However polkit
already sends the requests with such messages (e.g. "Authentication is
required to configure software repositories"), and it's important to
show those to the user, so this patch keeps the regular wording.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/829
Since `_destroySession()` is not only called before we try to initiate a
new authentication session with Polkit, but also when the dialog is
closed, it's currently possible that key focus is grabbed by the close
button after the dialog was dismissed and hidden. This is causing a bug
where after dismissing one of multiple queued dialogs, key focus goes
away and keyboard navigation with the new dialog is impossible.
Fix this by only resetting the UI of the dialog if the dialog is still
opened/visible at that point.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/828
Just as with c35b4cede5, there's no
default vfunc implemented by any parent which causes gjs to crash when
trying to call it.
So return EVENT_STOP if the key press successfully toggled the button,
and EVENT_PROPAGATE otherwise.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/830
Modifying variables from an outer scope in functions created in a loop
is considered problematic by eslint, because the variable value in the
resulting closure is often not what the coder intended.
In this particular case however, the scoping is correct, so add a comment
to disable the rule locally.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/818
The FolderView class is responsible for creating the 4-item
grid of the folder icon, with the preview of the first four
apps inside the folder.
However, with the deprecation of StAlign as child properties,
the folder icon stopped being horizontally centralized.
Center the folder icon horizontally again.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/817
Since ES5, trailing commas in arrays and object literals are valid.
We generally haven't used them so far, but they are actually a good
idea, as they make additions and removals in diffs much cleaner.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/805
ES6 allows to omit property names where they match the name of the
assigned variable, which makes code less redunant and thus cleaner.
We will soon enforce that in our eslint rules, so make sure we use
the shorthand wherever possible.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/805
If an else block only contains an if statement, the two can be
combined into an if-else block, which cuts down on indentation
and usually helps legibility.
There are exceptions (for instance where the outer if and else
blocks are mirrored), but where it makes sense, change the code
to avoid lonely ifs.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/805
Nesting functions can be helpful for private helper functions, but
here they are accessing some variables from the outer scope and
shadowing others. Split them out to avoid any ambiguity.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/805
The event blocker in AllView is responsible for stealing click events
from the icon grid and closing the folder popup. The event blocker is
kept unreactive when no folder popup is visible, and it's made reactive
as a response to the 'open-state-changed' signal.
Using this signal, though, is problematic. When opening an app folder,
the icon grid first opens space for the folder to fit in; during this
period, it's possible to click on another folder icon, and break the
icon grid state.
Make sure the event blocker is reactive immediately after clicking on
a folder icon.
Related: https://gitlab.gnome.org/GNOME/gnome-shell/issues/1470https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/816
Objects implementing EventSource should have some mandatory methods and
properties, we can ensure this by defining an EventSourceBase abstract
class.
So inherit EmptyEventSource and DBusEventSource from it making sure that
they implement all the needed methods, using native properties and
replacing the 'notify::*' fake signal emissions with proper object
notifications.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/563
Use GObject based objects for ModemGsm, ModemCdma and BroadbandModem.
This allows to define a base class that we can use to natively define
properties and notify property changes.
We can now remove the "fake" notify signals with proper properties
notifications.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/563
Animation background is just wrapping a native GnomeDesktop BGSlideShow
object, so instead of using composition we can now just inherit from the
native GObject, re-using native properties when possible, and avoiding
to keep an extra wrapper to the bg file.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/563
Resizing effects are more finicky as other effects, as the actual
animation is delayed until we receive the ::size-changed signal.
However that signal may never be emitted if the window is destroyed
just after starting the size-change effect, in which case the effect
is never completed, blocking mutter from destroying the corresponding
window actor.
Address this by tracking when a resize effect is pending, and complete
the effect when appropriate.
https://gitlab.gnome.org/GNOME/mutter/issues/655https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/815
In the xwayland-on-demand scenario, it may happen that Xwayland is
shutdown (causing a restart of ibus-daemon to drop ibus-x11) while
we are typing.
If we have a bit of bad luck, this will cause the IBusInputContext
to be disposed (due to its bus "closing") at a time when we have
an ibus_input_context_process_key_event_async() request on the fly.
As the object is disposed in between this would tickle JS (rightfully
complaining that it's been disposed under its feet) and make us pass
an actually NULL IBusInputContext to the corresponding _finish()
function (despite the IBusInputContext being still held alive by some
other refs). This will assert and abort in
ibus_input_context_process_key_event_async_finish() then.
To handle this, listen for IBusInputContext::destroy, and reset our
internal state, this way we can compare on the JS side that the
IBusInputContext is indeed an up-to-date one.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/813
I've observed that UPower can occasionally report a charge level of 100%
while the state is still "charging". This usually doesn't last very long
but it is noticeable because the power icon changes to a "missing icon"
icon. This will handle that rare case correctly.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/814
For stable branches, we currently only check out the correct mutter
branch for merge requests. For the regular pipeline, our code to
determine the current shell branch fails because CI runs on a
temporary "pipeline/12345" branch that doesn't exist for mutter.
Switching to the correct gitlab environment variable fixes that.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/811
Clutter originally cluttered its namespace with key symbols, before
prefixing all symbols with KEY. We still use the unprefixed symbols
occasionally, replace them so mutter can drop the deprecated symbols.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/808
Since polkit takes a few milliseconds from initiating the session to
emitting the "request" signal, don't introduce visual distraction by
hiding the password entry and showing it again a few ms later.
So start a timeout of 200 ms when we destroy a session and if no session
request (i.e. a request for a password-authentication) happened during
this timeout, hide the password entry.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/788
Since we don't know if polkit/PAM will request a password (emitting the
"request" signal) or use another authentication method like a
fingerprint after the current authentication failed, hide the password
field and make the "Authenticate" button insensitive after cancelling
the session, just like we do when creating the dialog.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/788
Set the key focus to the password field only after we got a request
(and therefore know that a password is requested) instead of using
`setInitialKeyFocus()`. This way we don't try to focus the password
field by default if we aren't showing it (e.g. in case the user has no
password or is using fingerprint login).
Also we have to move the call to `grab_key_focus()` to happen after
`_ensureOpen()`, because otherwise the ModalDialog will set the focus to
one of the buttons while opening itself.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/788
Show the user avatar for all users, including the root user. The root
user will always have the generic avatar, but it looks more consistent
than showing no avatar at all.
This way we also don't have to worry about the spacing introduced by the
polkit-dialog-user-layout CSS class, which would give the
"Administrator" label a small offset to the left.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/788
Instead of every individual StThemeNode. There are essentially two kinds
of theme nodes: Those we create for lookups, and those interned by the
theme context and used by StWidgets. Listening to the signal on the former
is pointless as they are short lived and not meant to be really used for
drawing. So it is only essential to track stylesheet changes in those we
intern for later use.
This change does precisely that, it lets the StThemeContext track the
stylesheet changes and let all known theme nodes reset their state for
it.
The internal array holding all connected handlers for this signal in glib
was about the biggest single allocation made in gnome-shell, as interned
theme nodes nodes are around the 4 to 5 digit numbers. This essentially
makes it disappear.
This however means that widgets that are explicitly set a theme through
st_widget_set_theme() don't get their theme node implicitly updated.
There's little reasons to use that API, so perhaps this is an acceptable
tradeoff.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/779
A StWidget could get its style from a) a theme set in the StThemeContext,
and b) directly through it's ::theme property. Generally, overriding CSS
through the latter cannot be recommended as it loses any connection with
the global theme (eg. the ones you get through selector specificity).
It sounds a bit too powerful and pervasive, there's no use for it in
gnome-shell and doesn't look like something that could be recommended on
extensions. So, just drop this piece of API.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/779
xgettext got better at recognizing template strings, so we can
replace more string concatenations. Alas xgettext is still buggy
(surprise, regular expressions are hard), so there are still a
handful of holdouts that prevent us from making a complete switch.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/792
By now, all containers and layout managers except StBin (and its
subclasses) use the generic ClutterActor expand/align properties
to control how their children are laid out.
This is particularly confusing as two or the properties StBin uses
for layout - x-align and y-align - shadow the generic ClutterActor
ones, but work very differently: They use a different enum and
determine how the bin lays out its child, instead of how the bin
is laid out by its parent.
Address this by deprecating the StBin properties and using the same
generic ClutterActor properties as everyone else.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/803
Every since commit aa394754, StBoxLayout has supported ClutterActor's
expand/align properties in addition to the container-specific child
properties. Given that that's the only container left with a special
child meta, it's time to fully embrace the generic properties (and
eventually remove the child meta).
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/780
This wasn't added on the GObject-ification in commit c4c5c4fd5c. This
introduced warnings and misbehaviors when closing the dialog. (Eg.
pressing the "show OSD" pad action would show stack different dialogs
on top each other).
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/800
It seems like some recent change (maybe the move to a ClutterActor
subclass for AppIcon) broke the check whether the drag source is an
instance of AppIcon. While the drag source indeed is an AppIcon and
everything else works correctly, the check still returns false, which
breaks the creation of new folders using DnD.
Theoretically it makes sense that this doesn't work, because we're
assigning AppIcon using `var AppIcon =` and that will only get set after
`GObject.register_class()` finished, so accessing `AppIcon` inside that
function seems risky and is probably wrong.
Fix this by comparing to `this.constructor` instead of `AppIcon`, which
works fine and we know for sure exists at this point.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/794
Something changed recently in the test initialization code, causing
the test-theme invocation to fail. Make sure there is a D-Bus session
by running the tests through dbus-run-session to get them going again.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/796
I have observed a client in the wild (Chromium again) set CanPlay to
false momentarily while it is loading the next song. Previously, the
code would close the player proxy in that case, meaning that after
playing one track, the MPRIS message would disappear and never come
back.
However, I think this use of CanPlay, while apparently not usual, is not
incorrect according to the spec. We should hide the message instead of
closing the player proxy.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1362
In the wild we have buggy clients (notably Chromium 77 and earlier) that
send metadata with the wrong types. Previously, this would throw an
exception and prevent the MPRIS information from showing up in the
message list.
This changes the code to check if any incoming metadata is of the type
it is expected to be, and logs a warning if not, then continues on with
a default value.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1362
Make gjs to compute the GType name for registered GObject-derived
classes using the file basename and the first directory name, so that we
can avoid name clashing, and ensure that no extension will break the
shell by registering a name that is already used (by the shell or by any
other extension).
This requires gjs commit 02568304 [1] that will be part of release 3.35.2,
so bump the required version as gjs does post-release version bumps.
[1] https://gitlab.gnome.org/GNOME/gjs/merge_requests/337https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/790
Similar to the previous work-around, xgettext gets thrown off by
embedded quotes in template strings, in particular where a template
"breaks up" a pair of quotes.
Throw in some more comments to make xgettext happy, but whoever makes
the gettext toolchain not depend on fragile regular expressions will
be drowned in beverages of their choice ...
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/792
Xgettext learned about template strings now, which is good. However
it's still buggy, so instead of the "classic" xgettext issue with
backticks, we now have exciting new issues to find work-arounds for.
One issue is that it doesn't detect backticks inside string constants
as regular characters, so having an odd number of backticks throws off
its regex.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/792
This corrects weird-looking blending visible as it fades out when the
overview closes. Previously the entry's dark background would drown out
the text as it fades out, but now they maintain a consistent contrast ratio
during the fade.
There's no noticeable change in performance, but in theory it should be
faster as text entries don't change at full frame rate. So stage redraws
will usually have a cached searchEntry drawn and require less effort.
Though the main purpose here is to correct the appearance.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/778
The close dialog is added as a child to MetaWindowActor, and, in Wayland
sessions, since commit [1] MetaWindowActor applies a transformation
matrix which scales all it's children using the geometry scale factor.
Now because the dialog actor is not a window (i.e. a MetaSurfaceActor),
but a subclass of StWidget, the scale factor is also applied to the
properties of the dialog by StThemeNode, so we end up applying the
geometry scale twice to the close dialog.
Fix this by applying the inverted scale to the dialog, which leaves the
scaling only to MetaWindowActor. This means we also can't apply a pivot
point other than 0 to the dialog actor, so apply the 0.5-pivot point to
the `_dialog` child of the Dialog class (the actual visible dialog box)
and also perform scaling animations on this child.
[1] https://gitlab.gnome.org/GNOME/mutter/commit/fb9e8768https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/783
Remove all transformations from window actors after a window animation
was either cancelled or finished. Right now we only do that if the
transition finished successfully, which seems kind of pointless (it can
probably be historically explained because the callbacks inside the
"kill-window-effects" signal handler are connected to those
`*WindowDone()` functions though and the `*WindowOverwritten()`
functions were only added later in [1]).
This fixes a recent regression where a window animation would get
cancelled and remain stuck by switching workspaces. The regression
probably happened due to different behaviour of the `onOverwritten`
callback of Tweener and the `onStopped` callback of Clutter transitions:
For the workspace-switching animation the window actors get reparented
to a temporary container, which makes Clutter transititons emit
"stopped" (`clutter_actor_remove_child_internal()` stops transitions on
its children), while Tweener would continue the animation.
[1] 6dd302e5cehttps://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/784
Some vfuncs like `button_press_event`, `button_release_event` and
`touch_event` don't have handlers in the parent classes of
PopupBaseMenuItem. So don't call those handlers and return the default
Clutter.EVENT_PROPAGATE there.
This fixes a crash of the shell that happens when pressing a mouse
button inside the system popup menu and releasing it above a slider like
the volume slider again.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/787
We currently only update the windows section when either the focus app changes,
or when the app's windows change (that is, a window is opened or closed). This
allows the menu item labels to become stale if the window title changes after
one of those events (for example when switching tabs).
Fix this by updating menu items when the corresponding window title changes.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1830
g_desktop_app_info_get_categories() may return null. In that case, the
previous code would fail to create a folder when dragging an app with
no categories onto another app. Instead, simply continue with the next
app info.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/782
In the case of bugs in a drag target's acceptDrop() function, it may
throw an exception. In the previous code, this would break out of the
loop entirely and never cancel the drag, so the mouse button release
event would be ignored and you would have to press Esc to get out of the
drag.
In this change, if acceptDrop() throws an exception, we log it and move
on to the next parent target instead.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/777
Those are two useful ClutterTimeline properties and
will be needed for wiggling the search entry when
failing the password.
Add support for passing repeat-count and auto-reverse
to ClutterActor.ease and ClutterActor.ease_property.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/768
When accessing properties on ClutterActor for size and position there is
a notable access time overhead. This overhead adds considerable user lag
when opening the overview if many windows are open.
This is primarily due to these properties being accessed while sorting
WindowClone instances by their window's center for placement in the
overview. By pre-computing this center value only once when
initializing WindowClone, the induced lag can be significantly reduced.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/763
The script can be helpful outside of CI, in particular for gradually
transitioning to the new style.
Reverting commit f00201fa6c it is already possible to do something
like
$ CI_MERGE_REQUEST_PROJECT_URL=https://gitlab.gnome.org/GNOME/gnome-shell \
CI_MERGE_REQUEST_TARGET_BRANCH_NAME=master CI_COMMIT_SHA=HEAD \
.gitlab-ci/run-eslint.sh
but that is hardly convenient.
Instead, allow passing the required parameters on the command line:
$ .gitlab-ci/run-eslint.sh origin master
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/730
Overview's animationInProgress, visible and visibleTarget properties are not
meant to be modified from others, but be read only.
So make this clearer using properties getters and private values.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/559
Instead of manually updating properties on change, use native properties
bindings to keep the them synchronized.
Disable hover-tracking and focus-ability when the avatar is not sensitive.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/559
Now that the calendar message list and the message sections are actors, there's
no need to keep track of the sections in a different Map as we can just use the
native clutter functions to manage the children and access to their properties.
Also cleanup the signal connection/disconnection.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/559
When messages are added to the message list, we create a container for those,
however since now the messages are actor themselves we can just create a list
item actor that holds the message actor and refer to the message parent in order
to get their container.
This allows to remove the obj container map we used, using the native clutter
parent-child hierarchy and handle signal connections cleanly.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/559
Since all the search result classes are now GObject classes, we can enforce
the methods we want to have in there (just activate() for now) using an
interface, to make sure they are implementing what we require and to easily
group all the classes that can be used as search results, even though they
are not extending SearchResult.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/559
Remove the `this.actor = ...` and `this.actor._delegate = this` patterns in most
of classes, by inheriting all the actor container classes.
Uses interfaces when needed for making sure that multiple classes will implement
some required methods or to avoid redefining the same code multiple times.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/559
Dispose the Source Object when dispose() is called, avoiding that it could be
called twice on a destroyed Source.
So, notify count changes before destroying the object, and don't emit this
twice on destroyNonResidentNotifications (as if a notification is destroyed
the property notify will happen in the notification destroy callback anyways).
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/559
When the notification is destroyed we should also dispose the underneath GLib
object, and ensure that we don't dispose this twice.
In order to avoid this, don't destroy transient notifications that have been
already been removed and only destroy the resident notifications on activation
if they have not been destroyed earlier.
Thus connect after to the 'activated' signal and once the default handler has
been called destroy the notification if not requested earlier.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/559
The Keyboard class used to be both a view and controller class, however in order
to make the keyboard a native Clutter.Actor, we need to separate the widget from
the controller class, so that we can manage the actor lifetime from the JS side.
Thus, initialize the keyboard actor on the Keyboard constructor and create a
KeyboardManager class to manage its state and lifetime.
Add proxy methods for the public functions that were used by other shell
components
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/559
Meta.Background has already a 'changed' signal and not to confuse the source
signal with the wrapper one, rename the wrapper class signal into 'bg-changed'.
This will be relevant when we'll inherit from Meta.Background, as signal
emissions from the base class could interfere with the wanted derived class
behavior and with the the grouping of successive changes into a single ::change
emission.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/559
When the screen is marked as idle, we normally start a fading animation and
a timeout to finally lock the screen. This timeout is configured using the
fade time if no longer delay is set in settings.
However if animations are disabled or slowed-down/up, the fade time is
different from the STANDARD_FADE_TIME and so we might end up showing the
lock shield without actually locking for STANDARD_FADE_TIME in the disabled
or slowed-up animations case, or locking too early in case of slowed-down
animations.
So, just adjust the timeout time using the same logic of animations so that
this value is matching all the times.
Related to https://gitlab.gnome.org/GNOME/gnome-shell/issues/1744https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/749
Devices like cameras and microphones are privacy sensitive, as they can
be used to spy on the user. We cannot prevent non-sandboxed apps from
doing that, but as we already track when the microphone is recording,
we can at least show an indicator to make sure it doesn't happen behind
the user's back.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/729
Search result views can include also objects that are not inheriting from
SearchResults (such as the AppIcon) that has not any 'activate' signal, to
connect to. Since we want to enforce a more formal interface, we want to
have just a simpler requirement as an activate() method.
So, instead using the 'activate' signal in SearchResult to activate a result
via SearchResultsBase just implement activate() in the result.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/765
When a transition is set up with a delay, it may be removed before it
actually started. We won't get a ::stopped signal in that case, with
the result that we currently end up with a mismatched unredirection
disabling.
Address this by only disable unredirection once the transition has
actually started.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1788
gnome-session used to show a dialog in this case, but a
notification is more natural nowadays. Doing it in gnome-shell
avoids complicated synchronization between gnome-session and
gnome-shell.
https://bugzilla.gnome.org/show_bug.cgi?id=701212
We share this actor with other shell menus, which arguably track a different
"cursor" as we care of the caret/anchor text positions, and menus care about
pointer click coordinates.
Use a standalone actor for this, so popups/IM are entirely decoupled.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/1571
As per GNOME/mutter!385 [1], the compositor is finalized an its pointer
cleared on display close.
However, since the shell reacts to such events instead of controlling them,
when the shell is stopping or restarting and its display closing, the shell
stage destroys its children after the display closing is finished and during
this process the focus is unset, causing focus_actor_changed() to be called
and thus calls to meta_stage_is_focused() which deferences the now NULL
compositor, leading to a crash on shutdown.
Since after this point we should just ignore any stage event, disconnect
from them all.
[1] https://gitlab.gnome.org/GNOME/mutter/merge_requests/385https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/746
If graphical applications want to start from systemd units, they need to
start after we're properly ready to display them. This is particularly
important under X where `_GTK_FRAME_EXTENTS` and other xprops are needed
to have the right theming.
We're doing this in an idle callback so that the dynamic starting of
`gnome-session-x11-service.target` (which launches `gsd-xsettings`) as
the result of a signal emission happens before us signalling we're ready
for later things to start.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/750
As per clutter optimizations in should_skip_implicit_transition() any
transition will be ignored if applied to an actor with unmapped clones.
Since we initialize the lightbox as hidden, when we use it standalone (as it
happens for the long fade in screenShield) the transition will be ignored.
This causes the lockscreen fade-out after the idle delay not to work, but
instead to have an apparently locked system that is instead not locked at
all.
So, just ensure that the lightbox actor is visible before applying to it any
transition.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1683
The shell tries to spawn the ibus daemon on startup if unavailable, however
as per commit 8adfc5b1 we also force restarting it once the X11 server is
available.
Unfortunately this could cause a race if we disconnect while we were already
connected to an ibus daemon, but still in the process of going through the
various nested calls.
In fact the ::disconnect callback didn't stop any further async ibus call
that, even if failing, would have eventually triggered the emission of a
'ready' signal and to the Keyboard's callback, leading under X11 to a full
grab owned by ibus daemon.
In order to avoid this and keep control of the calls order, use in both
IbusManager and InputMethod a cancellable that is setup before connecting to
the bus, and that is cancelled on disconnection.
Then handle the finish() calls properly, using try/catch to validate the
returned value, taking in account the potential error and just not
proceeding in case of cancellation.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1712
gnome-shell calls ibus_input_context_focus_in() in InputMethod.focus_in()
but the event is not actually forwarded to panels and engines in GNOME
Wayland because gnome-shell changes IBus.Capabilite by focus events and
disables IBus.Capabilite.FOCUS when ibus_input_context_focus_in() is called.
IBus.Capabilite is assumed a fixed value per input context in the
first place and it should not be changed by focus events.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/573
Until commit 506b75fc7f we got away with not handling a NULL return
value, as cairo_surface_destroy() deals with a NULL surface; the same
isn't true for get_width/get_height, so guard to code in question to
prevent a crash.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1678
Unset the signal IDs we connected to when starting the drag. Otherwise
we get error messages if a touch drag is ended after a mouse drag
happened because the signal IDs are still set but no signals are
connected.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/740
This is now handled in Mutter. Also, respect the result size instead
of assuming it to be equal to the clip size, as the clip takes actor
coordinates while the result takes buffer coordinates.
This can be fixed in a future API iteration.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/728
The screen shield creates the unlock dialog based on the session mode.
However since commit 0c0d76f7d6 turned LoginDialog into an actor
subclass (while UnlockDialog kept using the delegate pattern), it is
no longer possible to handle both objects the same way without warnings.
Allow this again by turning UnlockDialog into an actor subclass as well.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/736
When easing, we need the transition of one of the involved properties
to connect our callbacks. Currently we simply get the transition for
the first property, however as Clutter optimizes the case where a
property doesn't actually change, that transition may be NULL even
though we still animate other properties.
So instead of only looking at the transition of the first property,
try to find a transition for any of the involved properties.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1572
The RenameFolderMenu uses the internal box as a menu item, while PopupMenu
expects to have PopupBaseMenuItem based children with a delegate set.
Instead of using a custom menu with a customized box acting as menu
item,just add a RenameFolderMenuItem that inherits from the parent,
adjusting the features as we need them. In fact, the rename folder menu item
doesn't need any label, padding or default styling so we can reuse
PopupMenuBaseItem after we use our styling properties and we set the
Ornament to HIDDEN.
To get the proper style in place, define rename-folder-popup and
rename-folder-popup-item to override the default popup-menu-item rule
padding instead of using margins.
Pass the menu item as menu's focusActor as this will key-focus it on pop-up,
by overriding the key_focus_in() vfunc we can then delegate the focus
handling to the entry's clutter-text.
Also override the map() vfunc in order to update the entry's content before
mapping the entry.
Finally, use the item's activate method in order to tell the parent menu
we're done with it and that the menu can be closed.
As consequence we can also remove the menu's popup() method, and just use
the default open().
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/720
When the rename folder menu is opened the text entry is expected to be
focused and selected for a quick editing.
While this is required it doesn't actually happens since PopupMenu by
default gives the key focus to the source actor, that is then free to pass
the key focus to the menu if there's an user interaction.
In this case however, we want the text entry to be focused once we prompt
the menu, so just use the PopupMenu's focusActor property to ensure it will
handle it for us.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1604https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/720
The PopupMenuManager is supposed to grab and focus the menu actors, with
normal menus we always need to grab the actual menu but set the key focus to
the source actor so that it will be able to move the focus to the menu
child, if requested.
However there are menus such as the RenameFolderMenu that requires the
key-focus once prompted, so provide a focusActor property (defaulting to the
sourceActor) that can be set in order to define the actor to give the
keyboard focus to, when the menu is popped-up.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1604https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/720
The menu item ornament is used to put dots or checks in menus or otherwise
to define a padding for a label.
However in some cases we want to create a menu item with no left (in ltr)
padding.
In order to do that, define a HIDDEN Ornament mode that completely hides the
ornament actor.
The naming here might be confusing as this should probably be called NONE,
while the default mode is the invisible one, but it's too late to change it
now.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/720
While commit 3094f863 was intended to cancel the ongoing idle hide
timeout before we start a new one, a mistake slipped in there while
rebasing: Obviously we should check if the signal id is NOT 0 here.
This didn't prevent timeouts being started while old ones are still
running and did override `this._idleHideOverlayId`, which caused the old
timeouts to run indefinitely after an overlay actor was destroyed
because we fail early (and don't return TRUE) in `_idleHideOverlay()`.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/735
Indicate whether dropping an app icon was successful or not by using the
newly added `animateLaunchAtPos()` API of AppIcon which starts a zoom
out animation of the icon at the position the drop happened.
To get the position of the drag actor, we have to forward the arguments
passed to `acceptDrop()` and `handleDragOver()` to the internal drag
handlers of the WorkspaceThumbnails. We can use this position directly
without transforming it to stage coordinates because the actor is a
child of `Main.uiGroup` and the animation actor will also be a child of
this container.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/121
Add a `animateLaunchAtPos()` method to the AppIcon class to animate the
launch of an app at a given position. This allows for a visual
indication of whether dropping an app icon using DnD was successful at
the position the drop happened in a later commit.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/121
Return the results of calls to acceptDrop that we forwarded to the
Workspace object.
This fixes a bug where app icons that were dragged and released above a
window clone would get animated back to their original position
(indicating that nothing happened) even though they opened correctly.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/121
We allow opening new windows as a fallback in case the app doesn't give
us explicit information about it, but we don't want to allow opening new
windows if we're unable to ask for this information (we can only use the
APIs to get this information while the app is RUNNING).
So always return FALSE in case the app is STARTING, always return TRUE
in case the app is STOPPED (starting an app always opens a new window)
and go through the usual checks in case the app is RUNNING (and
eventually fall back to FALSE).
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/121
`AppIcon.shellWorkspaceLaunch()` can easily be replaced by checking for
`AppIcon.app` and calling `AppIcon.app.open_new_window()` directly.
For compatibility and to prevent breaking extensions implementing the
function, keep supporting the `shellWorkspaceLaunch` API in AppIcon
while logging a deprecation warning. Also keep supporting the API on
drag sources (without deprecating it) to allow extensions to define
custom actions on their drag sources.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/121
The use of box-shadow on a StWidget that has a background-gradient was
not been rendered correctly, the shadow borders was calculated inside
the st_theme_node_prerender_shadow function and in the case that we've a
prerendered_texture the max_borders was not calculated and are 0.
This patch creates a new static function to compute shadow maximum
borders copying the code from st_theme_node_prerender_shadow, and call
this new method in the case that we've a prerendered_texture.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1186
If the search entry does not have any text typed in and a button press
happens outside of the search entry, we set key focus to NULL to make
the search entry appear unfocused.
This is quite intrusive and can easily cause unwanted focus changes, so
change the captured-event handler to only call `reset()` if the search
entry actually is focused.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/683
Instead of returning and waiting until the old timeout is finished,
start a new idle hide timeout for the overlay when the pointer enters a
window clone. This makes sure the timeout for hiding the overlay after
the pointer left the clone mostly stays the same (except when leaving
the clone via the title or the close button).
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/683
As arrow functions have an implicit return value, an assignment of
this.foo = bar could have been intended as a this.foo === bar
comparison. To catch those errors, we will disallow these kinds
of assignments unless they are marked explicitly by an extra pair
of parentheses.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/731
Calling await in a loop means the asynchronous operations are
run sequentially instead of in-parallel. Usually that's not
what's wanted, so eslint has a rule to warn about this.
However here we use async/await to handle control back to the
mainloop between steps, so running operations sequentially is
actually intended.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/731
The intention of the code is clearly to operate on a copy, but that's
not how the Object constructor works. While it doesn't matter in
practice that we modify the passed-in object parameter, it's still
a good idea to fix the code.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/731
They didn't just allow for the style patterns they were added to,
but allowed for some messed up indentation to slip through. Now
that we adapted the code to not use the old style, it's time to
drop the exceptions.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/725
The legacy indent rule currently ignores arrow functions in parameters
to allow callbacks to not align with the other arguments:
this._someFunctionWithFairlyLongishName(arg1, arg2, arg3,
() => {
this._someOtherFunctionWithLongName(arg1);
});
But as ignoring entire nodes means we can end up with arbitrary
indentation, we should drop the exception. While this would make
the above "illegal" under the legacy config, it conforms with the
non-legacy style, so everything should be fine ...
... except that eslint starts to complain about some function args
that should be fine under the legacy config. Maybe it's thrown off
by the function-arg-in-arrow-function-in-function-arg structure, but
rather than figuring it out, let's just move those to the new style.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/725
We are currently inconsistent whether to put the operators in front
of the corresponding line or at the end of the preceding one. The
most dominant style for now is to put condition and first branch on
the same line, and then align the second branch:
let foo = condition ? fooValue
: notFooValue;
Unfortunately that's a style that eslint doesn't support, so to account
for it, our legacy configuration currently plainly ignores all indentation
in conditionals.
In order to drop that exception and not let messed up indentation slip
through, change all ternary operators to the non-legacy style.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/725
Some more places where the indentation doesn't comply with either
the old or new style. They slipped through because the legacy eslint
configuration accounts for some patterns by plainly ignoring certain
nodes. We'll address that later, first fix up the indentation errors.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/725
The indicator for the active workspace is currently two pixels
smaller because it doesn't account for the border used for
inactive workspaces.
Fix that to make sure all indicators have the same size.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1243
When there is a transition, it's likely that we are animating some part
of the desktop, and in such situations we don't want to unredirect
fullscreen windows.
This fixes unwanted unredirection when e.g. hiding a modal dialog by
re-enabling the unredirection after the animation has finished, instead
of when it starts.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/721
Updating the window list in the Looking Glass is a costly
operation: it destroys a whole lot of actors, and recreates
them. This triggers CSS changes, repaints, and allocations.
It is specially bad when paired with Wayland's big number
of window creations and deletions when showing Builder's
and Epiphany's popup window.
Only update the window list in the Looking Glass when it is
visible.
Related: https://gitlab.gnome.org/GNOME/mutter/issues/556https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/719
We aren't quite ready to enforce non-legacy style for now, mostly due
to the xgettext bug that prevents us from using template strings in
some places, and vast amounts of legacy indentation.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/716
Now that we fixed all pre-existing errors that are common between
regular and legacy configuration, we can stop filtering the result
by the lines modified by the merge request.
This will allow us to catch errors in merge requests that slipped
through until now, for example when leaving a newly-unused import
behind.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/716
Since ES5, it is possible to create objects with no prototype at all:
let foo = Object.create(null);
Those object won't have any builtin properties like hasOwnProperty(),
which is why eslint added a corresponding rule to its default rule set.
While this isn't an issue that affects our code, there's no harm in fol-
lowing the recommendation and call the method through Object.prototype.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/716
We currently use no less than three different ways of indenting
object literals:
let obj1 = {
foo: 42,
bar: 23,
};
let obj2 = { foo: 42,
bar: 23 };
let obj3 = { foo: 42,
bar: 23
};
The first is the one we want to use everywhere eventually, while the
second is the most commonly used "legacy" style.
It is the third one that is most problematic, as it throws off eslint
fairly badly: It violates both the rule to have consistent line breaks
in braces as well as the indentation style of both regular and legacy
configurations.
Fortunately the third style was mostly used for tween parameters, so
is quite rare after the Tweener purge. Get rid of the remaining ones
to cut down on pre-existing eslint errors.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/716
Since disabling an extension will lead to disabling and re-enabling all
following extensions in the list, always disable multiple extensions by
looping through the list in reverse order.
This lowers the execution time of the event handlers quite a bit if many
extensions are installed.
Thanks to Philippe Troin for identifying the problem and proposing the
initial patch to change the extension order when reloading.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/177https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/96
Only push uuids of newly enabled extensions to the `_extensionOrder`
array if enabling them was successful.
Otherwise, since `_callExtensionDisable()` doesn't remove uuids that
weren't successfully enabled from the array, those extensions get added
to the array multiple times when they're disabled and enabled.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/96
It's currently possible to circumvent the `sessionMode.allowExtensions`
property: For already enabled extensions one can call reloadExtension
via DBus, for new extensions it's possible by adding the extension to
the enabled-extensions gsettings key and setting the
disable-extension-version-validation key (which triggers a reload of
`this._enabledExtensions`) and then calling reloadExtension via DBus.
So to enforce `allowExtensions` while still allowing to update
extensions and keeping the extensionSystem synced with various gsettings
keys, replace the checks for `this._enabled` with simple checks for
`Main.sessionMode.allowExtensions` inside `_callExtensionInit()` and
`_callExtensionEnable()`.
The remaining checks for `this._enabled` are only small optimizations to
prevent running code on irrelevant sessionMode updates.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/96
Right now we're only handling added sessionMode extensions correctly on
sessionMode updates, also handle the other case and disable removed
sessionMode extensions on sessionMode updates.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/96
Instead of only logging a message that loading the extension stylesheet
failed and silently returning we should use `logExtensionError` for that
instead. This also sets the extension state to ERROR and makes sure we
don't try to enable it again.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/96
If the extension doesn't exist in the `this._extensions` Map, we'd try
to access `extension.dir` on undefined/null. So set the `dir` variable
after checking if `extension` is defined.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/96
If there's a stubborn process in our cgroup, we shouldn't hang around
waiting for the default (30 seconds) before the session closes. We've
logged out, SIGTERMed and the thing is refusing to go away, let's not
make people hang around for ages.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/699
Code and comment were based on the old get_input_rect() and get_outer_rect()
method names that were changed to the more appropriate get_buffer_rect() and
get_frame_rect() a long time ago.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/713
The animation was removed in commit 6a00a504d4 for consistency with
other menus. However commit a9b12d5d73 then *added* animations to
those just four minutes later.
So add back the original animations for consistency, both with menu
closing and with other menus.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1595
Remove transitions of the `slide-x` property of the layout manager
before we set the property to a fixed value, otherwise the transitions
might still be running and change the value after we set it.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/707
When selecting an area for screenshot we monitor the events while we've valid
coordinates in order to redraw the rubber band.
However, we don't stop ignore the motion events after button release and so
while animating. This might cause an unwanted effect if moving the mouse away
during fade out that is way more visible slowing-down the animations.
To fix this ignore any motion event once we've set the results.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/711
Evolution draws in libsoup, which exposes deprecated types in its
API. While its headers have been fixed to guard the affected symbols,
those fixes aren't in our CI images yet.
Until we get a fixed version, just disable all deprecation warnings
during the include in order to not trip over "foreign" bugs.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/709
We aren't using any deprecated evolution-data-server API, so we can
turn it off; this avoids compiler warnings for glib deprecations
used by those functions, which makes it harder to spot warnings for
our own code base.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/709
Add a new popover with a regular entry + button to rename
folders. The layout is similar to other GNOME applications.
The popup is implemented as a PopupMenu subclass, leaving
the grab management to PopupMenuManager.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/675
We disable and enable extensions inside the `notify::active` signal
handler, but we shouldn't do that in case the change didn't come from
the user but because something else changed the state of the extension.
This causes an issue when the extensionPrefs window is open and the
session gets locked: The extensions are temporarily disabled by the
shell, extensionPrefs updates its switches on the state change and adds
those extensions to the `disabled-extensions` gsettings key inside the
signal handler. Now when the session is unlocked again, the extensions
won't be enabled again since they're forced-disabled.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/705
We're using a vfunc override for `get_paint_volume` to exclude children
with an opacity of 0 from the paint volume and thus decrease the size of
the area we need to paint.
Now if the paint volume is requested during the spring animation (the
real icons are hidden using an opacity of 0 and clones are used for the
animation), `get_paint_volume` returns a paint volume with a height of
0. After that, the spring animation finishes and the icon-opacities are
set to 255 in `_resetAnimationActors`, and since we cache paint volumes
and there's no reason for Clutter to assume it got invalid, the icons
end up not being painted.
Fix this by queuing a relayout of the grid when the opacity of a child
is changed from or to 0, which manually invalidates the paint volume.
The reason why this is not an issue with the paginated icon grid
(all-apps view) is probably because StScrollView invalidates the paint
volume a lot more often than regular containers.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1502
Extensions might emit JS errors explicitly or implicitly, however GNOME
Shell doesn't present any stack trace for those making them quite hard
to debug.
Make this easier by logging errors with logError() whichs includes the
stack dump.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/700
When the GridSearchBase actor is destroyed we should remove the
ongoing later that might try to access to invalid resources.
To do this, add an _onDestroy() callback function to SearchResultsBase
and override it in GridSearchBase.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/700
Easing calls on show/hide functions have some parameters in common whether the
radial effect is enabled or not.
So instead of doing repeated calls with similar parameters, initialize common
values in params objects.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/700
If the resource scale or the scale factor changes while the animation
is playing, we need to stop the animation and start it again once the
texture is loaded, as the idle might try to access an invalidated
animation child otherwise.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/700
We translate the raw stream content far too directly into a char*,
it notably forgets that the stream does not have nul-ended data,
this means we are potentially adding garbage after the pasted content.
Tentatively fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1570
Commit 21e14bd46f fixed this for the
brightness slider, but we have the same problem for volume too. When the
volume is muted - for example in Settings or via a media key, we update
the slider to '0' to indicate this visually. But we also actually invoke
the slider's callback to *set* the volume to zero. That means that the
previous level is overwritten so it can't be restored when unmuting.
The fix is the same - when we update the slider internally ourselves,
don't call the signal handler.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1557
We now do 2 things along Xwayland startup/shutdown:
- Start or stop the gnome-session-x11-services target, that will
pull all X11 related services that the session might depend on.
- As we start ibus-daemon manually, trigger a restart in order to
toggle the XIM daemon on and off along with Xwayland presence.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/680
We may need to restart it with different arguments, so make it
possible to do that. Also, avoid to just restart it on _clear(),
this is now most likely through our --replace call than it is
through ibus-daemon eg. dying, avoids some noise in logs as
there is already an ongoing ibus-daemon.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/680
An Endless OS system was found in the wild with a malformed
.local/share/gnome-shell/notifications which causes _loadNotifications()
to raise an exception. This exception was not previously handled and
bubbles all the way out to gnome_shell_plugin_start(), whereupon the
shell exit(1)s. The user could no longer log into their computer.
Handle exceptions from _loadNotifications(), log them, and attempt to
continue. Ensure that this._isLoading is set to 'false' even on error,
so that future calls to _saveNotifications() can overwrite the (corrupt)
state file.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1552
An Endless OS system was found in the wild with a malformed
.local/share/gnome-shell/notifications. When deserialized in Python,
after passing trusted=True to g_variant_new_from_bytes(), the first
element of the first struct in the array looks like this:
In [41]: _38.get_child_value(0).get_child_value(0)
Out[41]: GLib.Variant('s', '\Uffffffff\Uffffffff\Uffffffff\Uffffffff\Uffffffff')
When deserialised in GJS, we get:
gjs> v.get_child_value(0).get_child_value(0)
[object variant of type "s"]
gjs> v.get_child_value(0).get_child_value(0).get_string()
typein:43:1 malformed UTF-8 character sequence at offset 0
@typein:43:1
@<stdin>:1:34
While g_variant_new_from_bytes() doesn't have much to say about its
'trusted' parameter, g_variant_new_from_data() does:
> If data is trusted to be serialised data in normal form then trusted
> should be TRUE. This applies to serialised data created within this
> process or read from a trusted location on the disk (such as a file
> installed in /usr/lib alongside your application). You should set
> trusted to FALSE if data is read from the network, a file in the
> user's home directory, etc.
Persistent state is read from the user's home directory, so it should
not be trusted. With trusted=False, the string value above comes out as
"".
I don't have an explanation for how this file ended up being malformed.
I also don't have an explanation for when this started crashing: my
guess is that recent GJS became stricter about validating UTF-8 but I
could be wrong!
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1552
Instead of going via the MetaShapedTexture to get the cairo surface, get
it from the window actor. The window actor can then handle this in a way
that makes it include potential subsurfaces.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/692
The updatesPermission is currently initialized synchronously, which
blocks the Mainloop for quite some time and therefore slows down startup
of the shell, let's do it asynchronously instead.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/689
Using the bus name to notify service startup to systemd has some
disadvantages. The main one being that systemd will consider a
gnome-shell restart (Alt+F2 r) a service failure and restart the shell,
cleaning up all its children (i.e. user launched applications). In the
future the shell should launch applications in their own transient unit
so that a service restart does not affect applications.
Another potential issue is that we must never load
gnome-shell-wayland.service and gnome-shell-x11.service at the same
time, as systemd does not like two services providing the same bus
name.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1496https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/690
Mutter's Clutter fork can no longer be initialized separatedly, as
its backend now draws from MetaBackend. Adjust the code to use the
newly added test initialization function instead to get the test
back up.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/691
Clutter's backend code depends on MetaBackend now, which makes it
impossible to initialize without resorting to private mutter API.
Luckily we only need Clutter for interactive tests which are broken
anyway, as Clutter.main() and friends were removed a while ago.
So for now, get at least unit tests working again by simply the
unnecessary Clutter initialization.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/691
Since we now put a short timeout in before the start of the actual pie
timer we don't start the timer as often as we used to. This allows us to
create a new PieTimer object each time a timeout is started and
therefore play a finish animation independently of other (new) timeouts.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/688
If the circle is complete and the pie timeout finished, we don't need
the lines to the center point indicating the ends of the pie anymore.
We just draw a clean circle instead, which allows for a zoom-out and
fade animation of the circle when we're done.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/688
If the pie timeout has finished successfully there's no need to cancel
the pie animation, instead we can just wait for that animation to finish
and show some visual feedback like a zoom-out animation to indicate the
click afterwards.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/688
Fade the pie timer in using a duration of 1/4 of the timeout and a
EASE_IN_QUAD animation. This significantly reduces flickering of the pie
timer while moving the cursor and makes the timer less distracting.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/688
gjs no longer has an implicit dependency on GTK 3.0, so without
requesting an explicit version, we will get the highest available.
Our code isn't GTK-4 ready, so request 3.0 explicitly.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/686
Popups and other override-redirect windows are meaningless to everything
that depends on the ShellWindowTracker. Ignoring those windows will result
in less ShellApp::windows-changed signal emissions, and less activity in
the AppMenuButton and everything else that depends on them.
Reduces gnome-shell CPU activity while typing on the Epiphany addressbar,
as the pop up animation there results in a number of xdg_popup being
created and destroyed.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/642https://gitlab.gnome.org/GNOME/mutter/issues/556
Now that we allow to disable session mode extensions, it can be useful
to reset an extension to its original state, that is disabled in the
regular session, but possibly enabled via the session mode.
Add a corresponding command.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1234
Change both 'enabled-extensions' and 'disabled-extensions' keys as in
commit ce1bee727. While those actions are now also exposed by the
shell's D-Bus API, there is some value in allowing the tool to be used
outside a running GNOME session (for example in setup scripts), so
keep changing the GSettings keys directly.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1234
With the addition of the 'disabled-extensions' key in commit ce1bee727,
the way extensions are enabled/disabled changed: Now a UUID is always
added to one list and removed from another.
Prepare for that by generalizing the relevant bits of the existing
enable/disable commands as helper functions.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1234
The ability to install unaudited extensions directly from a zip file
can be useful for testing and code review, so implement a corresponding
command that complements the previously added 'pack' command.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1234
Extensions are uploaded to extensions.gnome.org as zip files that
not only contain the extension sources, but also compiled GSettings
schemas and message catalogues. To make this more convenient, add
a corresponding command for creating an archive suitable for up-
loading.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1234
We already support displaying extension details for the list command,
so it's a logical extension to also support showing extension info
for a particular extension (not least because the shell has a
corresponding D-Bus method).
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1234
In addition to a plain list of all extensions, add options to display
additional details of each extensions and to filter the list by
enabled state or install location.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1234
This implements more functionality of the existing tool and, as
'reload' is an unreliable feature that doesn't work more often
than not, the last bit that we will replicate.
The command follows the original for the most part, with the most
important difference being the installed template, which doesn't
provide any sample functionality and uses modern JS syntax.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1234
This replicates the most basic functionality of the existing
gnome-shell-extension-tool, albeit using a git/gio/gsettings
style command interface rather than plain options; this will
allow us to implement more complex commands that have options
on their own in the future.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1234
Before the move to Clutters implicit animations with 0846238f6 and
bf497ed64, we used Tweener to do a fake-animation of the opacity and
Tweeners `onUpdate` signal to queue a repaint of the PieTimer everytime
Tweener tries to update the animation.
Now, with Clutters implicit animations, there is no `onUpdate` signal
anymore and also `notify::opacity` no longer gets emitted since the
value doesn't actually change. This lead to the PieTimer no longer being
repainted, which broke the animation.
Fix this by implementing the current angle of the pie using a custom
GObject property `angle` and animating this property using the new
`actor.ease_property` method.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1533
When cancelling the animations of the icon grid, right now we simply
destroy all the clones without resetting the opacity and making the
actor reactive again. So if the spring animation to show the grid is
cancelled by pressing a key to start a search, the icon clones would be
destroyed, but the icon-opacity would still be set to 0. Now if the
Escape key is pressed, viewSelector will show the last active page (ie.
the iconGrid) without a custom animation and only fade in the page, and
because the icons still have an opacity of 0, they will be invisible.
Fix this by always restoring the opacity and reactive property of the
original actors if the animation is cancelled instead of only destroying
the clones.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/678
Since we set the proxy value when the slider changes and set the slider
value on proxy property changes, we run into a cycle.
Before commit 3d3dca4aa this was addressed by not notifying on all slider
changes, but only in reaction to direct user action. Given that since the
splitting out of the BarLevel class those events are handled in a subclass,
that approach is at least unconvential and fairly fragile.
Instead, make the brightness indicator ignore any changes to the slider it
initiated itself.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1500
With 8b368d010 we fixed a bug where the onComplete callback was always
called no matter whether the transition was interrupted before or not.
This exposed another bug: viewSelector depends on this behaviour when
fading out pages: After fading out a page, we call `this._animateIn` to
show the new page. Now if the fade-out animation gets interrupted, with
the correct behaviour of onComplete we end up not showing a new page and
the viewSelector remains empty instead. One case where this happens is
when pressing a key to start a search during the overview-animation.
Obviously we also want to show the new page in case the fade-out
animation was interrupted, so use the onStopped callback instead of the
onComplete callback here.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/674
An actor ease callback could destroy the actor, in such case we should do not
touch the actor anymore.
So, before calling the callback, reset restore the easing state and don't
perform any further action with it.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1507
When a drag is cancelled and the source actor
is visible, the drag actor is animated back to
the source position. The scale that the drag
actor will become is calculated as:
scale = this._dragActor.width / sourceScaledWidth
However, this is wrong; what we wanted to do
is the opposite:
scale = sourceScaledWidth / this._dragActor.width
Fix the scale calculation to match the math
above.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/671
Create a new folder when dropping an icon over another
icon. Try and find a good folder name by looking into
the categories of the applications.
Delete the folder when removing the last icon.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/671
Because the Dash icons are not drop targets themselves,
add a tiny DashIcon class, which is an AppDisplay.AppIcon
subclass, and disable all DND drop code from it.
Show a folder preview when dragging an app icon over another
app icon.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/671
As per design direction, scale and fade the app icon
when starting dragging it, and show it again if the
drop is accepted. Clutter takes care of animating the
rest of icon positions through implicit animations.
Scale and fade the dragged icon while it's being dragged.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/671
Since the `notify::allocation` signal will obviously get emitted while
the actor is inside an allocation cycle and we might end up doing
changes to its allocation inside `updateSearch` by hiding or showing the
actor (which queues a relayout), we get a warning from Clutter.
Fix this by delaying the call to the parent method until the next
redraw, which should happen a few moments after the current relayout.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/672
Since commit 1a27ff6130 we use the
allocation width of the GridSearchResults actor to calculate the max
number of results that can be shown for this search provider.
On the first run of the search, when no previous (cached) allocation is
available for the actor of GridSearchResults, the allocation width used
in `_getMaxDisplayedResults` will be 0, which in turn will make
`updateSearch` filter out all results returned by the search provider.
Now if this search provider is the only search provider that's enabled,
after calling `updateSearch`, the `SearchResults` class will call
`_updateSearchProgress` to check if any results are visible, assume
nothing was found and therefore hide the scrollView. This in turn causes
the GridSearchResults actor to not get a new allocation, which prevents
our code to fixup the max number of results on `notify::allocation` from
working: The number will continue to be 0 and we'll never show any
results.
To fix this regression, return -1 in `_getMaxDisplayedResults` if the
allocation width is 0 to inform `updateSearch` that we can't calculate
the maximum number yet and interpret a return value of -1 as "show all
results" in `updateSearch`. The same problem would probably also appear
if the allocation width is anything between 0 and the width of the
iconGrid with one icon in it, although this might as well be a valid
width in case a very small screen is used or with very large icons. So
let's only check for a width of 0 and hope the GridSearchResults actor
won't get weird temporary allocations in that range.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/672
Just as we animate the apps launch using the zoom out animation if the
'new-window' action provided by the app is launched, we should also show
this animation if the 'activate-discrete-gpu' action provided by the app
via its AppInfo is launched.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/673
For the "New Window" entry we add to the AppIcons popup menu we should
always animate the app icon if the menu entry is activated as it was
intended by commit 62786c09a8.
For the "Launch using Dedicated Graphics Card" entry we can also always
show the animation if the entry is activated since the entry should only
be visible if the app is stopped.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/673
Clocks has exactly the same issue as Weather: Its integration currently
relies on accessing its settings directly, which isn't possible when
the app is sandboxed.
Fix this the same way we did for Weather, by adding our own setting
and syncing it with the app via a custom D-Bus interface.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1158
We add our own "New Window" menu entry if the app doesn't already
provide a 'new-window' action. For this menu entry, we show the zoom out
animation on the app icon when the user clicks the entry.
To be consistent in case the app already provides its own 'new-window'
action via its AppInfo, also show the zoom out animation when this
action is activated.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/662
Whenever an app is installed, the usual routine is
to run 'gtk-update-icon-cache' after installing all
of the app's files.
The side effect of that is that the .desktop file of
the application is installed before the icon theme
is updated. By the time GAppInfoMonitor emits the
'changed' signal, the icon theme is not yet updated,
leading to StIcon use the fallback icon.
Under some circumstances (e.g. on very slow spinning
disks) the app icon is never actually loaded, and we
see the fallback icon forever.
Monitor the icon theme for changes when an app is
installed. Try as many as 6 times before giving up
on detecting an icon theme update.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/661
The texture cache, right now, only monitors for
complete theme changes. If the contents of the
icon theme change, however, the texture cache
isn't properly invalidated.
This manifests itself as a randomly reproducible
bug when installing an app; the app icon may be
the fallback forever, or as long as something else
updates the icon theme.
Watch for the GtkIconTheme:changed signal, and
evict the texture cache when the theme changes.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/661
As pointed out by designers, fading it signals that the
icon grid is not a drop target, when now it actually is.
Remove the fade effect applied to the icon grid when
dragging. Since this is the only caller of fadeIn() and
fadeHalf(), also remove these methods.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/664
App icons inside folders are already animated when the folder is
opened, but moving an app icon from a folder doesn't, making the
transition abrupt.
Fortunately, it's easy to detect icons that were previously hidden
but are not anymore.
Add an animation to these icons when showing.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/664
This is necessary for being able to drag application icons
to folders in different pages.
Add a drag motion handler to AllView and handle overshoots
when dragging. Only handle it when dragging from AllView.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/664
After dropping an application into the folder icon, the
list of applications is updated but the folder icon itself
is not.
Introduce BaseIcon.update() and call it from FolderIcon
when redisplaying.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/664
The event blocker is an actor that is added in between the
icon grid and the app folder popup in order to guarantee
that clicking outside the app folder will collapse it.
However, the next patch will require allowing dragging events
to be passed to folder icons, and the event blocker gets in
our way here, preventing drag n' drop to work properly.
Add an API to inhibit the event blocker. This API will be
used by the app folders while an item is dragged.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/664
When plugging in a device with sensors that are unsupported by
iio-sensor-proxy, the proxy may quit so fast that the name disappears
from the bus before we get to construct the SensorProxy in response
to the name-appeared handler, resulting in the following warning:
JS ERROR: TypeError: this._sensorProxy is null
_sensorProxyAppeared/this._sensorProxy<@resource:///org/gnome/shell/misc/systemActions.js:217:17
_makeProxyWrapper/</<@resource:///org/gnome/gjs/modules/overrides/Gio.js:243:21
Address this by creating the proxy unconditionally instead of monitoring
the bus name, and using the g-name-owner property to determine whether
iio-sensor-proxy is active.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1357
When transitioning to or from the overview, windows travel
a certain distance between their real desktop position and
their place in the overview window grid. The less this travel
distance is, the smoother, more polished, and less jarring
the overall transition looks. This is why it makes sense to
try reordering and repositioning windows to minimize their
travel distance. That being said, there are other factors
that impact the quality of the overview layout, such as how
much the windows get scaled and what portion of the overall
available space they take up.
The existing code tries to minimize the travel distance by
sorting the windows in each row by their horizontal position.
There are, however, two problems with this implementation.
First, it compares the coordinates of windows' left edges as
opposed to their centers, which means it yields unexpected
results when a small window is positioned next to the left
edge of a large window. Second, it completely disregards
vertical coordinates, instead assigning windows to the grid
rows using their monotonically increasing window numbers,
effectively vertically sorting them by the order they were
created in.
This commit changes both vertical and horizontal ordering
to work based on the coordinates of the geometric centers
of the windows. That is to say, windows are first assigned
to grid rows based on the vertical coordinates of their
centers, and subsequently sorted inside each row based on
the horizontal coordinates of said centers. In my testing,
this leads to a much more intuitive and visually pleasing
window placement.
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/267
GDBusProxy::g-properties-changed is also emitted when the name drops from
the bus, at which point any properties will be null. That's not a valid
gsettings value, so to avoid the corresponding warning, move the g-name-owner
check accordingly.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1158
Those checks were carried over from the very first DND implementation;
if they were ever actually required at all, this is no longer the case
as we moved away from Tweener for all our animations.
The number of cases where an extension is still using Tweener, creates
draggable actors, *AND* requires the checks for proper functioning
should be indistinguishable from zero, so drop the code.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/669
By now, Tweener is used exclusively to animate changes to the
StAdjustment:value property. But not for long, as now that we
implement the same transition API as Clutter.Actor, we can
re-use the existing convenience method for property transitions
for adjustment changes as well.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/669
StAdjustment implements the ClutterAnimatable interface, so we can
already animate its properties with ClutterPropertyTransitions.
But as it is currently not possible to associate a transition with
an adjustment, it must be owned (and kept alive in case of GC) by
the calling code.
Change that by implementing the same (add|remove|get)_transition() API
as ClutterActor, so we can use a familiar API and even duck typing in
case of javascript.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/669
The tracking was important in an earlier iteration, but as the helper
functions now remove overwritten transitions before setting up the
new ones, we can just as well connect to the ::stopped signal directly.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/668
This is rather embarrassing - we currently confuse the transition with
the finished parameter, which means we always run the onComplete handler
no matter whether the transition was interrupted or actually completed.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/668
Commit 0f178c3b3d added a shortcirtuit to avoid running
an animation on an invisible actor. However, it introduced
a bug where the current page is not properly updated. That
leads to the wrong set of icons being animated under some
circumstances.
Update the current page even if we bail out early.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/667
Properties that aren't marked as animatable don't support *implicit*
animations, but they can still be animated with explicit transitions.
Use the newly added convenience method to cut down further on Tweener
usage.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/666
While we are now using implicit animations for all animatable properties,
there are still some cases where we animate other actor properties (for
example from a custom subclass) or associated objects like effects.
Those can still be animated using Clutter animations, as long as we use
the explicit API rather than implicit animations. Again this API is
cumbersome and tricky enough to warrant a convenience wrapper.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/666
Clutter animations work on GObject properties on animatables. The
last commit took care of the latter by turning all animated objects
into actor subclasses, now it's time to make all properties used
in Tweens into GObject properties.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/666
We have a couple of places where we don't tween the actor, but a
custom property on the delegate object. In order to move those
to Clutter animations, we will need an animatable, so turn those
objects into widget subclasses.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/666
The set_brightness() method is the most convenient way of controlling
the effect's brightness, but Clutter animations only deal with properties,
so start using the (ClutterColor) brightness property instead.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/666
Currently WindowDimmer exposes a JS property that is used to control the
underlying effect. This works fine with Tweener, but not with Clutter
animations which we want to use ultimately.
As a first step towards that, expose a setDimmed() method instead of
the property and handle the animation internally, so it can be adapted
more easily.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/666
We now have everything in place to replace Tweener for all animatable
properties with implicit animations, which has the following benefits:
- they run entirely in C, while Tweener requires context switches
to JS each frame
- they are more reliable, as Tweener only detects when an animation
is overwritten with another Tween, while Clutter considers any
property change
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/22
Setting up implicit animations is more verbose than using tweener, in
particular when setting up a callbacks to run on overwrite or completion.
In order to make its use more convenient, monkey-patch ClutterActor
with an ease() method that works similarly to Tweener.addTween().
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/22
Being able to slow down animations is a helpful debugging tool; to not
lose it when starting to use Clutter's implicit animations, monkey-patch
the appropriate methods to support our global slow down factor.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/22
As we currently use Tweener for all animations, we have a single place
for hooking up the enable-animations and slow-down-factor settings.
However that will no longer hold true when we'll start to use Clutter's
built-in animation facilities, so add a small helper function that
applies the necessary adjustments.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/22
Notifications use a transition that overshoots the target value, however
we can only really do that for the position and not the opacity where
some values would end up out of the valid range.
We currently address this by proxying the actual opacity property in a
javascript property, and clamp it to the valid range in an onUpdate()
callback.
This won't be an option if we want to use Clutter animations, so instead,
use separate tweens for opacity and position.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/22
Unlike Tweener, which doesn't know or care about actor state, Clutter
will skip implicit animations on actors that aren't mapped. This makes
sense of course, but it will break the page indicator animation we
do on map: When we get notified about the container being mapped, the
individual indicators (which are the actors being animated) are still
unmapped.
Resolve this by deferring the animation to a LaterFunc.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/22
For animating the arrows on the screenshield, we currently use a custom
transition function that tweens the opacity from 0 to maxOpacity in the
first half of the animation, and from maxOpacity back to 0 in the second
half.
This doesn't easily translate to Clutter's own animation framework, so
replace the custom transition with two consecutive tweens which do.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/22
Dash items are currently animated via the custom "childScale" and
"childOpacity" properties. However since commit efb3025d8c, those
properties actually control the scale-x/scale-y and opacity properties
of the actor itself (not the child), so cut out the intermediate
custom properties in favor of the "real" ones.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/22
When expanding a submenu, we currently use a single tween to animate
both the submenu actor and the source arrow. We do this by tweening
a monkey-patched JS property on the main actor, which we then use
to update the arrow's GObject property on updates. As Clutter cannot
animate random JS properties, this trick will prevent us from using
implicit animations here.
The only reason I can think of for using a single tween is to keep
both animations in perfect lock step, but as expansion and rotation
are visually quite distinct, this shouldn't be required, so just
set up separate animations for each actor.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/22
We currently only consider a remote "app.new-window" action when running,
but not a fixed "new-window" action in the .desktop file. The latter is
clearly useful as well, in particular as open_new_window() already does,
so add it.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/665
Now that redisplaying is a lightweight operation that only
adds and removes what changed, we can not be concerned about
redisplaying on folder changes.
Redisplaying will be necessary when custom order in the app
grid is implemented, in order to update not only which icons
are hidden, but also their position.
Call _redisplay() in AllView when folders change.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/645
FolderView and AllView currently check if the item is
present in the BaseAppView._items map, in order to avoid
adding the same icon multiple times.
Now that BaseAppView._loadApps() has a different role --
it returns a list with all app icons, and BaseAppView
diffs with the current list of app icons -- checking the
BaseAppView._items map is wrong.
Make sure there are no duplicated items in the temporary
array returned by all _loadApps() implementations. Remove
the now unused BaseAppView.hasItem() method.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/645
BaseAppView currently removes all icons, and readds them, every
time the list of app icons needs to be redisplayed. In order to
allow animating app icon positions in the future, however, we
cannot destroy the actors of the app icons.
Previous commits paved the way for us to do differential loading,
i.e. add only the icons that were added, and remove only what was
removed.
Make the BaseAppView effectively implement differential loading.
The BaseAppView.removeAll() method is removed, since we do not
remove all icons anymore. BaseAppView._loadApps() now returns an
array with the new apps, instead of putting them directly at the
BaseAppView lists.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/645
Next commit will introduce differential loading of
app icons, and will reorganize this part of the
codebase.
When doing that, the ideal symmetry of the new code
would be:
* Update BaseAppView._allItems array
* Update BaseAppView._items map
* Update BaseAppView._grid actor
Move the code in _loadGrid() into _redisplay() so that
we can check in-place which new icons need to be added.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/645
Now that the three views follow the exact same loading routine
(remove all + load apps + load grid), we don't need each view
call loadGrid() directly anymore.
This is an important step in order to animate adding and removing
icons, since now we can diff old and new app icons properly.
Move all calls to BaseAppView.loadGrid() to a single one after
BaseAppView._loadApps(). Also add the underscore prefix, since
this is now considered a protected function.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/645
FrequentView is another view that is slightly not unified with how
BaseAppView expects subclasses to load app icons. Instead of using
BaseAppView.addItem() and then calling BaseAppview.loadGrid(), it
adds the app icons directly to the icon grid.
Make FrequentView add icons using BaseAppview.addItem(), and load
the icons using BaseAppView.loadGrid().
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/645
Future patches will diff the old and new icons of views, in order to
animate them when necessary (e.g. adding an app icon to a folder, or
from a folder back to the app grid). In order to do that, all views
must be streamlined in how they load app icons.
Currently, FrequentView and AllView are already following the behavior
expected by BaseAppView, but FolderView isn't. Its icons are loaded by
FolderIcon, and FolderView doesn't implement BaseView._loadApps(),
which makes it impossible to diff old and new apps.
Move the app icon loading routine from FolderIcon to FolderView, by
implementing the _loadApps() method.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/645
The different units - seconds for Tweener and milliseconds for
timeouts - are not a big issue currently, as there is little
overlap. However this will change when we start using Clutter's
own animation framework (which uses milliseconds as well), in
particular where constants are shared between modules.
In order to prepare for the transition, define all animation times
as milliseconds and adjust them when passing them to Tweener.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/663
The existing units were never used as the corresponding support was
never merged into gnome-session.
This commits updates units to be usable with the newer gnome-session
unit definitions. Also added is appropriate failure/restart logic
including the ability to disable extensions. Note that extensions will
only be disabled if a failure happens in the first two minutes after
login.
https://gitlab.gnome.org/GNOME/gnome-session/merge_requests/13https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/507
As gnome-shell is a required component for GNOME sessions, gnome-session
will currently always try to autostart it. However as we are moving towards
using systemd's user instance for session startup, gnome-session should only
be responsible for launching the shell when either not running under systemd
or when we were built without systemd support.
gnome-session can detect the former but not the latter, so communicate this
via the newly added X-GNOME-HiddenUnderSystemd key in the .desktop file.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/507https://gitlab.gnome.org/GNOME/gnome-session/merge_requests/13
The eslint wrapper script is useful for development as well, but it currently
fails on systems where bash is not installed in /usr/bin.
Make it useful there as well by changing the shebang to use /usr/bin/env
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/655
Our current Weather integration depends on poking around the app's
settings, which we cannot do when the app is sandboxed (as its
filesystem is "hidden away" in a container in that case).
So instead, use our own GSettings schema for the settings, and sync
it with GNOME Weather via a custom D-Bus interface.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1158
`g_object_notify()` actually takes a global lock to look up the property
by its name, which means there is a performance hit (albeit tiny) every
time this function is called. For this reason, always try to use
`g_object_notify_by_pspec()` instead.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/652
Since commit 007d30573 we use an actor effect to apply the radial effect and
we pass the effect to the tweener in order to animate it.
However, we always still remove the previously added tween from the actor,
instead that from the actual target.
So, depending the radial effect state, remove the tweens from the proper target
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/653
In `st`, we can do this by using `ST_PARAM_*`. In the other code files,
just use `G_PARAM_STATIC_STRINGS` directly.
This is just a minor convenience to prevent a few unnecessary string
copies.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/646
We currently assume that user icons are square, which is the case when
set by the users settings panel, but not enforced by AccountsService.
Handle that case by moving the pixel size back to the actor and using
an appropriate background-size style property of 'cover' (which means
the smallest dimension of the image is scaled to fit the desired size).
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1144
A generic, introspectable Shader effect is not only more flexible
than a shader actor, it will also make it much easier to turn
Lightbox into an actor subclass and replace Tweener with Clutter's
own animation support.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/651
Due to typecasting being done when converting floats to integers in
gnome-settings-daemon, a volume of 0.9% in g-s-d will end up as 0% in
gnome-shell. This can lead to a mismatch of icons between the volume OSD
(the icon to use is determined by g-s-d itself) and the shells own
volume indicator (the icon to use is determined by the shell using the
volume received from g-s-d).
To fix this, simply get rid of the conversion from float to percentage
in g-s-d and back to floats in the shell and just send a float/double
value on DBus.
https://gitlab.gnome.org/GNOME/gnome-settings-daemon/merge_requests/78https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/385
LevelBar is not really used, all the checks are implemented inside
BarLevel as well and the accessible name is wrong because the osdWindow
doesn't only show the volume, but also the brightness and other things.
The workaround for updating the bars width is also no longer needed now
that we have BarLevel.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/385
There are some cases (for example when tweening value changes), where
the level will be set to the same value it already is at. Avoid those
unnecessary repaints by checking whether the value is already used and
returning if it is.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/385
The check is supposed to run for all merge requests that touch javascript
files, but for some reason I see it's skipped quite often. Better have
the test run unnecessarily some times than let bugs through, so remove
the limitation.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/647
When a MR uses a private namespace, "origin" refers to that, and its
master branch may be outdated with regard to upstream master.
We are really only interested in checking the line changes from the commits
in the MR, so figure out the correct branch point instead.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/647
AppIcon makes itself draggable, and handles the various DnD
routines such as 'drag-begin' and 'drag-end' by making the
Overview emit the appropriate signals.
However, when destroyed, the AppIcon does not try to finish
any drag operations that started. That causes the event
blocker in AllView not to be updated correctly when dragging
icons to outside folders.
Make AppIcon emit 'item-drag-end' when a drag operation
started and it's destroyed.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/643
We have now reduced the number of eslint errors enough to add it to
the CI pipeline. There are still plenty of errors left though, so we
cannot simply run eslint and fail on any errors. So instead, run it
through a fancy script that:
- generates an eslint report using the "regular" configuration
- generates an eslint report using the "legacy" configuration
- creates a combined report with errors common to both configurations
When the pipeline is running for a branch or tag, the final report is
printed out and the job succeeds (we know there are errors left);
when the pipelne is running for a merge request, we fail if any errors
are reported for the lines modified/added by the MR.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/627
GNOME apps use 'review' for the CI stage that generates and exports a
flatpak bundle after a successful build, so they need some other name
for anything that is checked before building; that's how we ended up
with the somewhat awkward 'source_check' stage (inherited from Polari).
But since the commit log check added a 'review' stage that runs pre-build,
use that for all checks that are performed before the build stage.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/627
The functions here are asynchronous to handle control back to the
mainloop while waiting for an action to complete, not to run operations
in parallel. That is, the race condition the rule is protecting against
isn't an issue here, so disable the error.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/627
For GObject properties, we follow the convention of all-lowercase,
dash-separated names. Those translate to underscores in getters/setters,
so exempt them from the newly added "camelcase" rule.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/627
While we aren't using those destructured variables, they are still useful
to document the meaning of those elements. We don't want eslint to keep
warning about them though, so mark them accordingly.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/627
Those unused arguments aren't bugs - unbeknownst to eslint, they all
correspond to valid signal parameters - but they don't contribute
anything to clarity, so just remove them anyway.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/627
Unused variables or arguments can indicate bugs, but they can also
help document the code, in particular in case of signal handlers
and destructuring.
Account for this by keeping the error, but set up patterns that allow
us to opt out of if for individual variables/arguments. For arguments
we pick a '_' prefix, while for variables we go with a suffix instead,
to not accidentally exempt private module-scope variables.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/627
This was left-over in commit 2743f18af, and probably is the real reason
why the busy spinner wasn't using the shared AnimatedIcon.Spinner class:
The animation there was much slower.
Still, let's keep the code as-is for now, if we really need a different
animation time, we can add an optional constructor parameter to the
Spinner class.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/640
At the moment the only way to open a folder icon is to click on it;
there's no API to open the icon programmatically.
This commits adds an open method and makes the click handler use
it.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/628
When a FolderIcon is opened, it asks the parent view to allocate
space for it, which takes time. Eventually, the space-ready
signal is emitted on the view and the icon can make use of the new
space with its popup. If the icon gets destroyed in the
interim, though, space-ready signal handler still fires.
This commit disconnects the signal handler so it doesn't get called
on a destroyed icon.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/628
It is important that the FolderView of a FolderIcon always
gets destroyed before the AppFolderPopup, since the view
may or may not be in the popup, and the view should
get cleaned up exactly once in either case.
This commit adds a destroy handler on FolderIcon to ensure
things get taken down in the right order, and to make sure
the view isn't leaked if it's not yet part of the popup.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/628
At the moment AppFolderPopup calls popdown on destruction,
which leads to open-state-changed getting emitted after
the actor associated with the popup is destroyed.
This commit handles ungrabbing and closing from an
actor destroy handler to side-step the open-state-changed
signal.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/628
If an icon already exists in an app view with the same id, the
duplicate is not added on a call to addItem. Unfortunately,
since it's not added, the icon actor gets orphaned and leaked.
This commit address the problem by introducing a new hasItem
method and disallowing callers to call addItem with a duplicate
in the first place.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/628
meta_later_add() is modelled after g_idle_add() and friends, and
the handler's boolean return value determines whether it should
be scheduled again or removed. There are some places where we omit
the return value, add them (although the implicit return value of
"undefined" already gives us the intended result).
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/637
The startup/busy indication in the app menu was left out of commit
22e21ad7d1 because it doesn't use a hard-coded image, but as the
image in the CSS is actually the same used by the spinner class,
drop the "custom" styling and use the regular spinner.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/636
While all javascript functions have a return value - either an explicit
one from a return statement, or an implicit "undefined" - mixing both in
the same function is almost certainly an oversight, and more often than
not a bug.
Enable the corresponding eslint rule to catch those errors.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/635
Trying to disable an extension that is enabled by the session mode
currently has no effect, which is clearly confusing. We could update
the various extension UIs to reflect that via sensitivity, but being
unable to configure extensions based on which session the user picked
at login isn't obvious either.
So instead, add a 'disabled-extensions' gsettings key to list extensions
that should not be enabled which takes precedence over 'enabled-extensions'
and can be used to disable session mode extensions.
https://bugzilla.gnome.org/show_bug.cgi?id=789852
Now that extension loading and the extensions map are no longer shared
between the gnome-shell and gnome-shell-extension-prefs processes, we
can move both into the ExtensionManager which makes much more sense
conceptually.
https://bugzilla.gnome.org/show_bug.cgi?id=789852
By direclty using the underlying GSetting, whether or not an extension
appears as enabled or disabled currently depends only on whether it is
included in the 'enabled-extensions' list or not.
However this doesn't necessarily reflect the real extension state, as an
extension may be in error state, or enabled via the session mode.
Switch to the extensions D-Bus API to ensure that the list of extensions
and each extension's state correctly reflects the state in gnome-shell.
https://bugzilla.gnome.org/show_bug.cgi?id=789852
Extensions are used to calling the getCurrentExtension() utility function,
both from the extension itself and from its preferences. For the latter,
that relies on the extensions map in ExtensionUtils being populated from
the separated extension-prefs process just like from gnome-shell.
This won't be the case anymore when we switch to the extensions D-Bus API,
but as we know which extension we are showing the prefs dialog for, we
can patch in a simple replacement that gives extensions the expected API.
https://bugzilla.gnome.org/show_bug.cgi?id=789852
Each row represents an extension, so it makes sense to associate the
rows with the actual extensions instead of linking rows and extensions
by looking up the UUID in the external extensions map in ExtensionUtils.
This will also make it much easier to stop using the shared extension
loading / map in favor of the extension D-Bus API.
https://bugzilla.gnome.org/show_bug.cgi?id=789852
Whether or not an extension can be enabled/disabled depends on various
factors: Whether the extension is in error state, whether user extensions
are disabled and whether the underlying GSettings keys are writable.
This is complex enough to share the logic, so add it to the extension
properties that are exposed over D-Bus.
https://bugzilla.gnome.org/show_bug.cgi?id=789852
The existing 'ExtensionStatusChanged' signal has a fixed set of parameters,
which means we cannot add additional state without an API break. Deprecate
it in favor of a new 'ExtensionStateChanged' signal which addresses this
issue by taking the full serialized extension as parameter.
https://bugzilla.gnome.org/show_bug.cgi?id=789852
Serializing an extension for sending over D-Bus is currently done by the
appropriate D-Bus method implementations. Split out the code as utility
function and add a corresponding deserialization function, which we will
soon use when consuming the D-Bus extension API from the extension-prefs
tool.
https://bugzilla.gnome.org/show_bug.cgi?id=789852
Extensions are currently enabled or disabled by directly changing the
list in the 'enabled-extensions' GSettings key. As we will soon add
an overriding 'disabled-extensions' key as well, it makes sense to
offer explicit API for enabling/disabling to avoid duplicating the
logic.
For the corresponding D-Bus API, the methods were even mentioned in
the GSettings schema, albeit unimplemented until now.
https://bugzilla.gnome.org/show_bug.cgi?id=789852
While public methods to enable/disable extensions make sense for an
extension manager, the existing ones are only used internally. Make
them private and rename them, so that we can re-use the current
names for more useful public methods.
https://bugzilla.gnome.org/show_bug.cgi?id=789852
The extension system started out as a set of simple functions, but
gained more state later, and even some hacks to emit signals without
having an object to emit them on.
There is no good reason for that weirdness, so rather than imitating an
object, wrap the existing system into a real ExtensionManager object.
https://bugzilla.gnome.org/show_bug.cgi?id=789852
It makes sense to keep extension-related enums in the same module instead
of spreading them between ExtensionSystem and ExtensionUtils.
More importantly, this will make the type available to the extensions-prefs
tool (which runs in a different process and therefore only has access to
a limited set of modules).
https://bugzilla.gnome.org/show_bug.cgi?id=789852
Since -Werror=missing-braces is used, having missing braces warnings
aren't allowed. However, the first member of struct sigaction is a union
whose first member is a pointer, causing clang to produce warnings when
it is initialized to { 0 }.
Instead of initializing to a zero value, we can specify values of
members directly in the initializer to avoid warnings.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/633
Commit bd18313d12 changed to a new naming scheme for battery icons,
and used to old icon names as fallback-icon-name for compatibility
with older/other icon themes.
However that fallback code isn't working correctly, as GThemedIcon's
default fallbacks will transform a name of `battery-level-90-symbolic`
to a list of names:
- `battery-level-90-symbolic`
- `battery-level-symbolic`
- `battery-symbolic`
The last one frequently exists, so instead of the intended fallback,
we end up with a generic battery icon.
Address this by specifying the icon as GIcon instead of an icon-name,
where we have more control over how the icon is resolved.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1442
Glib stopped providing any fallback implementations on systems without
memmove() all the way back in 2013. Since then, the symbol is a simple
macro around memmove(); use that function directly now that glib added
a deprecation warning.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/632
Just as we did for the workspace switcher popup, support workspaces
being laid out in a single row in the window picker.
Note that this takes care of the various workspace switch actions in
the overview (scrolling, panning, touch(pad) gestures) as well as the
switch animation, but not of the overview's workspace switcher component.
There are currently no plans to support other layouts there, as the
component is inherently vertical (in fact, it was the whole reason for
switching the layout in the first place).
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/575
While mutter supports a variety of different grid layouts (n columns/rows,
growing vertically or horizontally from any of the four corners), we
hardcode a fixed vertical layout of a single column.
Now that mutter exposes the actual layout to us, add support for a more
traditional horizontal layout as well.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/575
Extension preferences Application class is just a container for a GtkApplication
so instead of using composition we can inherit from the base GObject class.
Also replace signal connections with vfunc's.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/631
In some cases the style-changed signal hasn't been emitted when
_computeLayout() is called, resulting in the use of the default spacing
and item size values for the calculations.
One case where this happens is when starting a search. Right after the
initialization of GridSearchResults, _computeLayout() is called from
_getMaxDisplayedResults() and the style-changed signal hasn't been
emitted yet. The computed layout will be wrong and the maximum
number of results will also be wrong.
To prevent this from happening, make sure the style has been updated
before doing the calculations in _computeLayout().
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/110
The calculation of how many results can be shown in GridSearchResults is
broken: The width of the parent container (resultsView.actor) we're
using as the maximum width right now is the width of the scrollView of
SearchResults (which always expands to the whole screen size). This
width will only be correct if the scrollView (ie. the whole screen) is
smaller than the max width of searchResultsContent, which only is the
case for screens smaller than 1000px.
To fix the calculation, use the width of our own actor and don't get it
using clutter_actor_get_width(), but using the last allocation of the
actor. This way we don't get the preferred width if the actor is not
allocated at this point (it's hidden by _ensureProviderDisplay() when
starting a new search).
Then, when the allocation of the actor changes, rebuild the grid search
results by calling updateSearch() with the old arguments to ensure the
number of visible results is correct. The fact that we're only listening
for allocation changes here is the reason why we never want to use the
preferred width of the actor inside _getMaxDisplayedResults(): While
the actor is hidden clutter_actor_get_width() would return the preferred
width, which we'd then use the as the maximum width. But if the actor
had a correct allocation before, no notify::allocation signal will be
emitted when the actor is shown again because the allocation is still
the same, and we'll end up using the preferred width as maximium width
forever.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/110
Unlike the app grid, we show the search results while the dash is hidden
and with a small scrollbar instead of page indicator dots. This
means there's nothing the search results might horizontally overlap
with and the padding here is unneccessary.
The spacing between the search results and the screen edges is still
sufficient because of the paddings applied to searchResultsContent.
On very small screens (< 1000px), this allows the search results to
utilize a lot more of the horizontal screen space.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/110
The functionality the searchResultsBin container provides can easily be
moved into a subclass of St.BoxLayout, no need for an additional StBin.
The "searchResultsBin" css class isn't used in the stylesheets either.
Same with the scrollChild container.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/110
Object.prototype.hasOwnProperty() is more precise than checking for
falsiness, for instance the following is true:
{ foo: undefined }.hasOwnProperty('foo');
However when checking for a handler ID, a more relaxed check is more
appropriate, as particularly 0 is not a valid handler ID.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/626
Regarding coding style, gjs is moving in a direction that departs quite
significantly from the established style, in particular when indenting
multi-line array/object literals or method arguments:
Currently we are keeping those elements aligned, while the gjs rules now
expect them to use the regular 4-space indentation.
There are certainly good arguments that can be made for that move - it's
much less prone to leading to overly-long lines, and matches popluar JS
styles elsewhere. But switching coding style implies large diffs which
interfere with git-blame and friends, so in order to allow for a more
gradual change, add a separate set of "legacy" rules that match more
closely the style we would expect up to now.
It also disables the rules for quotes and template strings - the former
because we cannot match the current style to use double-quotes for
translatable strings and single-quotes otherwise, the latter because
template strings are still relatively new, so we haven't adopted them
yet.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/609
All variables should be in camelCase, so configure the corresponding
rule to enforce this. Exempt properties for now, to accommodate the
existing practice of using C-style underscore names for construct
properties of introspected objects.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/609
We replaced all Lang.bind() calls with arrow functions or the standardized
Function.prototype.bind(), at least for the former eslint has some options
to ensure that the old custom doesn't sneak back in.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/609
gjs doesn't include any gettext wrappers, and obviously can't know
about the shell's global object, so include those in the list of
globals for all sources in the gnome-shell context.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/609
gjs started to run eslint during its CI a while ago, so there is an
existing rules set we can use as a starting point for our own setup.
As we will adapt those rules to our code base, we don't want those
changes to make it harder to synchronize the copy with future gjs
changes, so include the rules from a separate file rather than using
the configuration directly.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/609
For some reason, people are still seeing those after commit d5ebd8c8.
While this is something we really should figure out, we can work around
the issue by keeping the view actors hidden until the update is complete.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1065
Window previews are sometimes shown translucent, for example during
drags or animations. They can also have attached dialogs, in which
case the opacity should affect the combination of all windows instead
of being applied to each window individually, blended together, so
make sure they are redirected as a whole when necessary.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/774
Whether people love or hate the hot corner depends in large extents
on hardware sensitivity and habits, which is hard to get right
universally. So bite the bullet and support an option to enable or
disable hot corners ...
https://bugzilla.gnome.org/show_bug.cgi?id=688320
GNOME Shell is spitting out some errors in the journal due to its attempts
to speak to PackageKit, which is not present on Endless OS, so let's add
some runtime checks to make sure that PackageKit is actually available
before assuming so and using its proxy to decide which kind of UI to
show to the user when ending the session.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/369
st_theme_node_paint_equal() was originally added to preserve paint state
when a style change didn't affect any of StWidget's cached background
resources.
That's why using it for filtering out unneeded style changes as in commit
f662864a misses any non-background related properties that are relevant
for subclasses. Add additional tests to make sure we keep emitting the
signal in those cases.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1212
This is a small convenience wrapper around clutter_color_equal()
for the different color components, which also handles the case
where one (or both) of the icon colors are %NULL.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1212
The first parameter to Object.assign() is the same target object that
will be returned. That is, since commit 46874eed0 Params.parse() modifies
the @defaults object. Usually we pass that parameter as an object literal
and this isn't an issue, but the change breaks spectacularly in the few
cases where we use a re-usable variable.
Restore the previous behavior by copying the object first.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/615
Standard javascript now has Object.assign() which is very similar to
Params.parse(), except that the latter by default disallows "extra"
parameters. We can still leverage the standard API by simply
implementing the error check, and then call out to Object.assign()
for the actual parameter merging.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/612
Since priv->device gets set to NULL inside st_button_release, ungrab the
input device before calling st_button_release and avoid
clutter_input_device_ungrab failing with a critical error.
This fixes a regression introduced with
d5a1a888d9
While at it, also remove the superfluous line resetting priv->device to
NULL and move the check for priv->grabbed into an elseif block since
there should be no case where StButton has both grabs at the same time.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/614
- generate the OSK key colors from variables in _colors.scss without changing the design
- add hover and active colors for all key, not only letter keys
- use $button_radius for the OSK keys, buttons and entries (no value change for the latter)
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/610
Braces are optional for single-line arrow functions, but there's a
subtle difference:
Without braces, the expression is implicitly used as return value; with
braces, the function returns nothing unless there's an explicit return.
We currently reflect that in our style by only omitting braces when the
function is expected to have a return value, but that's not very obvious,
not an important differentiation to make, and not easy to express in an
automatic rule.
So just omit braces consistently as mandated by gjs' coding style.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/608
While we have some style inconsistencies - mostly regarding split lines,
i.e. aligning to the first arguments vs. a four-space indent - there are
a couple of places where the spacing is simply wrong. Fix those.
Spotted by eslint.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/608
We are currently inconsistent on whether case labels share the same
indentation level as the corresponding switch statement or not. gjs
goes with the default of no additional indentation, so go along with
that.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/608
Starting an object literal with a comment throws off eslint's rules
for brace style (newline between brace and properties for both opening
and closing brace or neither) as well as indentation (fixed four-space
indent or align with the previous argument).
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/608
Using multiple spaces after property names in order to align the
values isn't something we do elsewhere.
Instead, align the values by using a fixed 4-space indent as preferred
by gjs nowadays.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/608
The current code is carefully avoiding an overly wide line length as
well as adding literal new lines to the string due to indentation. It's
clever and barely legible.
Instead, use one string per line similar to how they appear in the actual
output, and join them together when setting the clipboard text.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/608
When destructuring multiple return values, we often use trailing commas
to indicate that there are additional elements that we are ignoring.
There isn't anything inherently wrong with that, but it's a style that's
too confusing for eslint - on the one hand we require a space after a
comma, on the other hand we require no space before closing brackets.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/607
We are currently inconsistent with whether or not to put a space
after catch clauses. While the predominant style is to omit it,
that's inconsistent with the style we use for any other statement.
There's not really a good reason to stick with it, so switch to
the style gjs/eslint default to.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/607
While allowed by the syntax, they are problematic because the
variable is in the scope of the switch() statement, but only
valid if a particular case clause is reached.
Add braces to limit the variables' scope to the corresponding
case clause to avoid that problem.
Spotted by eslint.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/607
Converting a variable to a particular type can be done explicitly (with
functions like Number() or toString()) or implicitly by relying on type
coercion (like concatenating a variable to the empty string to force
a string, or multiplying it with 1 to force a number).
As those tend to be less readable and clear, they are best avoided. So
replace the cases of string coercion we use with template strings, and
clarify the places that can be confused with number coercion.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/607
We can use that newer method where we don't care about the actual position
of an element inside the array.
(Array.includes() and Array.indexOf() do behave differently in edge cases,
for example in the handling of NaN, but those don't matter to us)
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/152
Control flow statements like return, break or continue are considered
unsafe in finally blocks, as they take precendence over any control
flow statement in the try and catch blocks, which may be unexpected.
This isn't the case here as the statement in the finally block is the
only one, but we can just as well avoid the finally block altogether
and use a regular return statement.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/606
This vfunc override has been introduced to ensure app icons are always
squared, but since the container of the AppIcon gets a square allocation
anyway if the 'square' property of the SwitcherButton is set, there's
no need to return a special width here.
Without the override we can also stop setting the size of the iconBin
manually. And since shell_app_create_icon_texture() uses logical pixels
but clutter_actor_set_size() uses screen pixels, that means we now no
longer set the size of the icon back to the unscaled value after it was
already correct.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1325
We're calculating icon sizes for the alt tab switcher early and at a
point where the style attributes of this._list are not loaded yet. To
make sure the value of this._list.spacing is correct, call
ensure_style() on this._list before accessing the spacing.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/587
The polkit password dialog has a spinner that gets displayed
while the users password is being verified.
Unfortunately, the spinner stop method unintentionally calls
back into itself after the stop fade out animation is complete.
The stop method is called at startup, so the looping begins as
soon as the dialog is visible and continues until the dialog is
dismissed.
This commit fixes the loop by having the stop method cease
calling itself, and instead having it call the stop method on the
superclass.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/602
The polkit password dialog has a spinner that gets displayed
while the users password is being verified.
Unfortunately, the spinner stop method unintentionally calls
back into itself after the stop fade out animation is complete.
The stop method is called at startup, so the looping begins as
soon as the dialog is visible and continues until the dialog is
dismissed.
This commit fixes the loop by having the stop method cease
calling itself, and instead having it call the stop method on the
superclass.
While the confirmation dialog for extension installation is simpler
than - say - authentication dialogs, it still makes sense to re-use
the common content layout instead of duplicating it.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/600
Using one variable to initialize all gestures will update the address of
the "gesture" pointer with every newly initialized object. This means
that event handlers which also use the "gesture" pointer like the
'keyboard-visible-changed' handler will update a different gesture as
soon as the pointer is changed.
This lead to a bug where the handler of 'keyboard-visible-changed'
wrongly nabled the unfullscreen gesture. Fix that by assigning each
gesture its own variable.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/598
In practice this has been seen to fail:
JS ERROR: TypeError: active.get_devices(...)[0] is undefined
ensureActiveConnectionProps@resource:///org/gnome/shell/ui/status/network.js:73:22
_getMainConnection@resource:///org/gnome/shell/ui/status/network.js:1791:13
_syncMainConnection@resource:///org/gnome/shell/ui/status/network.js:1809:32
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1406
Since commit 520cea9394, the opacity of icon grid children is used
both to skip children outside the current viewport and to hide the
real icons while animating icon clones.
As a result, a grid animation during an animation now ends up showing the
icons that are being animated. Avoid that glitch by leaving children's
opacity alone when there's an ongoing animation.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/582
AllView's adaptToSize is called as part of viewStack allocation vfunc, and this
makes the adjustment value to be reset while relayouting.
So, fix this by delaying this using the Meta later that we already had for
pageIndicators operations.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/1392
Since the repositioning is now done during allocation, we can just queue
a relayout when setting the boxpointer positioning via the source actor.
As per this _relayout() and _updateFlip now needs to be called during allocation
only and with an allocation box set.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/576
Changing the arrow side might need to reposition the boxpointer, however
if this happens during allocation, we don't need to trigger a new relayout since
we'd set the new allocation once _updateFlip's _reposition call is terminated,
otherwise if the position has changed, changing the boxpointer coordinates
will trigger a relayout anyways.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/576
As per commit 044572cb60 boxpointer uses its own coordinates to position itself.
However this would lead to warning when mutter-clutter is compiled with debug
options as we'd might try to set the box coordinates during the allocation
cycle.
So, when calling _reposition during allocation, instead of setting the actor's
coordinates we just pass the allocation box and we adjust its origin, in order
to set it properly in the vfunc.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1382https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/576
Hiding a child implies a parent reallocation, and IconGrid does it for the
children that doesn't fit in the available space, but this could lead to an
allocation recursion cycle. This has been introduced by commit 0e0574a0 to
reduce CPU usage not to using JS vfuncs.
To avoid this, toggle the children opacity instead so that we can achieve the
same visibility result, without any reallocation need.
In this way we also fix the case where hidden children can be shown again,
as _getVisibleChildren doesn't filter-out transparent ones, restoring the
pre-commit 0e0574a0 behavior.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1336https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/559
Background is monitoring the whole `org.gnome.desktop.background` gsettings keys
for changes connecting to the non-specialized 'changed' signal and re-emitting
this as-is.
This means that when the background is changed via control-center, we get
multiple 'changed' signal events from GSettings, and for each one of this we
recreate a Background and a BackgroundActor.
Avoid this by using an idle to delay the emission of the 'changed' signal
grouping the events.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/558
The same Meta.Background could be used by multiple instances of background
actors, and so should not be disposed when the actor using it is destroyed.
Instead of calling `run_dispose` directly on it, just nullify the reference
on destroy method, leaving the job of doing the proper disposition to the
gabage collector that keeps the proper reference count on the Meta.Background.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/501https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/558
Adds the UI part for the pointer accessibility features.
The various timeouts running are notified using a pie-timer showing
under the pointer.
For dwell-click type selection, we use a drop-down menu. Users can
use the dwell-click to select the next type of dwell click to be
emitted.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/474
Since the removal of the old (pre-3.16) message tray, legacy tray icons
are very unlikely to be placed in a container that is animated using the
deprecated anchor point.
Just assume that the regular stage position is good enough.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/572
Starting from commit 7bb84dae, GrabHelper requires the owner to be an Actor as
we pass this to pushModal that assumes it to be as well.
So check that GrabHelper owner is an actor and throws an error if it is not the
case. This helps in tracking down issues such as gnome-shell-extensions!68
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/565
The `switch-to-application-n` shortcuts are essentially "launch the nth
app in the dash" actions, so they are at the very least confusing when
the dash isn't available because the overview itself is disabled (for
example in initial-setup mode).
So disable the shortcuts when the overview is disabled, but delegate the
decision to a separate function so that extensions like 'panel-favorites'
which expose favorites by some other means can easily re-enable them.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1333
A menu item activation might lead to a call to `itemActivated` which eventually
will close the menu which leads to a `PopupMenu.removeAll` that destroys all the
items, stopping the emission of the 'activate' signal for them.
Before commit 4258ae3e this was not happening because destroy'ing a javascript
object wasn't really disposing it and thus stopping the signal emissions.
So, ensure that `itemActivated` is called after that all the other callbacks
have been consumed, and so that the menu is closed as last thing.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1326https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/557
If the state we're trying to delete does not exist, do not log an
error.
Prevents this journal warning at startup:
gnome-shell[1082]: Could not delete runtime/persistent state file: Error removing file /run/user/1000/gnome-shell/runtime-state-LE.:0/screenShield.locked: No such file or directory
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/555
Instead of considering a GValue containing a NULL string to be a
programmer error, simply return NULL.
remove_mnemonics() is in fact called on the value of the
"choice-label" property as well, which has NULL as its default
value.
This prevents triggering the following gnome-shell warning:
gnome-shell[1082]: remove_mnemonics: assertion 'label != NULL' failed
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/555
Upon construction of the CDMA modem proxy, _reloadCdmaOperatorName()
is called and the value of the Sid property is read.
That property is defined as UINT32 in the D-Bus interface, but the
value may not be loaded yet after the proxy is constructed, in which
case its value will be null.
In _findProviderForSid(), we'll end up calling lookup_cdma_sid(null)
which fails with the following assertion:
gnome-shell[1082]: nma_mobile_providers_database_lookup_cdma_sid: assertion 'sid > 0' failed
This commit changes the (sid == 0) check in _findProviderForSid()
to (!sid) which will also catch the null case.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/555
The 'destroy' signal is emitted at the end of the destroy() method.
However the implementation of destroy() can end up emitting one of the
signals we connect to on the window, causing us to re-enter destroy
from its callback.
That will in turn lead to some objects getting disposed twice, which
produces a stack trace like the following one.
This commit fixes the issue by overriding the destroy() method instead
of connecting to the signal, which allows us to disconnect the signal
handlers from the window at an earlier time and avoid re-entrancy.
--
gnome-shell[1082]: Object Gio.Settings (0x7f0af8143f00), has been already deallocated — impossible to access it. This might be caused by the object having been destroyed from C code using something such as destroy(), dispose(), or remove() vfuncs.
org.gnome.Shell.desktop[1082]: == Stack trace for context 0x5627f7d1e220 ==
org.gnome.Shell.desktop[1082]: #0 5627f9e801a8 i resource:///org/gnome/shell/ui/messageTray.js:238 (7f0aefa9eca0 @ 22)
org.gnome.Shell.desktop[1082]: #1 5627f9e80108 i resource:///org/gnome/shell/ui/messageTray.js:802 (7f0aefaa2ee0 @ 28)
org.gnome.Shell.desktop[1082]: #2 5627f9e80070 i resource:///org/gnome/shell/ui/windowAttentionHandler.js:79 (7f0aef7b29d0 @ 62)
org.gnome.Shell.desktop[1082]: #3 7fffa69fbfc0 b self-hosted:979 (7f0aefa515e0 @ 440)
org.gnome.Shell.desktop[1082]: #4 5627f9e7ffe0 i resource:///org/gnome/shell/ui/messageTray.js:121 (7f0aefa9e1f0 @ 71)
org.gnome.Shell.desktop[1082]: #5 5627f9e7ff38 i resource:///org/gnome/shell/ui/messageTray.js:1408 (7f0aefaa58b0 @ 22)
org.gnome.Shell.desktop[1082]: #6 5627f9e7fe80 i resource:///org/gnome/shell/ui/messageTray.js:1237 (7f0aefaa51f0 @ 729)
org.gnome.Shell.desktop[1082]: #7 5627f9e7fde8 i resource:///org/gnome/shell/ui/messageTray.js:1055 (7f0aefaa3d30 @ 124)
org.gnome.Shell.desktop[1082]: #8 7fffa69ff8e0 b self-hosted:979 (7f0aefa515e0 @ 440)
org.gnome.Shell.desktop[1082]: #9 7fffa69ff9d0 b resource:///org/gnome/gjs/modules/signals.js:142 (7f0aefccb670 @ 386)
org.gnome.Shell.desktop[1082]: #10 5627f9e7fd58 i resource:///org/gnome/shell/ui/messageTray.js:479 (7f0aefaa0940 @ 50)
org.gnome.Shell.desktop[1082]: #11 5627f9e7fcb8 i resource:///org/gnome/shell/ui/messageTray.js:808 (7f0aefaa2ee0 @ 99)
org.gnome.Shell.desktop[1082]: #12 5627f9e7fc28 i resource:///org/gnome/shell/ui/windowAttentionHandler.js:69 (7f0aef7b28b0 @ 13)
org.gnome.Shell.desktop[1082]: #13 5627f9e7fb80 i resource:///org/gnome/shell/ui/main.js:566 (7f0aefcd8820 @ 216)
org.gnome.Shell.desktop[1082]: #14 5627f9e7fad0 i resource:///org/gnome/shell/ui/windowAttentionHandler.js:103 (7f0aef7b2c10 @ 27)
org.gnome.Shell.desktop[1082]: #15 5627f9e7fa58 i resource:///org/gnome/shell/ui/windowAttentionHandler.js:43 (7f0aef7b2700 @ 17)
org.gnome.Shell.desktop[1082]: #16 7fffa6a03350 b resource:///org/gnome/gjs/modules/signals.js:142 (7f0aefccb670 @ 386)
org.gnome.Shell.desktop[1082]: #17 5627f9e7f9d0 i resource:///org/gnome/shell/ui/messageTray.js:471 (7f0aefaa08b0 @ 22)
org.gnome.Shell.desktop[1082]: #18 5627f9e7f950 i resource:///org/gnome/shell/ui/calendar.js:752 (7f0aefaabdc0 @ 22)
org.gnome.Shell.desktop[1082]: #19 7fffa6a048f0 b self-hosted:979 (7f0aefa515e0 @ 440)
org.gnome.Shell.desktop[1082]: == Stack trace for context 0x5627f7d1e220 ==
org.gnome.Shell.desktop[1082]: #0 5627f9e801a8 i resource:///org/gnome/shell/ui/messageTray.js:239 (7f0aefa9eca0 @ 42)
org.gnome.Shell.desktop[1082]: #1 5627f9e80108 i resource:///org/gnome/shell/ui/messageTray.js:802 (7f0aefaa2ee0 @ 28)
org.gnome.Shell.desktop[1082]: #2 5627f9e80070 i resource:///org/gnome/shell/ui/windowAttentionHandler.js:79 (7f0aef7b29d0 @ 62)
org.gnome.Shell.desktop[1082]: #3 7fffa69fbfc0 b self-hosted:979 (7f0aefa515e0 @ 440)
org.gnome.Shell.desktop[1082]: #4 5627f9e7ffe0 i resource:///org/gnome/shell/ui/messageTray.js:121 (7f0aefa9e1f0 @ 71)
org.gnome.Shell.desktop[1082]: #5 5627f9e7ff38 i resource:///org/gnome/shell/ui/messageTray.js:1408 (7f0aefaa58b0 @ 22)
org.gnome.Shell.desktop[1082]: #6 5627f9e7fe80 i resource:///org/gnome/shell/ui/messageTray.js:1237 (7f0aefaa51f0 @ 729)
org.gnome.Shell.desktop[1082]: #7 5627f9e7fde8 i resource:///org/gnome/shell/ui/messageTray.js:1055 (7f0aefaa3d30 @ 124)
org.gnome.Shell.desktop[1082]: #8 7fffa69ff8e0 b self-hosted:979 (7f0aefa515e0 @ 440)
org.gnome.Shell.desktop[1082]: #9 7fffa69ff9d0 b resource:///org/gnome/gjs/modules/signals.js:142 (7f0aefccb670 @ 386)
org.gnome.Shell.desktop[1082]: #10 5627f9e7fd58 i resource:///org/gnome/shell/ui/messageTray.js:479 (7f0aefaa0940 @ 50)
org.gnome.Shell.desktop[1082]: #11 5627f9e7fcb8 i resource:///org/gnome/shell/ui/messageTray.js:808 (7f0aefaa2ee0 @ 99)
org.gnome.Shell.desktop[1082]: #12 5627f9e7fc28 i resource:///org/gnome/shell/ui/windowAttentionHandler.js:69 (7f0aef7b28b0 @ 13)
org.gnome.Shell.desktop[1082]: #13 5627f9e7fb80 i resource:///org/gnome/shell/ui/main.js:566 (7f0aefcd8820 @ 216)
org.gnome.Shell.desktop[1082]: #14 5627f9e7fad0 i resource:///org/gnome/shell/ui/windowAttentionHandler.js:103 (7f0aef7b2c10 @ 27)
org.gnome.Shell.desktop[1082]: #15 5627f9e7fa58 i resource:///org/gnome/shell/ui/windowAttentionHandler.js:43 (7f0aef7b2700 @ 17)
org.gnome.Shell.desktop[1082]: #16 7fffa6a03350 b resource:///org/gnome/gjs/modules/signals.js:142 (7f0aefccb670 @ 386)
org.gnome.Shell.desktop[1082]: #17 5627f9e7f9d0 i resource:///org/gnome/shell/ui/messageTray.js:471 (7f0aefaa08b0 @ 22)
org.gnome.Shell.desktop[1082]: #18 5627f9e7f950 i resource:///org/gnome/shell/ui/calendar.js:752 (7f0aefaabdc0 @ 22)
org.gnome.Shell.desktop[1082]: #19 7fffa6a048f0 b self-hosted:979 (7f0aefa515e0 @ 440)
gnome-shell[1082]: g_object_run_dispose: assertion 'G_IS_OBJECT (object)' failed
gnome-shell[1082]: Object Gio.Settings (0x7f0af8161750), has been already deallocated — impossible to access it. This might be caused by the object having been destroyed from C code using something such as destroy(), dispose(), or remove() vfuncs.
gnome-shell[1082]: g_object_run_dispose: assertion 'G_IS_OBJECT (object)' failed
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/555
Make the dialog a widget itself, removing the `_group` property used for
handling the actor.
Update all the inherited classes to be also GObject implementations, moving all
the signals to proper object ones.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/55
Since version 1.50.0, gjs defines GObject.NotImplementedError for throwing
errors when a "virtual" method that requires a subclass implementation is not
defined.
So use this instead of a generic JS Error in such cases.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/549
This extends the ShellMountPasswordDialog by widgets which allow
specifying parameters supported by TrueCrypt and VeraCrypt compatible
volumes (TCRYPT). This includes:
- Whether the volume to be unlocked is hidden.
- Whether the volume to be unlocked is a system partition.
Note: TrueCrypt and VeraCrypt only support encrypting Windows
systems [1], so the label for this option is "Windows System Volume".
- Whether to use a PIM [2].
- Whether to use keyfiles. Unfortunately, GMountOperation doesn't
support TCRYPT keyfiles, so if this checkbox is checked, we tell the
user that they should unlock the volume with Disks, which supports
unlocking TCRYPT volumes with keyfiles.
[1] https://www.veracrypt.fr/en/System%20Encryption.html
[2] https://www.veracrypt.fr/en/Header%20Key%20Derivation.htmlhttps://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/126
Mutter's CI now also builds gnome-shell to ensure that a MR doesn't
break the shell. Its docker image has therefore been updated to contain
all our deps as well, so we don't need our own image anymore.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/546
App IDs in gnome-shell don't match AppStream, Flatpak or Snap IDs. For the
desktop portal, the latter two are more relevant, so include it in the
returned information.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1289
The top_window_group is used for windows like popup menus, which should
appear above shell chrome like the panel.
Since we want important actors such as the screen keyboard or modal
dialogs to be shown above those windows, add their actors after adding
global.top_window_group to this.uiGroup and provide a new function
addTopChrome() to add important chrome above the top_window_group.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/917https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/358
Util.ensureActorVisibleInScrollView takes care of the potential scroll view fade
effect in order to compute the scroll offset, reading the ScrollViewFade's
`vfade-offset` property. This was correctly working until gnome 3.30 cycle.
However such property isn't defined now because since gjs 1.54, it can only
fetch introspected properties and St.ScrollViewFade was considered a private API
not exposed by gir.
Fix this by also introspecting st-scroll-view-fade sources.
Not being considered private anymore, install the header.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1061
Don't use composition for PopupBaseMenuItem, but instead inherit from BoxLayout.
So remove the internal actor, making all the menu items actor themselves.
Add an actor property as fallback to avoid warnings for usage in menus.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/499
Our search for system actions is currently inconsistent with searching
for applications: While we match terms anywhere within keywords, GIO
will only match at the beginning of words.
In order to get the same behavior, split keywords into single words
and only match terms at the beginning of a word.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/745
gjs now supports an optional GTypeFlags value for GObject subclasses
defined with GObject.registerClass(), so it is not possible to define
abstract classes on the gobject-level, just like from C.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/517
When toggling keyboard various times, we might get an error because trying to
disconnect an idle that isn't set anymore.
This is because when we remove the idle, we don't unset the ID.
Also clear the idle when destroying the keyboard.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/540
The current page is going to be destroyed as part of _onKeyboardGroupsChanged
cleanup, however we don't unset its pointer, and thus we'd might try to call a
function using an invalidated pointer.
So, unset the this._current_page reference when its get destroyed, connecting
to destroy signal when setting it and disconnecting when changing page.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1281https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/540
Updating the :first/:last-child pseudo classes can result in a lot
of unnecessary style changes when bulk-adding children to a container,
as every child ends up as the new last child.
Address this by deferring the style change to an idle, so we only do
the work once for the actual first and last child.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/529
The interface name when a device is added may not be the final one. For
example when using USB tethering, it will first appear as 'usb0' before
being renamed to something like 'enp0s20f0u1' depending on the port the
phone is plugged in.
As a result, we will ignore the new interface name in that case and fail
to associate the correct connection with the device: Instead of the
correct "USB Ethernet" (or user-customized name), it will show up as
"Ethernet".
Fix this by updating names and connections when a device's interface
property changes.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/534
This makes it possible to drag a window which appears connected with the
panel, even if it is not in focus. As a result, it should be easier to
manipulate side-by-side windows.
https://bugzilla.gnome.org/show_bug.cgi?id=679290
Images are loaded either with a supplied fixed size, or using the "native"
dimensions of the file. When creating a content image from the loaded data,
we currently simply apply this directly to the preferred size.
This works usually fine: GdkPixbuf will always keep the aspect ratio, so
if only one dimension is provided, the other will be adjusted accordingly:
Loading a 200x200 image with a requested size of (100, -1) will result in
a 100x100 content image.
There is a catch though: GdkPixbuf will only scale *down* to the requested
size, no up. That is, loading a 100x100 image with a requested size of
(200, -1) will result in a 100x100 pixbuf. But as we assume that the pixbuf
size matches the requested size, the image content ends up with 200x100.
Fix this by explicitly handling the case where only one size was supplied,
and make the other dimension take the aspect ratio into account
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/525
To prevent a small gap between windows in the workspace switching
animation, we temporarily shift windows up or down by the height of the
panel. This obviously breaks the animation for fullscreen windows, those
will overlap with the ones on the other workspace since there is no
panel shown in that case.
Fix this by checking whether the old or new workspace includes a
fullscreen window and don't shift the windows if there is one.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/757https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/322
Dialog's subtitle or body could not be properly wrapped, while it's ellipsized
when the text's width doesn't exceed the container size.
Clutter text has an `ellipsize` property, however in dialog's subtitle and body
we have been setting the `ellipsize-mode` property to Pango.EllipsizeMode.NONE
that is not present in the underlying GObject.
Not being an error in javascript, gjs didn't warn us about this, while at the
same time the St.Label's default Pango.EllipsizeMode.END was used.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/922https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/531
If an actor's allocation is outdated, clutter_actor_get_allocation_box()
will queue a relayout. That's why it's advised to not use the function
unless the allocation is known to be valid (namely during paint), but
in particular not from within get_preferred_width/height vfuncs.
Using the :allocation property (which may be outdated) would be better,
but in this case we can simply delegate the request to the correct actor.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1065
We were cleaning up self._groups, but the actors for all previous
groups/layers/modes would remain attached to the aspect container,
simply hidden.
Under some circumstances this can really make the amount of actors
in the shell stage to quickly ramp up, it's not just a "leak" but
also has potential side effects on performance.
We should destroy all child actors of this._aspectContainer, except
the static ones (emoji and keypad).
While at it, fix this._groups re-initialization, as it's actually an
object, not an array.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/523
Closes?: https://gitlab.gnome.org/GNOME/mutter/issues/556
We currently assume that every location has an associated timezone.
While this is sound in the real world, in practise it depends on
whether or not libgweather can find a corresponding timezone DB
entry.
This used to be a fringe case, but has become more likely when commit
https://gitlab.gnome.org/GNOME/libgweather/commit/d7682676ac9 moved
weather stations from cities to countries - the station itself is un-
likely to have a timezone entry, and the country may be part of more
than a single timezone.
It would be good for libgweather to return a timezone for those
locations again, but we should defend against the case anyway.
We cannot tell what time it is at a particular location without
knowing the timezone, so simply filter them out.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1062
The parameters that may affect the icon on ::style-changed are more size
related than visual (we listen to icon theme changes for the latter). It
makes sense to just update the icon if the size came out different.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/524
With a high enough amount of actors, there may be enough theme nodes and
signal connections on StTheme::custom-stylesheets-changed that
g_signal_handlers_disconnect_by*() on dispose becomes expensive, this may
become a surprisingly hot spot in StWidget::style-changed.
Keep the handler ID around and use g_signal_handler_disconnect() to avoid
linear lookups for the matching func/data.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/524
The top bar handles allocating all its children itself, so there's
little value in chaining up to st_widget_allocate() and get the
default layout manager allocating all children again (and possibly
differently).
If this happens, we end up with an infinite allocation cycle with
corresponding performance penalty. Fix this by just doing and what
Shell.GenericContainer did before commit 286ffbe2b6 replaced it,
and not chain up to StWidget.
Thanks to Robert Mader for debugging the issue.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1054
On one hand, we were using a path instead of an URI on
rsvg_handle_set_base_uri(). This broke at some point in librsvg
(presumably for the best, handling paths there sounds non-standard)
leaving a blank svg (As the base image wouldn't be accessed).
On the other hand, we use this with the deprecated rsvg_handle_write()
which we should drift away from.
Using rsvg_handle_new_from_stream_sync() neatly solves both. We use
newer API based on input streams and GFiles, and it internally does
the right thing, bringing the pad OSD back to life.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/1220
Classes that are sub-classes of GObject don't use a constructor per se, so we
can't check for new.target (as this is undefined) in _init.
Then compare the current constructor name instead.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/503
Classes that are sub-classes of GObject don't use a constructor per se, so we
can't check for new.target (as this is undefined) in _init.
Then compare the current constructor name instead.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/503
Unlike regular keys that generate key events from a virtual device,
emoji keys rely on the input method to insert the character. However
as the compositor cannot inject IM events into ibus, this only works
in the shell's own entries on X11.
We shouldn't expose mostly broken functionality to the user, so limit
the feature to the wayland session.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1172
Depending on how gitlab's CI checks out gnome-shell, the shell branch
may not have a local reference like "gnome-3-32", but only a remote
one like "remotes/origin/gnome-3-32".
Consider that case as well when looking for a corresponding mutter branch.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/511
If we don't find a branch that matches the branch used in the merge
request, we currently fall back to the non-merge-request matching,
i.e. first try the current shell branch, then fall back to master.
This should work for commits to upstream branches, but not for merge
requests to a stable branch. For those, the target branch name is
a better fallback.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/509
Move the signal handlers for changed settings to be connected after the
creation of the menu items to make sure a reference to the item is set.
While it also worked fine before, this solution certainly looks cleaner.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/512
A window being unmanaged can cause the ShellApp to be removed from
the ShellAppSystem, which if we are unlucky is the app's last
reference, causing it to be disposed and freed. It would be bad if this
happened before we finished handling the signal.
Use g_signal_connect_object to ensure that a reference is held to
the ShellApp for the duration of the signal handler, delaying its
last-unref.
In particular, when a signal handler calls _shell_app_remove_window(),
there is a brief period for which ShellApp breaks the intended
invariant (see !497) that app->running_state is non-NULL if and only if
app->running_state->windows is also non-NULL (non-empty). Freeing the
ShellApp at this point would cause a crash. This seems likely to be the
root cause of <https://gitlab.gnome.org/GNOME/gnome-shell/issues/750>,
<https://gitlab.gnome.org/GNOME/gnome-shell/issues/822> and
<https://bugs.debian.org/926212>.
Signed-off-by: Simon McVittie <smcv@debian.org>
Compare painting/geometry of old and new paint nodes, so it's ensured to
be only emitted on actual style changes. Emission still must be propagated
through to children, though.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/1153
At the point it is disabled, it has got signal handlers connected but
this._workspacesView is uninitialized. This triggers:
(gnome-shell:3993): Gjs-WARNING **: 18:49:53.281: JS ERROR: Exception in callback for signal: cancel: TypeError: this._workspacesViews is undefined
_endTouchGesture@resource:///org/gnome/shell/ui/workspacesView.js:527:25
_emit@resource:///org/gnome/gjs/modules/signals.js:142:27
set enabled@resource:///org/gnome/shell/ui/windowManager.js:478:13
WorkspacesDisplay<@resource:///org/gnome/shell/ui/workspacesView.js:482:9
ViewSelector<@resource:///org/gnome/shell/ui/viewSelector.js:167:35
ControlsManager<@resource:///org/gnome/shell/ui/overviewControls.js:405:29
init@resource:///org/gnome/shell/ui/overview.js:234:26
_initializeUI@resource:///org/gnome/shell/ui/main.js:184:5
start@resource:///org/gnome/shell/ui/main.js:124:5
@<main>:1:31
On startup. Shuffling these two lines prevent this from happening.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/506
The port away from the old Shell.GenericContainer actor turned many JS
classes with a corresponding actor property into Clutter.Actor subclasses.
For compatibility reasons, those properties were kept around for a while.
They were now removed and any code that still uses them should be adjusted.
Facilitate that transition by defining the compatibility property on
Clutter.Actor itself, but log a warning every time it is accessed.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/487
- simplify the close button to use blue, lighter blue and darker blue
solid disks for normal, hover and active states
- use a milky, transparent white border for the hover effect of the border
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/461
It may not be immediately obvious that the windows section is a
list of open application windows, as titles like "Downloads" can
easily be confused with an action. Add a section heading to avoid
confusion.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/968
We currently copy the app icon menu behavior, which puts a separator
between windows from the current workspace and windows from any other
workspace. It is more useful to have the windows section appear as a
clearly marked group, so drop the separator.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/968
Actors themed through CSS should ideally get sizes and positions that
conform to the "pixel grid". A notorious example is the panel that has a
height of 1.86em. On unchanged font settings and hidpi that translates to
55px, which leaves the workarea with "half pixels" that hidpi wayland
applications don't know how to fully cover.
If the requested height is a multiple of the scale factor, the workarea
and maximized applications can then work on full pixels.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/91
Work around a known regression from [1] that caused the volume bar in
the OSD window to never be hidden, even if the volume is set to 0. This
happened because the border radius of the barLevel is always drawn
without ensuring that the actual bar is visible.
So simply check if the value to draw is 0, and if it is, don't draw the
border radius of the bar at all. This will still result in incorrect
representation of values that have a width smaller than 2*border-radius,
but at least the bar looks right for a width of 0 now.
[1] https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/2https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/384
If a window gets destroyed right before it's resize
animation starts the user can get confronted with an undead
zombie clone that doesn't go away.
This commit makes sure said clones get reaped with their
actors.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1166
When determining the biggest icon size that fits the available height,
we first subtract the additional space requirements of icons (spacing,
padding, running indicator etc.) and then divide the result by the
number of icons to get the maximum size available to each icon texture.
In the above, the additional space requirement of each icon is taken
from the first icon (as all icons are assumed to be the same), and
calculated as the difference between the icon button's preferred height
and the currently used icon size.
To make sure that the icon is actually using the dash's current icon
size (even while animating to a new icon size), we enforce its height
during the size request and restore its original height afterwards.
However after some recent changes, that step is causing troubles:
For some reason, the original height may be 0, and when we restore it,
we end up forcing a fixed non-height that bypasses the regular size
request machinery.
While it is unclear where exactly the zero height comes from (maybe
waiting for a valid resource scale?), it is clear that it's best
to avoid forcing a fixed height. So instead of making the icon
texture comply with the assumed icon size, adjust the calculations
to use its current height request.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1053
We recently added offsets to world clocks that represent the location's
timezone as UTC offset. However for most users, that representation is
overly technical and less helpful than the difference to their local time.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1157
We currently use the city name for all location except named timezones.
However locations only have a city name if they are of level CITY or
DETACHED, or if they are of level WEATHER_STATION with a parent of level
CITY.
So when libgweather commit d7682676ac9 moved weather station locations from
cities to countries, it broke their names in the world clocks section.
To fix this, stop making assumptions about when we can use the city name
and simply try it first for all locations and fall back to the plain name
if its not available.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1150
After the Adwaita refresh, the button shows up oval rather than
circular. To address this, make sure that the "image-button" class
is applied as well by using the dedicated setter function.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/482
Compute the source actor workarea and allocation when repositioning and keep it
cached so that we've not to calculating it again in _calculateArrowSide.
Since _calculateArrowSide only is called inside _updateFlip that is always
called just after reposition, we can be sure that the computed values are still
correct.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/435
Currently all the widgets using BoxPointer and so popup actors are always drawn
at screen origin and then shifted at paint time in the proper position.
This doesn't work when using resource scale, since the widgets need to know
in which monitor they currently are in order to use properly scaled resources.
So, basically revert commit 22c22e0d7 and go back using the actual actor
coordinates for positioning and the actor translation for animating it, as the
relayouting issues of the past seem to be gone now.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1008https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/435
Inserting a workspace is implemented by appending a new workspace, then
shifting all windows after the "new" workspace up. This has an unintended
side effect on sticky windows, as changing its workspace will unstick it.
Fix this by excluding sticky windows - there's little point in moving them
anyway, given that they should be on all workspaces (including the original
workspace and the target one).
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1151
The monitor index is not something that gnome-shell and
gnome-settings-daemon seem to be agreeing about. Using the connector
string is a much more reliable method of identifying a specific screen
and we are indeed using this already for monitor labling.
So switch over to use the connector rather than the monitor index. If a
user tries to use the old API, then the OSD will simply show up on all
monitors (which is the status quo currently anyway).
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/489
This API has been broken for quite some time now as the corresponding
mutter function meta_monitor_manager_get_monitor_for_output was removed.
If anyone tries to use it, we would just run into a backtrace.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/490
Selecting a screen area for a screenshot isn't the same as selecting
items in an icon view, so there's no strong rationale for picking
up the style from GTK. We stopped doing that for other elements like
tile previews long ago, so just use our own style here too.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/481
Now that the existing touch/touchpad gestures in windowManager only
handle normal mode, add corresponding gestures for the overview and
hook them up to the existing workspace scroll animations.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/516
The window group is hidden while in overview, so the stick-to-content
animation isn't visible either. Worse, the gestures messes up the
position of window actors in that case. Just limit the gesture to
normal mode for now, we will soon add it back in the overview with
its own animation handling.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/516
The touch/touchpad gestures to switch workspace currently hard-code
the modes in which we want the gestures to work. While these modes
are correct, the existing switch animation only works in NORMAL mode,
not in the overview where the window group is hidden. The easiest way
to address this is to handle both cases completely separately, namely
use separate actions in- and outside the overview.
Make the existing usable in that way by making the list of allowed
modes a constructor parameter.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/516
Our weather integration is supposed to follow GNOME Weather's settings,
including its permission to use location services. However there's a
discrepancy in case xdg-desktop-portal is unavailable:
While our geoclue agent grants all applications access to location
services in that case, the weather integration treats it as if
access was denied.
Fix this by handling this case explicitly.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1130
The same code for reading the current magnifier state is repeated in both
shell-recorder, shell-screenshot and magnifier itself.
So to move this inside a property of st-settings so that we can refer to it
all over the places removing duplications.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/473
If the locale doesn't honor strftime()'s %c argument, we would end up
feeding NULLs into GdkPixbuf tagging. Fallback to a sensible (although
not nicely localized) datetime string.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/1017
There's no point in keeping the cursor sprite texture around all the time,
and to listen for its changes, we just need this when the magnifier is active.
So, initialize the magnifier texture and monitor for the sprite changes on
activation, while disconnect from the signal and nullify the texture when
the magnifier is deactivated.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/443
In order to paint all the color channels of the content texture we need to
set the color channels to 255, so instead of doing this manually we can just
reuse the static color definition for white.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1020
ClutterContent's get_preferred_size should return a boolean weather the
preferred size is valid, so in javascript we've to return this state value
before out width and height.
Since this was not happening, clutter was considering the width as the state
(converting the non-zero value to true), the height as the width, while ignoring
the returned height (that was then defaulted to 0)
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1020
Just like we take a remote "new-window" action into account for
opening new windows, we should call an explicit "quit" action
before falling back to closing all the app's windows on quit.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/624
The default ZoomRegion is created at startup and only updated if it is active
when the monitor setup changes. Thus when reactivating the magnifier after a
display change, the viewport used is still the one that been computed with the
old screen geometry values.
Move screen update code inside a function and call it both when activating
the zoom region and when the monitor changes during a zoom session.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1120
NetworkManager added support for a new device - NMDeviceWifiP2P - but
did not add the corresponding enum value in NMDeviceType. The return
value for nm_device_get_device_type() is therefore "illegal" for the
newly added device, and gjs throws an exception.
This should ultimately be fixed in libnm, but as errors when adding
one device shouldn't interfere with adding any other devices, catching
exception is a good idea anyway, so do just that.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1023
The current scripting module makes heavy use of pre-standardized
iterator/generator/promise APIs, at least for some of those support
was pulled in SpiderMonkey 58.
Port to the new standardized replacements to get the module back into
a working state.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/440
Commit 1b169655ac removed the system indicator from the list of children
that are considered for the overall menu width, because we do want the
log-out submenu to adapt to the available width.
However as a side effect, action buttons no longer contribute to the
width either, so if extensions add additional buttons, the menu is
likely to overflow.
Avoid this by only adding the button group to the list of size children.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1094
This call just went through stomping over previous drag operations if any,
_maybeStartDrag() accounted for this, but other callers (well, WindowClone
in workspace.js) don't. This must bail out early even if a drag operation is
requested, luckily all callers account for it already.
This broke shell state by preserving connected captured-event handlers if
one tried to drag multiple windows simultaneously through multitouch. We
of course don't support that, now more elegantly.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/455
The bind constraint that replaced the Shell.GenericContainer in commit
f4682748fa is subtly different from the previous code:
It forces the actor to have the same size as the stage, rather than just
requesting that size.
This breaks the magnifier which relies on the UI being able to be bigger
than the display size. Fix by going back to using a custom actor.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/646
The texture cache now returns an actor with an appropriate ClutterContent
rather than a ClutterTexture. That actor uses the CONTENT_SIZE request
mode, which means that it will unconditionally request the preferred size
of the content. That is, setting an explicit size no longer has an effect.
Fix this by making sure the image is already loaded with the desired
dimensions.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1024
After the latest texture cache changes, loading the icon at its preferred
size and scaling it via the actor size no longer works. Instead, use the
icon-size property which is applied when loading the icon.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/452
For window backed apps, create_icon_texture() doesn't return an StIcon
but a generic widget. Set an appropriate style class to make it easier
to apply a specific style only to fallback icons.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1027
With StImageContent, the meaning of passing -1 as size parameter changed
from "load the image at its preferred size" to "abort the session". It
is therefore no longer possible to just load the image and then have it
scaled by applying a CSS size to the texture's parent.
Setting the size from CSS is useful though, so to still allow that, fall
back to the actor's size (which can be determined by the style).
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1027
We need this to run `test-theme`, otherwise when run as part of the
build tests it fails like:
error while loading shared libraries: libmutter-cogl-4.so.0: cannot
open shared object file: No such file or directory
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/442
It is convenient for the OSK so it eg. doesn't appear centered in the
available space (eg. on very narrow portrait layouts), plus it will also
be convenient to align other AspectContainers to the same baseline.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/439
The executable is assumed to be run from $top_srcdir/src, which is
essentially an autotools left-over (it's where the program ended
up with srcdir == builddir).
Now with meson, its actual srcdir makes more senses.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/419
Clutter no longer hard-codes a resolution of 96 DPI (although that's
still the default), so any assertions of sizes for physical units
may be off.
Fix this by setting up the test environment according to the
assumptions.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/419
Since we started to support tray icons on wayland, the icon we show
is not the actual XEmbed window. Instead, we let mutter create a
MetaWindow for it, then use its window actor as source for a clone
we (or nowadays: extensions) can add, remove and destroy freely.
To not let the real icon get in the way, we set an empty input shape
and make its window actor fully transparent. This works OK on X11,
but on wayland all events still go through Clutter, so any reactive
surface actor inside the window actor will block events for any actors
underneath (and status icons go into the top-windows group, so almost
all actors are affected).
Luckily we can pile another hack onto the pile of status icon hacks ...
https://gitlab.gnome.org/GNOME/gnome-shell/issues/191
While it is possible to register accelerators in-bulk, there is no
proper way to unregister them again. This adds the corresponding call
for UngrabAccelerator to allow ungrabbing multiple accelerators at the
same time.
The idea is that g-s-d can use this in the future to simplify the
keybinding reload logic.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/429
Commit 8f15193b4 changed the `policy` property from a regular JS property to
a getter. This was necessary to avoid calling an overridden _createPolicy()
method before a subclass is properly initialized, but it broke the second
way of using notification sources:
Don't create a Source subclass, but use the base class directly and change
its `policy` property.
There's no good reason why we should no longer allow this, so add a setter.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/431
The dialog doesn't change the `destroyOnClose` property from its default,
so it is already destroyed automatically on close. So if we also destroy
it explicitly, we end up (rightfully) with one of gjs' infamous "invalid
access" warnings.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/430
If a result is displayed at the end of the search results, there should
obviously not be a line separating it from the next result underneath
it. To fix this, always hide the separator for the last result visible.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/311
While mapping the :first/:last-child pseudo classes directly to the
ClutterActor:first-child/:last-child properties allows for an easy
implementation, it is unexpected that rules can appear to not have
an effect because the selected child is hidden. GTK's behavior of
applying the classes to visible children makes much more sense, so
change our implementation to do the same.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/312
When we grab a screenshot of a framebuffer scaled shell, we shoudl apply the
device scale to the image surface, while the monitor scaling should be applied
to the cursor surface, so that it's painted at proper coordinates and in proper
size in the generated image.
This is not needed for XWayland clients as they are not scaled anyways, while
for wayland clients that are painted in multiple monitors, this might cause
a lower quality cursor in the lower dpi monitor, because the cursor sprite is
generated for the monitor scale, and not for the surface scale.
https://bugzilla.gnome.org/show_bug.cgi?id=765011https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/5
Under wayland, if the cursor should be included when doing a fullscreen
screenshot, we can rely on mutter "paint" signal to have it composited for free.
Otherwise if it's not requested, we can use the "actors-painted" signal to get a
stage texture before the mouse overlay has been added.
Instead, under X11 or when only a window screenshot is requested, we still
need to draw it manually.
https://bugzilla.gnome.org/show_bug.cgi?id=765011https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/5
Get from clutter the capture sizes and scale and don't mind
about doing any rounding here, as it might be different
from the one done at clutter level (causing mismatch and
not-working videos). Delegate this to clutter, and forget
about the internal details.
These values are then used to composte the image and set the video caps.
https://bugzilla.gnome.org/show_bug.cgi?id=7650111
It might happen that the target clutter actor that we return on call
of st_texture_cache_load_sliced_image might be destroyed while the
loading task is still running. To protect from this, let's connect
to "destroy" signal and when this happens we use a cancellable to
stop the task.
This allows to safely reuse the return value of this function to
cancel the execution and avoiding that load_callback is called
even for a request that is not anymore under our control.
https://bugzilla.gnome.org/show_bug.cgi?id=765011
When loading an actor for a sliced image actor, we can now use the
REQUEST_CONTENT_SIZE request-mode for the actor since we the content image
has now a predictable size and thus we can be sure that the size will be applied
taking care of the resource scale.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/5
Create StImageContent as a simple ClutterImage with preferred width/height
properties in order to be able to use explicit sizing when creating clutter
contents that will be applied to actors whose size depends on the content itself.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/5
Instead of just passing a scale when getting a cached icon, pass both a
'paint_scale', the scale of which the icon will be painted on the
stage, and a 'resource_scale', the scale of the resource used for
painting.
In effect, the texture size will use the scale 'paint_scale * resource_scale'
in a ceiled value while the size of the actor will use 'paint_scale' when
determining the size.
this would load a bigger texture, but the downscaling would keep the visual
quality.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/5https://bugzilla.gnome.org/show_bug.cgi?id=765011
Create the surfaces for background shadows at scaled sizes and then draw on them
using logical coordinates, by setting the surface device scale accordingly.
Use the said surface scale when generating the actual shadow cairo pattern
but in such case, to reduce the number of code changes, is better to work in
absolute coordinates, and to do so:
1) Create a temporary shadow-spec copy with scaled values to absolute sizes
2) Invert the scaling on the shadow matrix
3) Do the actual painting in absolute coordinates
4) Set the shadow matrix scaling back to the logical coordinates.
Finally scale down the created shadow pattern surface size when painting it,
applying again a reverse scale to the matrix.
https://bugzilla.gnome.org/show_bug.cgi?id=765011https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/5
Pass resource-scale to drawing phase, and use it to create texture
surfaces scaled with the widget current scaling.
Also redraw by default widgets when the resource scale changes.
https://bugzilla.gnome.org/show_bug.cgi?id=765011
A fractional resource scale would mean we never use the fast path for
creating the shadow, because we'd cast the int to a float before
comparing, which would never match.
Instead compare the expected texture size with the source texture, to
actually potentially trigger the fast path.
https://bugzilla.gnome.org/show_bug.cgi?id=765011
The fade shader will draw the fade effect up until the border pixel. If
we set the bottom right coordinate to the outer edge of the pixel we
might end up not drawing the fade effect on all of the pixels. This
could for example happen if one logical pixel (clutter stage pixel)
consists of more than one physical pixel.
https://bugzilla.gnome.org/show_bug.cgi?id=765011
This commit makes StWidget manage the scale of which its associated
resources should be multiplied with. The resource scale is calculated
by clutter, and is retrieved by clutter_actor_get_resource_scale(). Due
to the resource scale not always being available, the getter may fail,
and the actual widget that draws the content will have to deal with
this situation.
As the resource scale depends on where on the stage the widget is drawn,
the resource scale will in general be available once the widget is
mapped.
https://bugzilla.gnome.org/show_bug.cgi?id=765011
While we don't actually require a more recent version at build time,
we do need the latest stable version at runtime. There's no strong
reason for making that differentiation, so bump the requirement.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1006
instead of explicit screen arguments and `gdk_screen_get_number()`, as nowadays there
is always only one screen. This silences some deprecation warnings and removes
deprecated API.
Bonus: some code style cleanups
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/422
Running dnf to update and install additional packages every time
the job is executed slows down the CI pipeline. Avoid this by
using another custom images for JS source checks.
In addition to the js shell we use for the existing syntax check,
also include eslint for future jobs and some extension-specific
tooling to make the image more useful to extension authors.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/408
So far we are only performing a basic syntax check on javascript
sources; it's time to test the C code as well. As mutter is tightly
coupled, we bite the bullet and build it as well, either using a
matching branch (if it exists), or current master.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/408
Ouch, this went unnoticed for a long time: As the minimum size of menu
items is generally small (because its label can be ellipsized), we are
requesting the unellipsized width of the last "size child" instead of
the widest one.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/996
This adds a pipeline stage for merge requests that checks that the
commit message contains an URL to either a issue or a merge request.
This means that for merge requests without corresponding issues will
always fail initially, as the merge request URL is not known until after
it is created. This is still arguably better than accidentally merging
merge requests without URLs.
Taken from https://gitlab.gnome.org/GNOME/mutter/merge_requests/440.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/410
Here's a template string with '/' that escaped commit 94423151b2,
resulting in an xgettext warning when generating the .pot file.
Simply move it into the resource like the other interface descriptions
to make xgettext happy again.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/407
Since commit deec0bf255, the texture cache is based on ClutterImage
rather than ClutterTexture. As ClutterImage (like all ClutterContent)
is only concerned with painting, it doesn't influence the size of the
actor it is added to at all, and the returned actor will now stay at
size 0x0 after the image has been loaded.
Set up the actor to follow the content's size instead, to get closer
to the previous behavior.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/402
The top drag gesture is not of any use if the topmost window is not
a fullscreen window and will only block events near the important top
screen edge (i.e. the panel). To fix this, only enable this gesture if
the focus window is a fullscreen window.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/552
If the user's real name is too long to fit the menu comfortably, we are
supposed to use the username instead. However since commit f8e5e3e435,
we no longer set a max-width on the menu as a whole, but instead base
the width request on only "unellipsizable" children. For some reason
the system menu ended up there, so the name is now allowed to grow
indefinitely.
Remove it from the list of size children to get the intended behavior
back.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/400
The menu grabs the key focus when opened, which takes focus away from
whichever actor triggered the keyboard. And as the menu doesn't have
any text entries, the keyboard is popped down as a result.
Prevent this by making the menu items unfocusable, so the keyboard
focus just stays where it is. Considering that the menu is part
of the on-screen keyboard itself, not being keyboard-navigatable
isn't a big deal here.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/171
Menu items use a single 'active' state that follows both hover and
keyboard focus. It therefore makes sense for the active item to always
grab the focus, in particular as an item that is sensitive but not
focusable by keynav would be rather weird.
As it turns out, we do have a case that is weird enough where we want
exactly that, so only grab focus if the actor's :can-focus property
allows it.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/171
d="m 213.0007,724.40348 -10.3711,7.3945 v 0 a 1.5,1.5 0 0 0 -0.6308,1.2187 v 1.5 h 1.5 a 1.5,1.5 0 0 0 0.8711,-0.2793 l 8.6289,-6.1523 8.6289,6.1523 a 1.5,1.5 0 0 0 0.8711,0.2793 h 1.5 v -1.5 a 1.5,1.5 0 0 0 -0.6309,-1.2187 v 0 z"
d="m 213.0007,724.40348 -10.3711,7.3945 v 0 a 1.5,1.5 0 0 0 -0.6308,1.2187 v 1.5 h 1.5 a 1.5,1.5 0 0 0 0.8711,-0.2793 l 8.6289,-6.1523 8.6289,6.1523 a 1.5,1.5 0 0 0 0.8711,0.2793 h 1.5 v -1.5 a 1.5,1.5 0 0 0 -0.6309,-1.2187 v 0 z"
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
