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