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