Since IBus does not provide this information right away, we
so far cannot do much about providing a truthful anchor position
for the preedit text. But with the Mutter API in place it will
be up to this object to do so in the future.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2384>
This behavior dates back all the way to the original gnome-shell
release, and it did make sense at the time:
- we were first to make notifications persistent instead of
closing them after a timeout; apps were therefore used to
treat notifications as fire-and-forget instead of closing
them when no longer relevant
- neither web notifications not portals did exist yet, so the
D-Bus API was only used directly, instead of as a backend
for other APIs; as a result, focusing the app was more likely
than not to put the source of the event that the user was
notified about into view
Nowadays both persistent notifications and web notifications
are wide-spread, so the original reasons no longer apply.
This change helps web notifications in particular, as it reduces
the differences between XDG and portal-based implementations.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2332>
GNOME Shell will only update extensions if the org.gnome.Extensions
app is present. This commit adds alternative support for
com.mattjakeman.ExtensionManager to the extension updating mechanism.
It enables updates to occur when extension-manager is the sole installed
tool on the system. When both applications are installed,
org.gnome.Extensions is preferred at all times.
Fixes#5564
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2358>
The logging function cannot be asynchronous, so move the override
into main.js where ExtensionUtils can be imported at the top level.
Importing ExtensionUtils in environment.js at the top level is not
possible because it would import Main prematurely.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2363>
ES modules do not allow exports to be overriden, in anticipation
of the ESM port add a `setCurrentExtension` utility which will
throw if used in the shell. This is tested using a conditional
import of Main.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2363>
We considered any ConnectFlag value major than SWAPPED as invalid, while
it's technically not fully true as we need to ensure that the passed
value is respecting the whole flags mask.
In fact, per se SWAPPED|AFTER (> SWAPPED) is a valid value (even if we
don't support the AFTER value).
But this makes the check more future-proof.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2366>
While untracking an object we used to compute it's proto for each signal
we were disconnecting from, while this is not needed when we're just
iterating over all the same owner signals, so let's add few more
functions to compute an object prototype, and repeat the disconnections
in the simplest way we can.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2366>
We used to create a temporary array of signal tracker keys and then to
iterate through them in order to untrack the objects, but the Map's can
be iterated directly so let's just use their native forEach.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2366>
Introduce a new class, EventEmitter, which implements signal
handling for pure JavaScript classes. EventEmitter still
utilizes GJS' addSignalMethods internally.
EventEmitter allows static typechecking to understand the
structure of event-emitting JS classes and makes creating
child classes simpler.
The name 'EventEmitter' mirrors a common name for this pattern
in Node and in JS libraries.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2043>
If we only raise screenshot UI to top, ibusCandidatePopup can still
cover screenshot UI because each time ibusCandidatePopup updates it's
visibility it will raise it to top and this also happens if we open
screenshot UI via keybinding. This commit fixes it by only raising it
above keyboardBox, because keyboardBox is above all entries in modal
dialogs.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2331>
ibusCandidatePopup actually works as a top chrome because it always
raises itself above top_window_group when updating visibility, so just
initing it as a top chrome instead of initing it below top_window_group.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2331>
The overviewGroup's size is currently determined by the coverPane
actor. That actor is only shown during transitions, so we rely on
ClutterFixedLayout including hidden children in its size request.
That odd behavior is about to change, so we need to make sure the
overview still requests the correct size.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2351>
When a window with a modal dialog gets minimized and at the same time
the dialog is closed, the WindowDimmer undim animation starts and gets
cancelled when the minimize animation is done, because that unmaps the
window actor.
In this case we want ensure the dimming effect still goes into a
proper state instead of being stuck mid-animation, so listen to
onStopped instead of onComplete for syncing state of the window dimmer.
While at it, clean things up a little and move the check for the
attach-modal-dialogs pref inside the _syncEnabled() function.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5581
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2349>
Right now, we don't pay much attention to visibility hints from IBus
about the candidates list for the OSK suggestions bar. Since some
IMs rely on this visibility being honored, do that.
To fix this, the visibility hints for the lookup table are now
propagated to the keyboard, so the Suggestions actor hides its
internal candidate buttons. Since the Suggestions actor gets its
minimum height from CSS, this does not result in OSK size jumps.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5601
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2347>
There is no hint about the currently selected language, but this exists
in the mockups. Add a dot ornament on the language that is currently
selected at the time of showing the OSK languages popup.
Since this popup is created from scratch every time it is shown, and
the popup is torn down with the OSK during replacement. This also
works for further times the languages popup is shown.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5598
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2346>
When calculating the on screen coordinates of events from the window
relative coordinates, using the frame rect will include the decorations
added by the WM for SSD windows. This was causing the calculated
coordinates to be slightly off. Fix this by using the client rect for
SSD windows.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2319>
Absolute screen coordinates are impossible for Wayland clients to
provide, because the clients don't know where the window is positioned.
Some clients, such as the ones using GTK 3 were providing window
relative coordinates even when screen coordinates were requested,
while others, such as GTK 4 clients, were just returning an error for
caret events or also window-relative coordinates for focus events.
So for this to work on Wayland we have to request window-relative
coordinates and translate them to the current focus window.
To ensure the correct coordinates, we have to only consider events
coming from the current focus window. All other events are filtered out
now. As a side effect this also fixes the magnifier always jumping
to a terminal cursor whenever there was some output, even if the window
was not focused.
This also needs some special handling for events coming from the shell
itself, which should not be translated to the focus window either. As
another side effect this fixes another bug that was caused by these
events already including scaling and getting scaled again.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5509
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2301>
If we don't set the height property to -1 before requesting the
preferred height, get_preferred_height() will just return us the fixed
height that has been set before. We don't want this behavior here, so
set the height to -1 before calling get_preferred_height().
This fixes a resizing issue where the keyboard is sized incorrectly
after switching the monitor into portrait mode and back.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2306>
Both bluetooth and screencast support are based on build checks
right now. However in both cases, the dependency is only consumed
at runtime via the typelib, so let's actually check for that.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2297>
We currently decide at build time whether to include screencast
support, based on whether the required gst/pipewire library headers
are installed.
That check is imprecise, because having the library headers available
at build time doesn't necessarily mean that the libraries are there
at runtime, or that the corresponding typelibs are installed.
It makes more sense to check the requirements at runtime, so prepare
for that by installing the screencast service unconditionally, but
bail out early if the dependencies aren't met.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2297>
The problem is that " 9:59 AM" (notice the space at the beginning) and
"12:59 AM" strings, when centred, look misaligned —
strings padded with a space look off to the right by nearly
half a character. This happens because the font feature "tnum",
used to make numbers monospace, doesn't work on spaces.
The commit overcomes this by aligning time labels to the end.
However, this won't work for locales with AM/PM strings of different
lengths, so they are aligned to the start instead to minimise offset.
It's too complex to know whether the used locale has different
AM/PM string lengths. Instead, every time the time changes, it
determines whether all the time labels have the same amount of characters.
Fixes#5438
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2294>
We update the visibility on state or stream changes, but those
changes may never happen if pipewire-pulse/pulseaudio isn't
available (for example when running as root).
Hiding the sliders is preferable in that case to showing non-working
controls.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2295>
When selecting the largest possible icon size for restricted vertical or
horizontal space the options for low resolution icons were rather coarse
grained. This could often result in seemingly too small icons being
chosen in the app grid on systems with low vertical resolution, because
the next larger size would exceed the limit by a few pixels.
This adds two more commonly used sizes for application icons to have
some more options with restricted space.
Helps: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2173
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2289>
Commit 7419674b changed some grabs from requiring both mouse and
keyboard grabs to be considered successful to only requiring either of
them.
Due to this it was possible for example to open the overview or the
screenshot UI with a client (such as Chrome when opening a menu) holding
the mouse grab. This then made it impossible to interact with the UI
using the mouse (or keyboard) and if attempted could result in an
unresponsive UI.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5414
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2287>
Commit ca4f6e0123 was supposed to show the
"cellular-disabled" icon when wwan is disabled. For wwan, just like for
bluetooth wwan networks, we probably want this to include the "not
connected" state, because disconnecting from cellular service de-facto
means disabling it.
So switch the check to show the "cellular-disabled" icon to also use the
icon whether there's no active connection, not only when the wwan device
is turned off.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5401
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2283>
The swipeTracker wants the distance between two pages passed to it in
confirmSwipe(). In case of the app grid, the correct distance is not the
size of the scrollView (which has the width of the whole screen), but
instead the allocation size of the iconGrid (which is the actual size
of a page in the grid).
So pass the allocation size of the iconGrid to the swipeTracker, this
makes sure the pages move perfectly in sync with the pointer when
dragging using the mouse or touchscreen.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2275>
With commit c29e0cf6e6 the grabHelper
already started using a similar mechanism to funnel events to the osk
while a ClutterGrab is in effect. ModalDialog, the unlockDialog and
lookingGlass don't make use of the grabHelper though, they use
Main.pushModal() themselves, so those need to funnel the events to the
OSK themselves.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2263>
We currently complete the animation using an onComplete handler,
which only runs if the corresponding transition was stopped when
finished.
While it is unexpected that the transition is interrupted, it can
apparently happen under some circumstances (like VMs with qlx).
The consequences of that are pretty bad, mainly due to the cover
pane that prevents input during the animation not getting removed.
Address this by always completing the animation when the transition
is stopped, regardless of whether it completed or not.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5337
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2269>
If one of these libraries breaks its GIR API in future, then upgrading
packages unrelated to gnome-shell might pull in the newer version,
causing gnome-shell to crash when it gets a newer GIR API that is
incompatible with its expectations. For example, this seems to be
happening in Debian testing at the moment, when GNOME Shell 41.4
imports GWeather and can get version 4.0 instead of the version 3.0 that
it expected.
Adding explicit API versions at the time the newer version is released
is too late, because that will still let the newer version of the GIR API
break pre-existing GNOME Shell packages. Prevent similar crashes in
future by making the desired versions explicit.
This is done for all third-party libraries except GLib, similar to the
common practice in Python code; if GLib breaks API, then that will be
a disruptive change to the whole GLib/GObject ecosystem, regardless.
Gvc, Meta, Shell, Shew, St are not included because they're private
(only exist in a non-default search path entry).
Clutter and Cogl *are* included, because we need to import the fork of
them that comes with Meta, as opposed to their deprecated standalone
versions.
Signed-off-by: Simon McVittie <smcv@debian.org>
Bug-Debian: https://bugs.debian.org/1008926
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2261>
MetaWindow.move_to_monitor() can no longer be assumed to have updated
the monitor on return, as under wayland, if the move involves a size
change, the monitor state will only be updated after the new size has
been synced with the client.
If that happens, trying to change the workspace of the moved window
fails, as it is still considered on-all-workspaces until it leaves
the secondary monitor.
It's possible to work around this by waiting for the window to actually
enter the requested monitor. That's finicky enough to warrant a helper
funtion, so add one.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/893
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2259>
If the timezone offset calculation in the World Clocks contains non-zero
minutes, then a decimal Hours value is being displayed. Limit the Hours value
to integers by using Math.floor().
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2255>
On some hardware combinations the display can be known, then unknown again. Meaining that
when the update monitors function is called it will have a value, then be called again
setting this.primaryMonitor to null. If the timing is just right gnome shell will
loadBackground, then by the time the animation is ready the monitor will be gone,
thus methods will be called on a null value. This adds more checks for a valid
primary monitor, and wont play the animation until the system is idle AND has a valid
priamry monitor.
Fixes: #5003
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2144>
T_() is a convenience shortcut for looking up a string from the
locale defined by LC_TIME, but it isn't recognized as a gettext
keyword. To do that, we also have to wrap the string in N_() or
NC_().
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2246>
It existed to fade out/in `nautilus-desktop` for the overview, but it only
ever worked for X11 sessions (`Meta.WindowType.DESKTOP`) and
`nautilus-desktop` no longer exists anyway.
While I had suggested extending it in the past (!1395), that work was
never finished and since then the DING extension has implemented its
own visibility toggling. There seems little value in keeping the old
fade logic around in gnome-shell. Removing it actually fixes a bug with
DING (https://launchpad.net/bugs/1965072).
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2244>
Creating these default folders still doesn't work. After some
investigation I found that's because the template we use for
the path when creating the `child` `Gio.Settings` instance
results in a double slash - it comes out as e.g.
/org/gnome/desktop/app-folders//folders/Utilities/ . dconf does
not gracefully handle this as many other things that handle
paths do, it considers it a programmer error. It results in
error messages like:
dconf_changeset_set: assertion 'dconf_is_path (path, NULL)' failed
which is slightly confusing. Anyway, we fix it by removing a
slash from the template.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2242>
Since the ClutterGrab rework, grabbing properly emits crossing events.
StButtons take a ClutterGrab as soon as they are pressed, so pressing
the close StButton of the WindowPreview takes a grab and causes a
LEAVE+key-focus-out event getting sent to the WindowPreview. This in
turn makes us hide our overlay (which the StButton is part of). We
automatically ungrab ClutterGrabs when hiding actors, so the StButtons
grab now gets released again, key-focus and hover state are updated
again and we emit an ENTER event to the WindowPreview. The preview now
tries show its overlay again and things explode because we re-enter the
mapping machinery.
For the LEAVE event we can break this cycle by detecting the GRAB_NOTIFY
crossing event of our own StButton and not reacting to that.
We should do the same for the key-focus-out event, but these don't pass
context information like a GRAB_NOTIFY flag yet, so just check the
current grab actor here.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3165
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2231>
Commit ba23279f1f was aimed at fixing a
bug where the layout is frozen so early that we don't have an existing
one to re-use, because no allocation cycle happened yet. It tried to fix
that by forcing the creation of a layout when needsLayout === true,
this turned out to be a bit too much, as it also forced creating a new
layout when the layout was frozen after closing a window (which would
set needsLayout to true).
To fix this regression and still avoid reintroducing the bug the
previous commit fixed, tighten the check a bit and only force creating
the new layout when there's no allocation yet. This makes freezing the
layout after closing a window work again.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2236>
The magnifier uses a PointerWatcher (which is based on a simple timeout
source) to update the zoom region based on the current mouse cursor
position 60 times a second. When updating the zoom region, it would also
hide mutters cursor using meta_cursor_tracker_set_pointer_visible().
Since a few months, mutter has decoupled the handling of input events
from the monitor refresh rate though, which means it's no longer
guaranteed that the cursor changes only 60 times a second (on higher
refresh rate monitors it actually never was). This means mutter might
show the cursor more often than 60 times a second, while we hide it only
60 times a second, leading to a flickering second cursor.
To fix this, implement the cursor-hiding by listening to
MetaCursorTrackers visibility-changed signal, and immediately hiding the
cursor again when it's shown.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2234>
We want to use the current event time for activating the workspace, and
this time is only available when calling global.get_current_time() or
Clutter.get_current_event_time() from the context of an event handler.
So instead of trying to get that time when the animation has finished
from the onComplete() handler, get it before and store it as a variable
to use in the onComplete() handler later.
This fixes an error message when switching workspaces using the swipe
gesture where MetaWorkspace complains about the 0-timestamp we pass it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2233>
In testing on Fedora, gnome-shell crashes here:
JS ERROR: TypeError: DEFAULT_FOLDERS[folder] is undefined
This needs to be a "for of" loop, not a "for in" loop, because
`folders` is an array of the hash's keys, not the hash itself.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2238>
In a very un-StButton fashion, OSK keys are not interested in
altering the current focus state, as otherwise pressing those
will trigger a grab that will alter key focus, so the generated
key or IM state events will not be handled by the actor that
originally had the focus as long as the OSK key is pressed.
Despite being StButtons, OSK keys do already perform their own
press/release handling with internal state tracking, so it is
not a big stretch to simply consume the events, and update the
:active pseudo-class manually.
This makes OSK keys still look and behave as usual, but without
any grabbing shenanigans that might affect the focus state. This
makes all OSK keys work again.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4986
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2237>
In the case of bringing up the OSK while there is a grab (like, every
GNOME Shell entry), we used to special case event capturing so events
directed to the OSK would be let through.
When Clutter.Grab came around, events would be propagated only within
the actor hierarchy that holds the grab, which rendered this special
case just as useless as the OSK while a grab was hold. Since it wouldn't
be part of the grab hierarchy, clicking on the OSK would do nothing.
In order to let the OSK handle events, double down on the special case
and let it forward the event directly to the actor under the device,
instead of trying to let it through somehow. Since the actor under the
device are usually OSK buttons in this case, we don't need further
propagation to make it work, which makes the OSK functional again while
the shell holds a grab.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2237>
The screencast portal supports recording a single window,
and presents a list of open windows when that option is
selected. To allow updating that list when windows are
opened or closed, add a new "WindowsChanged" signal that
the portal can listen to.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2229>
