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
