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
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
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
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
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
