When using the fade animation when transitioning to the overview instead
of zoom, we fade out all window previews to fully transparent. But after
commit 751189253a removed the old _updateWindowPositions() function,
nothing resets the opacity again, so when switching from the app- to the
window picker, all previews are hidden.
Fix this by always resetting the window preview opacity after showing
or hiding the overview.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2969
We don't animate size and position when fading, so we want all previews
to already be at their final position. However when the app picker is
opened from within the overview, window previews use the zoomed layout,
so that's the state we are then fading when leaving the overview from
the app picker.
Fix that by setting the correct state at the start of the fade transition.
(In the case of fadeToOverview(), the value should always be correct
already, but set it anyway for symmetry with fadeFromOverview())
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2969
In commit 9297d87775 we stopped syncing the primary view's actual
geometry at the start of the transition when doing a fade animation,
however the view animation may still be triggered by an allocation
change.
Prevent those unwanted size changes during fade by keeping track of
the fade state and explicitly skip syncing the geometry while a fade
is ongoing.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2969
Since commit af543daf1c, we skip the overview transition when the
actual geometry hasn't been set yet. However with the new layout
manager, the only bit that still needs the separate geometry is
the transition of the view, the workspaces can do their transition
just fine.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2969
When dragging the workspaces through the swipe gesture, all
workspaces must be visible. WorkspacesView's _updateVisibility()
method special-cases this and ensures that.
However, this method is only called when (1) going to the active
workspace, and (2) when the gesture ends. That means, if there
is any workspace hidden by the time a gesture starts, it is never
shown!
Call _updateVisibility() on startTouchGesture() as well.
Related: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2969https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1360
Because for most frames during a workspace switch it's not changing and
we can repaint it faster if it's cached on the GPU as a single texture.
This seems to reduce the render time for workspace switching by more
than 20%.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1356
When going straight to the app picker, we fade in the overview instead
of doing the full-blown zoom transition. In order to keep windows at
their floating position, we must apply the same to the view itself
and not transition to the overview geometry when fading.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1353
We don't always want to sync the geometry when entering the overview,
namely when the fade transition is used.
However we do want the correct geometry once we have entered the overview,
so that workspaces are at their place when switching from the app picker.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1353
Non-primary views always use their monitor's work area for their
geometry, so there's nothing to animate when leaving the overview.
The animation is already limited to the primary view when entering
the overview, so this is also more consistent.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1353
It doesn't matter which animation we use to enter the overview,
we always want to start and end with the floating layout.
The simplest way to achieve that is by creating the state adjustment
with the correct value in the first place.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1353
The transition was temporarily removed when switching to the new
workspace layout manager. Now everything is in place to reimplement
it with a combination of the layout manager's state adjustment and
the view's allocation.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1345
So far we've been allocating workspaces in a stack, and relied on
translation to move them to the right position. And as the position
depends on both the workspace's index and the view's viewport, some
care is needed to prevent gestures/scrolling from interfering with
layout updates.
Clean that up by properly allocating workspaces in a row or column,
and use a translation to reflect the current scroll position.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1345
Since the workspaces themselves stopped using it, there is little
reason for upholding the difference between "full" and "actual"
geometry.
Just base positioning/swiping on the view's allocation.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1345
The workspace's layout manager keeps the workspace at the same ratio as
the work area, so it makes more sense to base the views' default geometry
on that as well than the monitor area we are using right now.
(It shouldn't matter much in practice, as this only affects views on
non-primary monitors where the work area usually matches the monitor area)
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1345
We adjust the size and position of the primary view to match the workspaces
display, but views on other monitors are always set to fill their monitor.
Take that into account and create views with a fixed size and position, then
only sync the primary view to the new geometry.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1345
WindowPreviews now contain and manage overlaid elements like close
button or title label themselves. That's generally better, but right now
the only way to disable those overlays (for example during transitions)
is to prevent any hover or focus events from getting to the preview.
Instead, add some explicit API for enabling or disabling overlay support.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1345
For the windowPreview we need to ensure the style information of the
border and title is up-to-date when chromeWidths() or chromeHeights() is
called. Since the introduction of the WorkspaceLayout those functions
may be called during an allocation cycle, which means we should avoid
calling queuing relayouts inside them. Calling StWidgets ensure_style()
method will queue a relayout though in case the newly generated theme
node has a different geometry.
So avoid queueing a relayout during allocation cycles (and the warning
Clutter logs because of that) by ensuring the style of the border and
title earlier, as soon as the WindowPreview is attached to a stage.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1305
Switch to the new WorkspaceLayout layout manager to allocate the window
clones of the overview properly using Clutters layouting mechanisms.
Since we now no longer make use of the fullGeometry, we can remove the
setFullGeometry() function from the Workspace class. Also we can stop
setting the actualGeometry on the Workspaces and WorkspaceViews and
instead just set the fixed position and size of the views to their
full or actual geometry. This also has the benefit that we no longer
have to set a custom clip, but can simply enable clip_to_allocation.
The geometry needs to be set inside a BEFORE_REDRAW later because
_updateWorkspacesActualGeometry() is called from a notify::allocation
handler.
This isn't doing any animations when showing/hiding the overview yet,
we'll add that in the next commit.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1305
Add a new ClutterLayoutManager for layouting the workspaces of the
overview, WorkspaceLayout.
This layout manager integrates the existing LayoutStrategies used to
layout the window clones of the overview and supports freezing the
layout, animating between layout changes and adjusting the spacing for
the width and height of the window chrome. It also adds support for a
layout of the windows that looks the same as the actual workspace,
transitioning between that layout and the LayoutStrategy can be done by
setting the value of an StAdjustment, available using the
stateAdjustment getter function.
This will replace the current static-positioning based layouting of the
window clones in the next commit.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1305
We're going to use fixed position for positioning workspaces when
they're allocated by their own layout manager, using those positions to
scroll between different workspaces interferes with that, so do that
using translations instead.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1305
In portrait orientation, we set the height to the preferred height
for the monitor width (or, if smaller, a third o the screen height).
However as the forWidth currently doesn't make a difference, the height
is effectively controlled by the natural height of the keys - which is
rather small.
Address this by making AspectContainer request an appropriate preferred
size based on the fixed ratio.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2349
The previous commit implemented a new CredentialManager interface to
facilitate adding additional providers for pre-authenticating the user
at the login screen.
This commit implements a new credential manager using that interface
for vmware deployments.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/1983
Commit 4cda61a1 added support for pre-authenticated logins in
oVirt environments. This feature prevents a user from having
to type their password twice (once to the oVirt management machine,
and then immediately again in the provisioned guest running gnome-shell).
That feature is currently oVirt specific, but a similar feature would
be useful in non-oVirt based virt farm environments.
Toward that end, this commit generalizes the various aspects of the
oVirt integration code, so that it can be reused in a subsequent
commit for adding single sign on support in vmware deployments, too.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/1983
ClutterActor provides the same function, but with a different return
value. So since we already switched to the ClutterActor implementation
in our C code, we can now safely remove st_widget_get_resource_scale()
and update the JS code that's still using the old API.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1287
The blur effect needs to take the scale-factor into account, so we
listen for scale changes. However we set up the signal handler when
creating a background, which is repeated for each monitor, and every
time the monitor configuration changes. But we only disconnect the
last handler that was connected, and only when we are destroyed,
not when recreating backgrounds.
Fix this by splitting out updating the effect parameters to a separate
method that iterates over all backgrounds, so we can simply set up the
handler from the constructor.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1341
The arrow of the removed app was still left in the list with the
visibility of the arrow still depending on the original list order. This
could either lead to apps with just one window now suddenly having a
down arrow or apps with multiple windows not having one. If the last
window in the list had a down arrow, it would have been displayed
outside the window switcher.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2935https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1340
As usually with GObject setters, we should check whether the property
actually changed before setting the value and notifying the property. So
check whether the title or description text actually changed before
setting it.
This fixes a bug which makes the title flicker and change its size,
because when updating the title we remove the "leightweight" css class
and reapply it inside a later, which makes the title appear larger for
one frame.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2574https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1336
Noticed while working on customizable folders. Calling GrabHelper.ungrab()
ends up calling FolderDialog.popdown(), but at this point the '_isOpen'
field isn't updated yet, so we end up calling popdown() twice.
Update the '_isOpen' field before ungrabbing.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1332
Overview has signals to notify about starting, cancelling, and
finishing icon drags, but none of these signals pass the dragged
item to the callbacks.
Pass the dragged items to the 'item-drag-*' overview signals.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1332
Commit c7e597cf72 tried to improve the slide animations when entering
the overview by using the same time as the overall overview animation,
but in fact broke the animation most of the times.
That is because the Overview imports OverviewControls before defining
the ANIMATION_TIME variable, so any javascript code that is evaluated
during that import will see the value as "undefined" (which is converted
to 0 for the animation).
Fix this by moving the ANIMATION_TIME variable before the imports instead
of the usual placement.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1331
When you tap Super and see the sidebars and windows slide, it looks more
cohesive if those animations complete at the same time.
Previously there were 0.09 seconds difference between the two animations
which was enough to make it look slightly buggy. Now it doesn't.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1289
We now found the underlying bug: The ControlsManager (which causes the
bad call to `_updateWorkspacesFullGeometry()`) is getting (re-)allocated
while we add the view to the overviewGroup actor because the
overviewGroup is already visible and the view is immediately getting
mapped by `clutter_actor_add_child_internal()`. That causes a
resource-scale calculation and that indirectly causes a call to
`_clutter_stage_maybe_relayout()` (explained more detailed in the last
commit).
So now that we got rid of the immediate relayout happening when mapping
the view, we can revert this fix.
This reverts commit 6cc19ee6f0.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1315
When the bounding box size is 0 during allocation (which happens right
after creating a window for example), we're doing a division by zero and
end up with a NaN scale. This ends up making the childBox NaN, which
triggers an error in Clutters allocation machinery.
So fix that and fall back to a scale of 1 in case the bounding box is
empty.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1320
The current microphone indicator only indicates if the microphone is in
use. Users might be also interested if their microphone is recording
or is muted, this commit enables that without opening the pop-up
menu. The microphone icon changes itself, depending on the sensitivity
of the microphone. It behaves similar to the already existing volume
indicator.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2902
In the past, the icon grid would update the number of pages
during the call to adaptToSize(). However, after the new grid
layout landed, the number of pages is updated by the time an
item is added or removed.
Instead of comparing the old and new number of pages in the
icon grid, compare the pages shown by the indicator, and the
grid pages.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1271
Now that we don't have the Frequent tab anymore, and subsequently
the buttons to switch tabs, the app grid fill all the way to the
bottom, leaving no room for drag overshoot.
Add a 20px (i.e. OVERSHOOT_THRESHOLD) area at the bottom of the
grid where dragging actually scrolls to the next page.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1271
The two BaseAppView subclasses now share a lot in terms of
widgetry: they both have a scroll view, pagination dots, swipe
management, etc.
Move this shared code into BaseAppView. Notice, however, that
BaseAppView only creates the widgetry, but it doesn't add them
to any specific layout. FolderView arranges the widgetry in a
vertical box, while AppDisplay arranges it in a ShellStack.
Add a new 'orientation' parameter to BaseAppView and use it
to determine the orientation of the pagination dots, the swipe
tracker direction, and the scroll event handling.
It is worth noticing that the scroll event is a bit more
sophisticated now: when the orientation is horizontal, it
handles all directions since mice wheels usually only generate
up/down events.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1271
When FolderIcon is destroyed, it destroyed the FolderView and, if
there's a folder dialog present, it destroys the dialog as well.
Turns out, the folder dialog adds the icon's FolderView to itself.
The view becomes part of the dialog's actor tree. When the dialog
is destroyed, it also tries to destroy the view - but the folder
view was already destroyed by FolderIcon!
Fix that by letting the dialog destroy the folder view if it exists,
otherwise destroy the folder view directly.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1271
Add app icons to the exact page and position they're located
instead of always appending. This will be useful later when
custom icon positions are in place.
For now, it assumes pages are always filled, which is true,
but this will also change with custom icon positions.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1271
AppDisplay currently adds all icons, and hides the ones inside
a folder. Change that to only add the icons that are not inside
folders. Adding an icon to a folder removes the icon from the
main grid.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1271
When filtering out the app icons, AppDisplay calls FolderIcon.getAppIds(),
which then calls FolderView.getAllItems(). This last function reads the
already added app icons inside the given folder, and return their app ids.
So far, so good.
When the GSettings backing a folder changes, FolderIcon emits 'apps-changed'
to notify AppDisplay that the folder changed.
Cool.
When AppDisplay receives this signal, it first recreates its own icons, then
updates the folders, and finally hides the icons that are inside folders.
This series of events is unfortunate. Future patches will need the folder
to be updated *before* AppDisplay updates its own icons.
Update folder icons before chaining up to BaseAppView._redisplay().
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1271
The icon grid is always paginated, so the app grid code doesn't need
to behave differently in the FolderView and AppDisplay.
Move the keyboard handling to IconGrid itself, and remove the now dead
code from AppDisplay.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1271
The new icon grid layout operates based on rows and columns, and
doesn't try to dynamically adapt it to fit to the container. In
this case, it is better to have a pre-defined set of well-known,
well-tested rows and columns, and switch between them based on
the aspect ratio of the screen.
Introduce a set of modes to the icon grid, and select the mode
that is closest to the aspect ratio.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1271
IconGridLayout is a new layout manager that aims to replace the
current paginated layout algorithm implemented by the icon grid.
There are a few outstanding aspects of this new layout manager
that are worth highlighting. IconGridLayout implements all the
mechanisms necessary for a paginated icon grid, but doesn't
implement any policies around it. The reason behind this decision
is that this layout manager will be used by other places (e.g.
the login dialog) that demand different policies to how the
grid should look like.
Another important aspect of this grid is that it does not queue
any relayouts when changing its properties. If a relayout is
required, the actor should manually queue it. This is necessary
to avoid layout loops.
Add the IconGridLayout class. Next commits will do the surgery
to IconGrid and any related code to use this new layout manager.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1271
For drag actors which get reparented to the uiGroup, we currently wait
until the next input event to set the fixed position of the actor, until
that they will just be allocated their old fixed position, which is 0,
0.
So avoid drag actors flickering at the top left for one frame and
position them correctly right after reparenting.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1310
Properly adjust for drag actors which were allocated using a custom
vfunc_allocate() and might not have gotten allocated their preferred
size. When DND reparents the actor to the uiGroup, the drag actor will
get allocated its preferred size, so we also need to take the difference
between the old allocation size and the preferred size into account
before reparenting to the uiGroup.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1310
Properly handle drag actors which are not allocated using a fixed
position and disable the fixed position we were using to move the actor
around before we reparent it again to its original parent.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1310
The workspace.js file is quite large and is a bit confusing when it
comes to the term "window" in there, because it can either refer to a
WindowPreview of a complete window or to an individual window like an
attached dialog.
So try to avoid that confusion and split the new WindowPreview class and
its WindowPreviewLayout layout manager out into a new windowPreview.js
file.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1307
MetaWindow is Mutters representation of a window and provides all the
APIs about it, MetaWindowActor is just the ClutterActor that's drawing
that window. So use a MetaWindow to create a WindowPreview instead of
the window actor.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1307
We want to stop using the MetaWindowActor for things which are actually
related to the MetaWindow, one more thing where we can change that is
the overviewHint, which is currently added to the MetaWindowActor.
So move that hint to the MetaWindow and stop calling
get_compositor_private() in a few more places.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1307
We can simply get the MetaWindowActor by calling
MetaWindow.get_compositor_private(), so stop accessing the realWindow
property of WindowPreview. For this we also have to make _isMyWindow()
and _isOverviewWindow() take a MetaWindow as an argument instead of a
MetaWindowActor.
Since the WorkspacesThumbnails are also drop targets for WindowPreviews
and their WindowClones also have the public metaWindow property, switch
to using the metaWindow property there, too.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1307
Since the WindowPreview class rarely needs to handle the actual actor
painting the window preview, refactor the WindowPreviewLayout a bit to
only pass a MetaWindow to its addWindow() and removeWindow() functions.
Also make the getWindows() function return an array of MetaWindows,
which makes the getMetaWindow() function obsolete, so remove that.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1307
We're going to remove ClutterClones, so call the parameters to
addWindow() and removeWindow() "actor" instead of "clone". Also make the
destroyIds less confusing and rename the actual actor destroy id to
"destroyId", and rename the window actors destroy id to
"windowActorDestroyId".
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1307
Since ClutterClones are going to be removed, let's switch the
terminology here to something that's more understandable and rename the
WindowClone class and its layout manager to
WindowPreview/WindowPreviewLayout.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1307
Now that we properly notify mutter about when a size-change animation
has ended, it should never happen that a new size-change animation is
started without the last one being cancelled (ie. 'kill-window-effects'
being emitted).
This means there should also never be an old animationInfo attached to a
window actor, so warn in case we still find one when starting the
animation.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1251
We're currently using the hack of telling mutter that our effect is
completed (even though it isn't) in order to unfreeze updates of the
window actor.
This causes a bug with detecting the wl_outputs a window is
visible on, because the MetaWindowActor emits its "effects-completed"
signal too early, making Mutter update the wl_outputs while we're doing
the animation.
Now since meta_wayland_actor_surface_is_on_logical_monitor() uses the
transformed position and size of the MetaSurfaceActor and is being
called right after we setup the animation (but before it actually
starts, that happens at the next paint cycle) it will use a "very wrong"
rectangle: The transformation has been set to move the actor back to its
old position, and while we did already unfreeze updates and called
clutter_actor_set_position() in meta_window_actor_sync_actor_geometry(),
the actual allocation is not updated yet; this makes
clutter_actor_get_transformed_position() return a position including in
the new transformation, but not including the new allocation, and the
rectangle ends up being moved to the next monitor or completely out of
the stage.
To fix this issue properly, we need to decouple unfreezing actor updates
from emitting the "effects-completed" signal, which is now possible with
the new meta_window_actor_freeze() and meta_window_actor_thaw() APIs. So
use those new methods to freeze and thaw actor updates ourselves and
make sure to call shellwm.completed_size_change() only after the
animation has finished.
Mutter MR: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1250
Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/513https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1251
It might be that we receive a "kill-window-effects" signal between the
emission of the "size-change" and the "size-changed" signal.
In this case we already have the animationInfo attached to the window
actor, so we should also remove it.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1251
Using CSS to center the title actor on the border is a bit ugly, because
it requires the CSS to match the calculations used in chromeHeights().
Also it is not possible to use CSS margins for cases where the position
of the actor is determined at run time, such as for the close button.
Instead use an invisible actor that spans between the horizontal and
vertical center lines of the border as guide when aligning the title
actor.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1313
Commit 1ea22a5281 broke the window reposition animation when it
based the ::size-changed signal on the layout manager's bounding box
instead of the MetaWindow::size-changed signal.
That's happening because of the combination of:
1. we adjust to window size changes immediately without animations
2. closing a window triggers a change to a 0x0 bounding box which
is not treated as a size change
Fix this by addressing the 2nd factor, and don't treat a change to
a 0x0 bounding box as size change.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2901
Animating the window clones of the overview requires the fullGeometry
and the actualGeometry to be set, which they won't be when showing the
overview for the first time. So don't even try to animate the window
clones in that case because the geometries will still be null and
accessing them in workspace.js will throw errors.
The workspace views will still get the correct layout as soon as the
allocations happen because syncing the geometries will trigger updating
the window positions. Since animations are disabled for position changes
when syncing the geometry though, we won't get an animation and the
clones will jump into place. That's not a regression though since before
this change we also didn't animate in that case because the geometries
used were simply wrong (the actualGeometry was 0-sized as explained in
the last commit).
If we wanted to fix the initial animation of the overview, we'd have to
always enable animations of the window clones when syncing geometries,
but that would break the animation of the workspace when hovering the
workspaceThumbnail slider, because right now those animations are "glued
together" using the actualGeometry, so they would get out of sync.
The reason there are no errors happening in workspace.js with the
existing code is that due to a bug in Clutter the fullGeometry of
WorkspacesDisplay gets set very early while mapping the WorkspacesViews
(because the overviews ControlsManager gets an allocation during the
resource scale calculation of a ClutterClone, see
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1181), so it
won't be set to null anymore when calling
WorkspacesView.animateToOverview().
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1119
The fullGeometry and the actualGeometry of the WorkspacesDisplay are set
from the allocation of the overviews ControlsManager and the
WorkspacesDisplay, that means they're only valid after those actors got
their allocations during Clutters allocation cycle.
Since WorkspacesDisplay._updateWorkspacesViews() is already called while
showing/mapping the WorkspacesDisplay, that allocation cycle didn't
happen yet and we end up either setting the geometries of the views to
null (in case of the fullGeometry) or to something wrong (a 0-sized
allocation in case of the actualGeometry).
So avoid setting invalid geometries on the views by initializing both
the fullGeometry and the actualGeometry to null, and then only updating
the geometries of the views after they're set to a correct value.
Note that this means we won't correctly animate the overview the first
time we open it since the animation depends on the geometries being set,
but is being started from show(), which means no allocations have
happened yet. In practice this introduces no regression though since
before this change we simply used incorrect geometries (see the 0-sized
allocation mentioned above) on the initial opening and the animation
didn't work either.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1119
Start using the new overlays we introduced in the last commit and remove
the WindowOverlay class and the objects for keeping track of them in the
Workspace.
The new layout which doesn't use the -shell-close-overlap CSS property
anymore sligthly changes the position of the close button to be a bit
further away from the actual window.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1298
So far we allowed the titles of window overlays to expand their width to
be larger than the actual WindowClone, they could expand to the full
size of the Workspace.
Since we're now going to implement those titles as part of the
WindowClone itself, having this feature is no longer possible as easily
as it was before. That's because the clones are stacked according to the
stacking of the actual windows, and since the overlay-elements are
attached to those clones, they will also be shown underneath other
clones.
So stop allowing the titles to expand and limit their size to the width
of the clone, which makes sure titles never get shown above or
underneath other clones.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1298
Add the window overlays we're currently showing using the WindowOverlay
class to the WindowClone class and implement them using
ClutterConstraints instead of the old fixed position/size layout, which
had to be used because the workspaces were scaled, and the title and app
icon were kept unscaled using a separate layer.
Specifically, this is done by adding the ClutterClones to a static
container owned by the WindowClone and adding the elements of the
overlay as children to the WindowClone itself. That way the
overlay-elements can use the container as a source for their constraints
and we avoid having to make sure the overlays remain visible above the
ClutterClones.
We're not using the new overlays yet, they're hidden by default and
showOverlay() isn't called anywhere yet.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1298
Now that we have a new API to get all the windows and metaWindows from
our layout manager, implement the deleteAll() method of the window clone
using that API instead of looping through the children of the actor and
using the source of the ClutterClone.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1298
Now that the folder dialog covers the whole primary
monitor, it eats all input events, and doesn't allow
the event blocker to detect clicks.
Move the click action to the folder dialog itself, and
popdown the dialog if a click is triggered on the dialog
(but not on any children).
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1301
Future commits will improve input handling of the folder
dialog, and they'll require the dialog to cover the whole
primary monitor.
Add another internal, center-aligned container to the
folder dialog, and make it cover the whole available area.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1301
Right now, the app folder dialog isn't really a dialog,
since it is actually added to the AppDisplay. Furthermore,
having it added in AppDisplay may mess up with its sizing
calculations, since AppDisplay has a ClutterBinLayout and
the folder dialog has a fairly large minimum size.
Add the folder dialog to the overview group. Next commits
will adjust various actors to be able to better handle it.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1301
Events have a clear and obvious connection to the calendar, and similar
to the Clocks and Weather sections there's a strong link to a particular
application.
Adding them as another section to the right-hand side of the calendar
therefore presents a viable alternative to the old events section.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1282
The idea behind hiding the notifications and media section on days
other than today was that they represent present activity together
with today's events, in contrast to past and future events from
other days.
After events were moved out of the message list, that behavior is
no longer useful: We just guarantee that the left-hand side of the
calendar will always be empty when browsing the calendar.
Adjust to that by removing the limitation by date.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1282
While treating notifications as a type of present event was a neat
concept, there are some issues with it that we never managed to
address (not least the inability to "open" an event).
So remove the current events section from the message list; we'll
bring back events in a different form later.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1282
This comment is no longer correct, we're not inserting any actors here
to adjust for the window border, but we're modifying the allocation of
the children to adjust for that border.
Since that happens in the layout manager anyway, remove the comment
here.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1297
Now that we handle all ClutterClones belonging to the WindowClone pretty
much the same, we can add a generic _addWindow function to WindowClone
which creates the ClutterClone and adds it to the layout manager.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1297
This isn't quite the same as the allocation, but it's what the workspace
actually wants to use given that we use the bounding box of the
WindowClone for all the layout calculation.
So instead of calculating the windowCenter in the WindowClone, make use
of the bounding-box property of the layout manager and return the center
point of that.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1297
Make use of the new bounding-box property we introduced for the
WindowClones layout manager in the last commit.
With this we can remove all the bounding box calculation code from the
WindowClone class and simply use the "notify::bounding-box" signal to
notify changes to our size. To make sure users of the WindowClone don't
break, we now have to convert the layout managers ClutterActorBox in our
getter function to a JS object.
Since we now also don't have to connect to the "destroy" signal of the
attached dialogs anymore, we can remove _disconnectSignals() and only
listen to "destroy" of the toplevel window.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1297
Move the tracking of the bounding box and all the layout related things
out of the WindowClone class and into the layout manager. This allows
the layout manager to keep track of its windows itself and simply notify
the new bounding-box property in case that box changes.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1297
WorkspacesDisplay is a ClutterActor subclass, and overriding
the show and hide methods require chaining up, otherwise the
actor isn't actually shown or hidden.
To avoid clashing with the pre-existing show method, rename
to animateToOverview.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1295
Unlike the desktop-entry hint, the app name is not optional. That
doesn't mean that we'll be able to match it to a .desktop file,
but we can at least try if we fail to match on PID or desktop-entry.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1291
Since we now have a layout manager for the WindowClone that allows
allocating it a size that isn't the absolute size of the window, we can
now give the WindowClone an artificial size and it will get scaled
accordingly.
So make use of that and stop positioning WindowClones using fixed
position and scale and use a fixed position and fixed size instead. This
will make it easier to use a ClutterLayoutManager to allocate the
WindowClones, because layout managers should only set the allocation of
their children, not the scale.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1294
Since we're going to override the fixed width and height of the
ClutterActor the WindowClone is subclassing, remove those confusing
getter methods for width and height and switch to the public boundingBox
for getting that information.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1294
The getOriginalPosition() API of WindowClone can easily be replaced by
using the existing boundingBox property, which reflects the windows
bounding box in absolute coordinates. This property is also used
everywhere else in the Workspace object, so we can use it here, too.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1294
Change the preferred size functions of the layout manager of window
clones to allow allocating smaller sizes, too. Also scale down the
allocation sizes of the ClutterClones our allocate implementation so
the ClutterClones will scale their texture accordingly.
This will enable us to position the window clones using their allocation
size instead of their scale, which is necessary when introducing a new
ClutterLayoutManager that positions the window clones.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1294
We're going to add a ClutterLayoutManager responsible for allocating the
WindowClones. Since layout managers should only set the allocation of
actors, not the translation or scale, we need to position the
WindowClones using their x, y, width and height properties.
The first step for this is to revert this commit, which switched from
setting fixed positions on WindowClones to using the translation
properties.
This reverts commit 8929c89d1f.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1294
Being able to visualize the actor tree is a handy feature
to have, specially when debugging the hierarchy.
Add a new "Actors" tab to the Looking Glass with the actor
tree inspector. The tree is cleared on unmap to not get
heavy on the number of actors.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1292
As explained in the comment in _init() of WindowClone, we hide the
actual clone from picking so it doesn't interfere with XDND.
This description applies to the clones of the attached dialogs just as
well though, so hide the clones of attached dialogs from picking, too.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1293
We currently only remove the screenshot operation from the shooter
map if the color pick operation completed successfully, but not if
it was cancelled. As a result, we now reject any further requests
from the same sender because we assume that there is an ongoing
operation.
Fix this by moving the cleanup to a finally clause that runs for
both code paths.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1288
Right now _createScreenshot() returns a tuple that indicates failure
when a sender requests a screenshot operation before a previously
started operation finished.
However that doesn't work for the PickColor() method, as it uses a
different return type than the other methods.
Address this by returning an error instead, which works in any case;
arguably trying to start multiple operations in parallel is an error
by the caller more than it is a failed operation anyway.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1288
Now that the only user of the IconGrid is AppDisplay, and
it only uses the paginated icon grid, there's no point in
having the two classes split anymore.
In addition to that, future commits will introduce a layout
manager that will extend current icon grid features, and
merging PaginatedIconGrid and IconGrid in the same class will
vastly simplify this transition.
Merge PaginatedIconGrid into IconGrid, and adapt AppDisplay
to this change.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1267
Now that AllView is the only actor that AppDisplay creates,
we can actually merge them together.
Merge AllView in AppDisplay, remove what used to be AppDisplay,
and rename AllView to AppDisplay.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/880
The Frequent apps grid has a few problems:
* On a fresh install there would be no history of app usage so the
applications shown in the grid have no relevance it takes time
to be useful instead of being useful from the start;
* The grid has far too many items in it to be relevant; 24 apps is
well beyond the average use case as most people don't frequently
use that many, so it gets populated with several apps that are
single use (hello xterm);
* The position of items in the grid are always changing based on an
unknown frequency metric (and not by user-intended input) which
makes it a poor way to quickly launch apps as one would have to
constantly learn the positions of the items in the grid;
* Having two app grids is a bit superfluous and needlessly complicates
the app launching navigation: you have to spend time checking the
frequent grid and if it's not there you have to switch over to another
grid and find the app you need in there it's not straightforward.
Remove the Frequent tab and simplify the related code.
Related: https://gitlab.gnome.org/GNOME/gnome-shell/issues/1425https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/880
With color picking implemented in the compositor, we
can do better than letting the user pick a pixel with
the crosshair cursor, and present them with a preview
of the color that will be selected.
Do this by replacing the cursor with a custom icon and
apply a recoloring effect, where we replace a given color
with the color of the currently hovered pixel (similar
to a green screen).
https://gitlab.gnome.org/GNOME/gnome-shell/issues/451
logExtensionError() currently saves the error message by calling
toString() on the passed error. That's convenient as it allows to
pass a string instead of a "proper" error, but the result isn't
great for the common Error case: Its toString() method prefixes
the message with the error name, which usually is just "Error:".
The plain message is more suitable for displaying it to users,
so use that for Error objects.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2337
Replace the usage of IconGrid in the grid search results by
a custom layout manager that only allocates as many children
as the actor can fit.
This new layout manager does not implement changing the icon
size depending on the screen size.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1265
This is a small convenience method for using ClutterActor's iterator API
with javascript's built-in iterator protocol, for example as:
for (let child of container.iterate_children())
doStuff(child);
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1268
For fd.o notifications, we are taking the sender's PID into
account when associating notifications with sources (mainly
to deal with notify-send).
This broke when the implementation under the well-known name
was moved into a separate service, as the implementation in
gnome-shell will now always see the public notification-daemon
as sender.
Restore the old behavior by resolving the sender PID in the
separate service, and pass it as hint to the implementation
in gnome-shell.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2592
Spidermonkey caches imports, which means that uninstalling an
old extension version and installing a new one doesn't work as
expected: If the previous version was loaded, then its code will
be imported instead.
For the last couple of releases this has been a reliable source
of extension bug reports after major GNOME updates. Thankfully
chrome-gnome-shell removed its update support in favor of our
built-in support now, but users may still use older versions
or perform those actions manually, so it still makes sense to
catch this case and set an appropriate error.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1248
The do-not-disturb button and the contained switch are
tied together via a bidirectional property binding.
However it still matters which objects are used as source
and target, as that will determine the initial state: Right
now the (unchecked) button is used as source, which means
that do-not-disturb is turned off on startup.
We want the state to be preserved, so swap source and target
to let the switch (that is bound to the underlying GSetting)
control the initial state.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2804
Sliders can be operated by mouse scroll, but the mouse has to be over
the slider control. Make the brightness and volume system menu entries
forward scroll events to the sliders they contain so that scrolling
anywhere on the menu item operates the slider.
Closes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2795
Whether or not an extension has errors influences the 'canChange'
property, but so far we only update it for errors that occur when
initializing the extension, not when an extension is enabled later.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1249
Soup.SessionAsync by default sets timeout and idle_timeout to 0. This
causes connections to hang around in state CLOSE_WAIT forever after the
remote host has closed the connection.
To fix this, we could set timeout and idle_timeout manually. However,
Soup.SessionAsync is marked as deprecated anyway and should be replaced
by Soup.Session. Doing so also sets a default timeout of 60 seconds.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2774
Removing a stylesheet from the theme will trigger a style update. There's
little point in updating the extension actors that are about to be destroyed
(hopefully), so call the extension's disable() function first.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2757
Sometimes an MPRIS media player will create and then destroy an object
before the signals that handle the object's destruction can be created.
This verifies that the object still exists after the necessary signals
have been created.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2776
Since commit 0ecddafc20 gsd-xsettings startup has been made conditional
on the systemd user instance being available at runtime. While that is
correct, it means that completing xwayland startup is also conditional
now.
We always want xwayland startup to go ahead, so wait for the XSettings
plugin to appear on the bus when gsd-xsettings is launched by gnome-session
and complete the task immediately if startup fails.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1252
Changing the icon to 'system-log-out-symbolic' has no visual
change in a default GNOME setup since both 'system-log-out-symbolic'
and 'application-exit-symbolic' are the same in adwaita-icon-theme
(at the time of writing), however, other icon themes differentiate
between the two icons so pointing to the appropriate icon name
is the right thing to do.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2751
Commit 764527c8c9 not only ports this file
to Promises but also changes the behavior of _initPanelService method.
Instead of always calling _updateReadiness when _panelService is ready,
it only calls it when get_global_engine_async succeeds.
The only callers of _updateReadiness are _initEngines and
_initPanelService. Assume that _initEngines completes first. Its
_updateReadiness call keeps _ready as false and it is expected for
_initPanelService to change it to true. However, since
get_global_engine_async fails because there is no active engine,
_initPanelService never calls _updateReadiness. Therefore, all setEngine
calls do nothing because _ready is false, and the input method panel
never shows. Users are unable to use any input method even if they can
see that ibus-daemon is already running.
Fix the issue by changing it back to the old behavior.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1235
gjs has gotten less forgiving about missing getters/setters, and
commit 6aa1b817 missed the missing getter in the base policy class.
Most notifications use a policy subclass that already provides a
getter, but at least Main.notify() and friends don't; unbreak them
by fixing the base class.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1229
When a modal that's not on top of the modalActorFocusStack gets popped,
we shift the focus stack as described in popModal() to ensure the chain
remains correct. That however destroys the association of a modal actor
and its prevFocus actor on the focus stack, because the prevFocus actors
are now moved to different entries of the stack.
Now when a prevFocus actor gets destroyed, we don't handle that case
correctly and search for the modal actor that was associated with the
prevFocus actor before the stack was shifted, which means we end up
unsetting the wrong prevFocus actor.
So fix that and search the stack for the prevFocus actor which is being
destroyed instead to unset the correct entry.
Thanks to Florian Müllner for figuring out the actual issue and
proposing this fix.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2446
The workspace switcher blocks state updates while the indicator is
animating. Since commit 9c1940ef9d the indicator is considered to
be animating when the workspace adjustment's value doesn't equal the
active workspace.
There is one case though where this breaks badly: When a workspace
is inserted before the active one, the adjustment's upper and value
properties are changed without transitions. But if that change happens
while there's an ongoing transition to the previously active workspace,
the value gets out of sync with the active workspace and we end up
blocking state updates indefinitely.
Fix this by removing any transitions before setting the adjustment
value.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2625
We override the :visible property for the keyboard actor, but don't
provide a corresponding setter. The property is therefore read-only
on the javascript level, and any attempt to set it will fail.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2691
Just as with the last commit, we should not break the assumption made by
Clutter that parents have their allocation set before their children get
allocated, so fix that here, too.
In this case we have to fix it by chaining up to the parent vfunc
override and updating the allocation once more before allocating the
`this._label` child.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/1615
It's important to update the allocation of the parent before allocating
its children, it's an assumption we make in a lot of places.
This broke resource scale calculation for boxpointers and their
children when multiple monitors with different scales are used and the
primary monitor is not positioned at x=0, y=0.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/1615
The session mode determines whether the screen casting should work or
not, but until now only dealt with the built in screen cast, not the
ones using PipeWire. Add the newly added API for inhibiting remote
access when the session mode says screencasts are not allowed.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1210
As of mozjs68 (gjs-1.64) `globalThis` is recommended over `window` and
it makes more sense in this context anyways. Migrate the few instances
of `window` we use and adjust the eslint configuration.
`window` will continue to resolve to `globalThis`, so this won't affect
extensions or other downstream users.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2322closes#2322
getEvents() filters all events for the given range and sorts the result.
That's more than we need when checking whether there are any events,
where we only care that there's at least one event in the range.
Address this by splitting out the event filtering into a generator
function, so hasEvents() can return after at most one iteration.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1192
We track messages so that we can account for just added and removed
events instead of having to rebuild the entire list, however it's
also possible that the time or summary of an existing event changed.
Account for that by updating existing messages in-place.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1192
We currently let the entry of the autoPrompt grab the key focus inside
setQuestion(), which is called from _onAskQuestion(), which is the
callback of the "ask-question" signal.
It seems that the "ask-question" signal isn't emitted again right after
the password-check failed, but a few seconds after that. Since we get
the "verification-failed" signal earlier than "ask-question" (right
after we know the check failed) and we also get a hint whether the entry
should be usable again with the canRetry argument, we can also grab key
focus to in the same step.
So do that by grabbing key focus when making the entry sensitive.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2655
The additional function UnlockDialog.addCharacter() is only used at one
place, so we can simply remove it and call AuthPrompt.addCharacter()
directly. The AuthPrompt is shown right before that anyway.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1209
Normally, we inhibit suspend while locking the screen. But in the
session mode used for gnome-initial-setup locking is not supported, so
in that case this inhibit call is pointless and should be avoided.
Without this patch you get the following error when you suspend and
resume during initial setup:
JS ERROR: Error getting systemd inhibitor: Gio.IOErrorEnum:
GDBus.Error:org.freedesktop.login1.OperationInProgress: The operation
inhibition has been requested for is already running
_promisify/proto[asyncFunc]/</<@resource:///org/gnome/gjs/modules/core/overrides/Gio.js:435:45
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1213
On Fedora 32 if you close the laptop lid during gnome-initial-setup,
gnome-shell hits this error:
JS ERROR: Exception in callback for signal: prepare-for-sleep: TypeError: this._dialog is undefined
_resetLockScreen@resource:///org/gnome/shell/ui/screenShield.js:434:9
activate@resource:///org/gnome/shell/ui/screenShield.js:571:14
lock@resource:///org/gnome/shell/ui/screenShield.js:617:14
_prepareForSleep@resource:///org/gnome/shell/ui/screenShield.js:219:22
_emit@resource:///org/gnome/gjs/modules/core/_signals.js:133:47
_prepareForSleep@resource:///org/gnome/shell/misc/loginManager.js:198:14
_emit@resource:///org/gnome/gjs/modules/core/_signals.js:133:47
_convertToNativeSignal@resource:///org/gnome/gjs/modules/core/overrides/Gio.js:169:19
This is because _ensureUnlockDialog() hit its first early return. So
return early from activate() in that case, so this._dialog doesn't get
used while it's null.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1213
StButton returns CLUTTER_EVENT_STOP in various circumstances, but
AppIcon throws that away and returns CLUTTER_EVENT_PROPAGATE even
when it should stop.
Return the parent class' result instead of CLUTTER_EVENT_PROPAGATE.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1211
These properties are never written; in the base class they are always
their default values, and in the subclasses the getters are overridden.
This will be necessary because GJS is adding checks to make sure that
readable properties always have a getter, writable properties always
have a setter, and that the variations of camelCase/snake_case are
handled correctly. It's supposedly backwards compatible, but that
assumes that code is not doing things like forgetting a setter on a
writable property. (If the missing setter had ever been called, it might
have led to a crash, which is why we've made this change.)
This is the minimally invasive patch which should work with both older
and newer versions of GJS. If you decide to require GJS 1.65.2, then
you'll also be able to remove the getters from NotificationPolicy as
well.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1205
We want the spinner to be centered with regard to the entry, but
constraining the height breaks that:
1. clutter_actor_allocate() is called with the available size
2. clutter_actor_update_constraints() then adjusts that according
to the constraints
3. clutter_actor_adjust_allocation() applies the margin/expand/align
properties.
The issue there is that 2. reduces the allocation to the desired size,
so there is no more extra space to distribute in 3.
We can fix this by either constraining everything (and rely on the
cancel button's alignment) or limit the constraint to the width. The
latter seems more appropriate, given that the constraint is only used
to center the entry horizontally.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2628
When handing the resetDialog request we're leaving a source ID alive,
leading this error:
(gnome-shell:22464): GLib-CRITICAL **: 17:46:11.065: Source ID 12934 was not
found when attempting to remove it:
== Stack trace for context 0x55c9246916c0 ==
#0 55c9249151b8 i js/ui/components/polkitAgent.js:391 (11f71fd544c0 @ 100)
#1 7ffc55140aa0 b self-hosted:1009 (3062ba49af88 @ 423)
#2 55c924915120 i js/ui/modalDialog.js:167 (1c9e50ae9880 @ 62)
#3 55c924915098 i js/ui/modalDialog.js:186 (1c9e50ae9970 @ 12)
#4 55c924915008 i js/ui/environment.js:75 (1c9e50a8d5b0 @ 98)
#5 55c924914f78 i js/ui/environment.js:149 (1c9e50a8d9e8 @ 14)
So, reset the source handle to avoid trying to remove it.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1203
Clutter.Animation doesn't contain any animation modes, they live in
Clutter.AnimationMode. The places we did `Clutter.Animation.WHATEVER`
just evaluated to `undefined`. Thus, use the correct namespace for the
animation mode enums.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1199
Translations are provided by .directory files, so trying to look
up a category name without the suffix will always fail.
Commit 343b3351f1 tried to fix this previously by changing the
saved keys, but that broke existing translatable folders.
Appending the .directory suffix for the lookup instead fixes the
issue without regressing non-custom folders.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2623
Right now, the actor hierarchy is such that the scroll view
does not contain the actual grid. It looks as follows:
StScrollView
↓
StBoxLayout
↓
ShellStack
↓ ↓
PaginatedIconGrid StWidget
This hierarchy can be slightly reorganized by changing it to be as
follows:
ShellStack
↓ ↓
StScrollView StWidget
↓
StBoxLayout
↓
PaginatedIconGrid
This will simplify future work where the PaginatedIconGrid will be
an implementation of StScrollable, in which case we'll be able to
simply remove the StBoxLayout from there.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1191
If a search provider is installed by an app which is blacklisted for the
current user by their parental controls, don’t show it or results for
it.
Currently, this only filters ‘remote’ (not built-in to the shell) search
providers. This seems fine for now; in future it could be expanded to
also filter built-in search providers, if any of them end up needing to
be filtered.
No corresponding changes need to be made `remoteSearch.js`, because the
results of `loadRemoteSearchProviders()` are filtered in `search.js`.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/465
Filter the apps shown on the desktop and in search results according to
whether they are blacklisted by the user’s parental controls.
This supports dynamically updating the filter during the user’s session.
This adds an optional dependency on libmalcontent. If that’s unavailable, no
parental controls filtering will occur.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/465
While we now deal more gracefully with adapter removals, we can
still mess up the hadSetupDevices tracking:
As adapters become available before any devices, we'll always
reset the setting to false when Bluetooth is turned on. And if
no set up device happens to be in range, it will still be false
when Bluetooth is turned off again.
To address that, only update the setting if we have an adapter
(like we do now) and we had one before (so it wasn't the adapter
itself that changed).
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1174
Our intended behavior when bluetooth is turned off is to keep
the menu visible if devices had been set up previously.
However since gnome-bluetooth@c437c729, devices are removed
first before removing the default adapter, so we now end up
always setting the property to false before checking for it.
Fix this by deferring all model changes to an idle, so that
we can process them as a unit. Do the same for proxy property
changes, as those may trigger a row-removal.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1174
Since commit 26c2cb9f65, nDevices is always the actual number of
paired/trusted devices. So when bluetooth is turned off, it is
now 0 rather than forced to 1 if devices were set up previously.
Fix this by checking the property that tracks set up devices instead.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1174
Pretty much the same case of the previous commit: we want this size
to be scale-dependant, and using the width and height properties of
ClutterActor doesn't automatically update.
Use CSS to set the width and height.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1176
The return value of st_theme_node_lookup_length() is scaled according
to the scale factor. IconGrid.ICON_SIZE is not. However, when BaseIcon
tries to fetch the CSS value for "icon-size" (which returns a scaled
value), it uses it as-is, mixing the two coordinate systems.
Use a single coordinate system (unscaled sizes) in IconGrid.BaseIcon.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1175
Usually the screen is woken up before the shield is deactivated, but
it is also possible to unlock the session programmatically via the
org.gnome.ScreenSaver D-Bus API.
The intention is very likely not to unlock a turned off screen in
that case. Nor does it seem like a good idea to change the lock
state without any indication.
Waking up the screen is more likely to meet expectations and is
more reasonable too, so do that.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1158
Extension that want to expose their own preferences (for example as menu
items) do that by passing their UUID to gnome-shell-extension-prefs.
But since 3.36.1 the app is optional and no longer accepts arguments on
the command line. To adjust, extensions now need to make a D-Bus call
the extensions portal, just like the app and gnome-shell.
We will add a convenience method for that purpose, so it makes
sense to share the existing code. As it's extension-related, the
extension manager looks like the right place ...
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1163
A promisified method expects the callback parameter to be either
a function (in which case the original method is called normally)
or omitted altogether (in which case a Promise is returned).
The call to open application details in Software does neither and
passes null instead, which will result in a warning (because no
function argument means a promise will be used, but not omitting
the parameter means we end up with too many arguments).
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2551
In case where only one device is connected, we want to display its name
in the menu. For that we will need more than the number of known/connected
devices, so change the function to return an array of device infos instead.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2340
During the shell initialization we call the (deprecated) function to
override the Desktop environment in Gio DesktopAppInfo to make sure that
applications are correctly shown (as per commit b2fbf5a2), however this
might break the cases in which $XDG_CURRENT_DESKTOP is already set and
contains GNOME (given that is now a list).
In Ubuntu this is in fact set to: ubuntu:GNOME.
Now, if an application contains NotShowIn=ubuntu, the key will be ignored by
the shell, and the application is still listed everywhere.
So, override the DesktopAppInfo desktop environment only in the case that
the current desktop is not already GNOME.
At the current date I think we could just safely get rid of this override at
all, but there could be still cases where it still might be useful, like when
running as nested in some other environment, so keeping it.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1156
In some situations we could end up not with lingering 'view-loaded'
handler. This could result in delayed spring animate-in being initiated,
e.g. after a minute after the activities overview was already closed.
Fix this by removing any lingering signal or later handlers when
unmapping.
Fixes: 5c33fe4a0ahttps://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1155
Promises make asynchronous operations easier to manage, in particular
when used through the async/await syntax that allows for asynchronous
code to closely resemble synchronous one.
gjs has included a Gio._promisify() helper for a while now, which
monkey-patches methods that follow GIO's async pattern to return a
Promise when called without a callback argument.
Use that to get rid of all those GAsyncReadyCallbacks!
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1126
Starting the animation from the actor 'paint' signal has various
unwanted consequences, such as sometimes trigger a
clutter_actor_queue_relayout() during the paint phase. One unwanted
consequence was that an offscreen actor effect was disabled during
painting, meaning the effect would begin being active, but later during
the post-paint processing being disabled. The caused said effect to push
an offscreen framebuffer to the paint context, but then just destroy it
instead of popping it. When this happened, we'd end up trying to operate
on a framebuffer that may had been finalized, or not, depending on the
garbage collector. Sometimes, for some users, this caused a segmentation
fault when trying to pop a matrix from the framebuffer matrix stack.
Deal with this more properly, by using the 'view-loaded' signal to wait
with animation until the view is loaded, as well as using MetaLater to
schedule the start of the animation.
For when a view was signalled to be ready, we're in a state where we can
start animation before the next frame as the layout is ready, but when
not, we have to add back the "hack" where we must wait for one frame for
the target icon positions to be up to date. Do this by adding a
MetaLater IDLE callback that starts the animation *after* the next
frame. This also needs the old 'opacity = 0' work around to not show an
incorrect first frame.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2418https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1154
The text is part of the entry, so it is surprising that it can
still be edited when the entry itself isn't reactive. Address
this by setting up a binding instead of expecting all consumers
to handle the case themselves.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2423
Set the do not disturb label as the label actor for the do not disturb switch,
so that Orca speaks the do not disturb label when the user moves
keyboard focus to the do not disturb switch.
Also enable toggle mode for the "Do Not Disturb" button and bind it's checked
state to the state property of the switch. This makes sure that Orca presents
thecorrect state of the do not disturb switch to the user.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2508
It seems there is a weird race condition between Clutter trying to
destroy the keyboard actor and Clutter trying to hide the keyboardBox
container actor: If the keyboardBox is hidden before destroying the
keyboard actor, Clutter doesn't repaint anything and the keyboard
remains visible until something else draws over it.
To fix this issue until we find the underlying Clutter bug, simply
destroy the keyboard actor before hiding the keyboardBox. The order in
which we call these doesn't matter anyway since hideKeyboard(true) hides
the keyboard immediately without an animation.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/1736https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1142
We're dealing with attached keyboards now using the touch_mode property
of ClutterSeat: If a device has a keyboard attached, the touch-mode is
FALSE and we won't automatically show the OSK on touches, also the
touch-mode gets set to FALSE when an external keyboard is being plugged
in, so that also hides the OSK automatically.
With that, we can now ignore keyboard devices when updating the last
used device and no longer have to special-case our own virtual devices.
Because there was no special-case for the virtual device we use on
Wayland now, this fixes a bug where the keyboard disappeared after
touching keys like Enter or Backspace.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2287https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1142
Since commit 2894085c45 we omit sound feedback on volume changes
if something is already outputting sound. Unfortunately that
"something" may be our own feedback (from a previous volume
change).
In that case we do not want to omit the new feedback, so instead
cancel the previous one.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1147
The offset argument is changing from uint to int. Which means we
might would pass a negative offset and trigger an "out of bounds"
error. Make it work more or less alright with older mutters, by
clamping the offset to 0.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1146
Since commit 784c0b7e4 we use the name of the nearest city rather
than the weather station, as the latter tend to have unwieldy
and weird names.
However the nearest city may not be that near after all, in which
case the result is again surprising.
Address this by not using the nearest city name unconditionally, but
only if it appears in the station name.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2468
AuthPrompt is created on demand, and this._authPrompt is
expected to be null except on very strictly controlled
occasions. The idle monitor callback isn't one of them.
Check if AuthPrompt exists before cancelling it.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2371
The Extensions app code is now independent enough from the rest of the code
base to move it to its own subprojects, like we did for the extensions-tool.
This allows for stand-alone builds of the app, which we are about to use
for distributing it as flatpak.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1133
We include config.js because it is a dependency of ExtensionUtils,
but it's not actually used in the code paths we exercise.
As we want to allow stand-alone builds of the app, it is much easier to
fake the module than to either include a generated file from elsewhere
in the tree or generate it ourselves.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1133
Instead of adding a dragMonitor for every icon in the grid as soon as
one icon is getting dragged, only add a dragMonitor for the icon that is
currently being dragged over (ie. the current drag-target). With a large
number of icons in the iconGrid, this should significantly reduce lags
while dragging.
We can do this by detecting the DnD-entering of an icon or folder using
the `handleDragOver()` callback of drag-targets, adding the dragMonitor
because we know an icon is hovering above the drag-target and then
detecting the DnD-leaving of the drag-target by using the `dragMotion()`
handler, where we remove the dragMonitor again as soon as the
targetActor is no longer our actor (ie. the drag-target).
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/849
While it should be impossible to destroy a FolderIcon while a DnD action
is still going on, there might still be rare cases where this happens
(ie. when a folder is removed because an app got deleted during DnD).
So make sure we're on the safe side here and don't potentially leave
dragMonitors around after the icon is destroyed by removing the
dragMonitor inside the onDestroy handler of the FolderIcon, just like we
do for AppIcons.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/849
Forward the arguments at the 'delete-surrounding-text' signal
from IBusInputContext to clutter_input_method_delete_surrounding()
so that ibus-typing-booster use the deleting surrounding text function.
Input method engines can delete the output text in applications
with this function.
This change will require a change of mutter of mutter!517
because the first arguemnt of the 'delete-surrounding-text' is INT
to express the offset of the current cursor position but
the first one of clutter_input_method_delete_surrounding() is UINT
since the Wayland spec accepts UINT in delete_surrounding()
mutter will change the type of the first one to INT in
clutter_input_method_delete_surrounding() to work with this change.
https://gitlab.gnome.org/GNOME/mutter/issues/539https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/477
While we don't technically need the app to download and apply
updates, we do require it for notifying the user about available
updates and listing extensions with pending updates.
So instead of intransparently applying updates in the background
without the user noticing, disable updates altogether if the
Extensions app is not installed.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2346
Blacklist support was added all the way back in commit 1e286e43, but
the code had been defunctional until recently. While uninstalling an
extension that has been blacklisted makes sense off-hand, unfortunately
we don't know if an extension was *actually* blacklisted:
The website returns that operation for any extensions for which it
doesn't find any versions that match the shell version. That is, the
most likely reason is that the user updated to a new GNOME release
which the extension doesn't support yet.
It doesn't look like the website is going to change that behavior any
time soon[0], so drop the 'blacklist' handling for the time being.
[0] https://gitlab.gnome.org/Infrastructure/extensions-web/-/issues/95https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1132
Commit 55b57421d changed signal handlers to the corresponding vfuncs,
but didn't always chain up as necessary. In most places this doesn't
matter, but at the very least the commit broke activating message list
items via the keyboard.
Add all (hopefully) the missing chain-ups to get the expected behavior
back.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2319
Destroying the policy invalidates it, so accessing it from a
Source::destroy handler (for example to disconnect signal
handlers) currently results in warnings like:
Object .Gjs_ui_messageTray_NotificationApplicationPolicy
(0x7f8c7c0a64a0), has been already deallocated — impossible
to access it.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2238
Since PackageKit 1.11.1, the prompt to install updates on the end
session dialog has been (mostly) broken. The problem is that it only
works if PackageKit is running at the time the end session dialog is
opened; otherwise, our GDBusProxy has invalidated all of its properties,
which we read to see if update is possible. We need to autostart
PackageKit before reading its properties to fix this problem. That would
be easy if we were calling a method to see if an update or distro
upgrade were available, but since we're just checking a property, using
cached properties won't suffice. We'll have to manually check the
property value to ensure we autostart PackageKit.
Most of the code is written by Florian. Thanks Florian!
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/2276
Previously we'd show the system background and then wait till the
main loop was idle before beginning the shell startup animation.
This resulted in one initial frame that was always just the system
background.
Now we try to get both the system background and the startup animation
begun on the same first frame.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1102
In telepathyClient we consider messages both Tpl.TextEvents and
Tpl.Messages, and we manually create JS objects to copy the properties we
care for each one. This may lead to objects not matching the interface we
want.
Instead, use an object with construct-only properties and two factory static
methods to initialize it.
Unfortunately we need to use the ChatMessageClass for the class name or
calling the static methods would trigger a gjs error as per [1].
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1113
[1] https://gitlab.gnome.org/GNOME/gjs/-/issues/310
We now warn on startup if screen locking isn't available, however for
users who choose not to use GDM or logind, repeating the warning on
each login is more annoying than helpful.
Instead, limit the warning to the first login on which the screen lock
became unavailable. That way the notification will still serve the
intended purpose of informing the user, but without being perceived
as nagging.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2432
It's easy to forget to add a new <release> tag to the metainfo when
doing a new release.
Address this with an additional test if appstream-util is recent
enough to include the new validate-version command, so distcheck
fails when the metainfo wasn't updated.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1117
Commit da537cda43 moved the Shell.Screenshot API to GIO's async pattern,
but we never set the GError passed to the *_finish() functions and only
indicate failure by returning FALSE.
The expected behavior is to throw an error in that situation, so make sure
we do that.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1123
As outlined earlier, in order to turn the Extensions app into a properly
sandboxed application, we need to split out the extension prefs dialog
and move it elsewhere.
With "elsewhere" being the new Extensions D-Bus service, effectively
turning it into a shell extensions portal.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1106
Similar to the previously added org.freedesktop.Notifications proxy,
this exposes the org.gnome.Shell.Extensions API and forwards any
request to the real implementation in gnome-shell.
The motivation differs though: We want to be able to package the
extension app as flatpak and distribute it separately, but the
extension prefs dialog is hard to impossible to sandbox:
- filenames need translating between host and sandbox, and we
can only do that in some cases (serializing/deserializing
extensions), but not others (extension settings that refer
to files)
- system extensions install their GSettings schemas in the system
path; the best we can do there is assume a host prefix of /usr
and set GSETTINGS_SCHEMA_DIR in the flatpak (eeks)
- extensions may rely on additional typelibs that are present on
the host (for example because gnome-shell itself depends on
them), but not inside the sandbox - unless we bundle all of
gnome-shell's dependencies
- if gjs/mozjs differ between host and sandbox, extensions must
handle different runtimes for the extension and its prefs
And all those issues occur despite a very permissive sandbox (full
host filesystem access, full dconf access, full org.gnome.Shell
access (including Eval()!)).
This new service will give us an alternative place for handling
the preference dialog:
- it runs outside of gnome-shell process, so can open windows
- it runs on the host, so the extension's prefs get to run
in the same namespace as the extension itself
That is, the service will provide portal-like functionality (albeit
not using the org.freedesktop.portal.* namespace, as extension
management is an inherently privileged operation).
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1106
We are jumping through quite some hoops to support showing only the
preference dialog when given a UUID on the command line.
As gnome-shell is about to stop calling out to us for the prefs dialog,
the reason for supporting this is going away, so remove all the special
handling.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1106
The dialog that contains the extension's preference widget has become
fairly complex over time, mostly due to the error handling.
It therefore makes sense to move it to a template, just like we did
for the main application window and extension rows.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1106
On X11, _onFocusChanged() updates the input region, as well as the
reactive-ness of the dialog's buttons.
That method is not only used as signal handlers (which are correctly
disconnected when the dialog is hidden), it also runs when the "show"
transition completes.
That's a problem if the transition is still ongoing when the dialog is
hidden, as it will then only complete when it is replaced by the "hide"
transition, after the this._dialog has been reset to null, and trying
to access the dialog's buttons results in an error.
Avoid this by explicitly removing all transition on hide before
resetting the dialog.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2467
Commit c1ec7b2ff meant to fall back to the base layout in case
a variant like `fr+oss` is set up, but as we are checking for
'+' on the array rather than the layout name, the fallback only
"works" for a layout that is literally called '+', whoops.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2471
Detailed notifications are meant to be single line, just as unexpanded
notification banners. So handle them the same way as in the message
list, and replace embedded newlines by spaces.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2463
We only show the list of system- and user extensions if corresponding
extensions are installed, however we only update the visibility
after loading the initial list of extensions.
As it's possible for the first user extension to be installed while the
app is open or the last one to be removed, we should also update the
list visibility after extension state changes.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1088
While we only shut down after a method call completed or (if the
interface has signals) the sender disconnects from the bus, services
may need to inhibit auto-shutdown for more specific reasons themselves,
for example when a method call kicks off an operation that should
complete before shutting down.
Add hold() and release() methods like Gio.Application for those cases.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1115
Some timezones, like the one of Kathmandu don't only have hour-based
timezone offsets, but their timezones are also offset by minutes. So
instead of showing weird values like "+5.8", show the minutes properly
in a format like "+5:45".
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/2438
I misremembered that imports.package.start() would set up the correct
gettext domain, but the module only provides a convenience method
for doing that.
Use it to bring back translations in the Extensions app, whoops.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1108
Now that the org.gnome.Shell.Extensions interface exposes the
disable-user-extensions setting on D-Bus, we can use that instead
of the shell's GSettings.
In a future where we distribute the app separately as flatpak, this
will require one less hole in the sandbox.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1081
Using the "regular" loadInterfaceXML() helper means less code duplication,
but it also ties us to the resource used by gnome-shell.
In order to untangle the extension app from core gnome-shell, change that
to load the interface from the existing data resource instead. While that
does involve reimplementing loadInterfaceXML(), it's not too bad actually
with the resource-loading code stripped (as the data resource is already
loaded by the package module).
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1081
We want to make the extensions app code more self-contained to make it
easier to build separately, and ultimately make it available on flathub.
One complication we are facing is that it is currently all over the source
tree:
- js/extensionPrefs for the main code
- src for the launcher process
- data for .desktop file and icons
Switching from a C launcher to the imports.package module allows us to
consolidate the first two, and will also take care of the annoying
setup bits (defining JS search path, extending GI lookup, loading
resources).
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1081
Extension updates are installed at startup, so any errors that bubble
up uncaught will prevent the startup to complete.
While the most likely error reason was addressed in the previous commit
(pending update for a no-longer exitent extension), it makes sense to
catch any kind of corrupt updates to not interfere with shell startup.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2343
When an extension is uninstalled, there is no point in keeping
a pending update: If the update didn't fail (which it currently
does), we would end up sneakily reinstalling the extension.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2343
Doing blocking IO in a graphical UI is bad, doing it in the compositor
is much much worse. So even if handling VPN requests is a relatively
rare event, doing it asynchronously is better.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2386
libnm doesn't only search for plugins in the regular VPN plugin directory,
but also in the legacy location and the directory pointed to by the
NM_VPN_PLUGIN_DIR environment variable (if set).
We don't monitor the additional directories, so it's possible for our cache
to become outdated.
Instead of trying to play catch-up with libnm's internals, do what nm-applet
does and use the appropriate API to look up the plugin on each request.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2386
checkForUpdates() will currently always query the server for updates,
even when passing an empty vardict of installed extensions. We know
there won't be any updates in that case, so avoid a pointless network
request.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1100
There are two ways for applications to provide a high contrast icon:
1. install an icon into the HighContrast theme
2. install a symbolic icon into the default hicolor theme
The latter is preferred nowadays, and implemented in the high-contrast
CSS variant by enforcing the symbolic icon style.
However together with the way we currently enable/disable high-contrast,
this can lead to the following race:
1. the GTK theme is changed from HighContrast
2. we reload the default stylesheet
3. the icon style changes to "regular", so we request a
new icon from the HighContrast icon theme
4. the icon theme is changed from HighContrast
5. we evict existing icons from the cache
6. we reload icons for the new icon theme; however as we
find a pending request (from 3), we re-use it
7. the request from 3 finishes, and we end up with a
wrong icon in the cache
The simplest fix is to change the icon theme before the GTK theme: Unlike the
theme name, the icon style is encoded in the cache key, so we won't re-use
an old (and incorrect) request in that case.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2414
The SignalQuality property is defined on the GDBusProxy, not the modem
JS object.
Fix this runtime warning:
JS WARNING: [resource:///org/gnome/shell/misc/modemManager.js 252]: reference to undefined property "SignalQuality"
JS ERROR: TypeError: this.SignalQuality is undefined
_reloadSignalQuality@resource:///org/gnome/shell/misc/modemManager.js:252:34
_init@resource:///org/gnome/shell/misc/modemManager.js:234:14
NMDeviceModem@resource:///org/gnome/shell/ui/status/network.js:517:34
_deviceAdded@resource:///org/gnome/shell/ui/status/network.js:1755:27
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1097
When launching the default calendar application, we special-case
evolution to make sure it starts up with the calendar component.
This is currently broken in two ways:
- evolution changed its .desktop file to use reverse DNS notation
- as evolution can now be distributed via flatpak, we can no longer
assume that 'evolution-calendar.desktop' exists when evolution does
(even though we ship the .desktop file ourselves, it is considered
invalid if the executable isn't found)
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1093
At least for the time being, this looks like the easiest option to
launch the service:
- we could add a systemd unit, but then we'd need to update the
RequiredComponents in the fallback session definition as well,
making it necessary for gnome-shell, gnome-shell-extensions and
gnome-session to be updated to 3.36.1 in lockstep
- autostart is problematic as it would make gnome-shell conflict
with other notification daemons; also autostart is most useful
with automatic shutdown, which would require tracking signal
subscriber to determine when the service is unused
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/547
Add a small service that exposes the Fdo notification API under the
well-known name, and forwards any requests to the actual implementation
in the shell.
That way any app with permission to talk to org.freedesktop.Notifications
will get exactly that, and nothing more.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/547
There are a couple of D-Bus services that are currently provided by
gnome-shell for which it makes sense to move them fully or partially
into separate processes:
- screen recording (performance)
- FDO notifications (security)
- Extensions (portalization)
Add some base classes and build system glue to take care of the
common boilerplate.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/547
This caches GAppInfo so that the compositor thread does not have to perform
costly disk access to load them. Instead, they are loaded from a worker
thread and the ShellAppCache notifies of changes.
To simplify maintenance, ShellAppCache manages this directly and the
existing ShellAppSystem wraps the cache. We may want to graft these
together in the future, but now it provides the easiest way to backport
changes to older Shell releases.
Another source of compositor thread disk access was in determining the
name for an application directory. Translations are provided via GKeyFile
installed in "desktop-directories". Each time we would build the name
for a label (or update it) we would have to load all of these files.
Instead, the ShellAppCache caches that information and updates the cache
in bulk when those change. We can reduce this in the future to do less
work, but chances are these will come together anyway so that is probably
worth fixing if we ever come across it.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2282
These paths are meant for Xwayland, not for X11 compositors being restarted
through alt-f2 + r. Maybe some signal analogous to init-xserver should be
added for Xwayland shutdown paths, but this signal we are currently
listening for is backend agnostic.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/2329
Since the FolderViews are not connected to the "installed-changed"
signal, we need to reload their apps by calling _redisplay() when an app
is removed or installed. We can't connect to "installed-changed" inside
FolderView because we need to ensure _redisplay() of the FolderView is
called before AppView tries to access the apps of the folder inside
_refilterApps(). So reload the FolderViews inside AllViews _redisplay()
implementation to ensure everything is up to date before accessing the
apps of the folder.
Since the "apps-changed" signal of FolderIcon now indirectly triggers a
_redisplay() of the FolderViews, the 'changed' handler of FolderView is
now redundant and can be removed. Because of this, we also need to move
the emission of the "apps-changed" signal to the start of the signal
handler to make sure the view is updated before we try to access items
of the view.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1901https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1011
We should disconnect the folders "changed" signal from the folder in
case the FolderView or FolderIcon is destroyed. While at it, also remove
the unused this._spaceReadySignalId of FolderIcon.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1011
The _redisplay() function is usally used for subclasses of BaseAppView
which want to implement their own _redisplay() function, having that
function name in two classes which have nothing to do with BaseAppView
can be quite confusing. Make those names less confusing and call the
functions _sync() and _rebuildMenu() instead.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1011
The viewBox has a border applied, so when we call adaptToSize using only
the content box of the container, the width of the border is not removed
from the content box and the grid will be allocated less space than what
we told it before using adaptToSize.
Fix that by adjusting the content box for the size of the viewBox, too.
This makes sure the correct amount of columns can be shown inside a
folder, since right now we only show 3 colums even though 4 would fit.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1011
Since 38da479ee we correctly ceil the non-integer radius of the slider
handle when calculating the offset for drawing the circle. Since the
handle also has a border with a width of 1px by default, we should also
factor that in when calculating the offset.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1569
Along the lines of `styleSheetName`, a session mode may want to provide its
own gresource file, so make this possible via a `themeResourceName` session
mode parameter, defaulted to gnome-shell-theme.gresource
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1063
Unlike any other methods in the Extensions API, LaunchExtensionPrefs()
opens what appears to be an application dialog, except that it is
really a separate application that the caller has no control over.
In order to address that, add a new OpenExtensionPrefs() method that
takes additional parameters (modelled after the desktop portal APIs)
that will make it possible to improve the behavior in the future.
The new parameters are ignored for now, but pushing the API out now
will allow us to fill in the functionality post the .0 release.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1074
The 'disable-user-extensions' GSettings key is the last extensions-related
setting that isn't exposed over D-Bus, and therefore requires consumers
to access the GSettings directly.
Expose the setting as UserExtensionsEnabled readwrite property in the
org.gnome.Shell.Extensions interface to allow consumers to manage
extensions purely via D-Bus.
The 'disable-user-extensions' setting is the last extension-related
bit from the org.gnome.shell GSettings schema that is not exposed
via D-Bus.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1074
This (mistakenly) now only depends on signals triggered on Wayland
sessions. Hardcoding the XIM support on X11 sessions will make input
in some clients work again.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/1690
Currently, a failure to start the Systemd unit `gsd-xsettings.target`
would be considered a failure to start Xwayland.
That means that if `gsd-xsettings.target` fails to start for whatever
reason, no X11 client can be used on Wayland.
However, XSettings is by no mean mandatory for X11 clients and many
legacy X11 clients do not implement XSettings. Those who do always have
a fallback path and therefore can still work without XSettings.
Make a failure to start the Systemd unit `gsd-xsettings.target` non
blocking for Xwayland, and just log a warning message.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1065
We ended up always showing the switch-user button on the lock screen,
as showing and hiding it with the prompt was too visually distracting.
But now that we have a fancy transition in place, we can easily extend
it to the switch-user button as well.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1029
We only call _updateSensitivity() to make elements sensitive, and
nothing ever touches the sensitivity of the switch-user button; so
just call the corresponding authPrompt method directly, which is the
only bit that has an actual effect.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1029
We do spawn gsd-xsettings, and watch its name before notifying on the
given task, so the mutter bits can proceed with X11 startup.
One notable change is that we only start gsd-xsettings, instead of the
generic gnome-session-x11-services target. We do so as we have to wait
on a dbus name to appear in order to deem the initialization done, and
making it all depend on gsd-xsettings seems tidier.
Less notably, we also use ::shutdown-xserver to shutdown the related
services. Its major benefit is that it'd allow us to ensure the olderly
shutdown of those services, but it's unused at the moment.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/836
When a window is being resized by the compositor, with Wayland the
compositor first asks the window to change its size and emits the
"size-change" signal, and then emits the "size-changed" signal after
the window acknowledges the new size. To show a fancy resize animation,
gnome-shell creates a "screenshot" of the resizing window on the
"size-change" signal, and later animates that "screenshot" to the new
window size on the "size-changed" signal.
Now if a client is not responding to our requests asking it to change
its size, we get a "size-change" signal and start showing the
window-clone, but never a "size-changed" signal, animating and hiding
the clone again. This causes a so called "ghost window" that is shown
above everything else and never disappears again.
To fix that, start showing the window clone once we get the
"size-changed" signal instead of the "size-change" signal. This makes
sure the window actually updates its size and the clone is going to be
hidden again.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/1078https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1055
Creating a new GTimeZone for the local timezone can be quite expensive if
done repeatedly. It requires an open(), mmap(), and parsing of
/etc/localtime.
This patch was provided by Florian, and I've tested it as far back as
3.28.4 to ensure that we are really reducing the number of open() calls
on the compositor thread.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1051
Signed-off-by: Christian Hergert <chergert@redhat.com>
The thumbnails actor `this._thumbnails` has already been destroyed when
calling `_destroyThumbnails()` from the `destroy` signal handler because
it is a child actor of the AppSwitcherPopup. So stop destroying the
thumbnails separately (fading them out inside a destroy handler wouldn't
make sense anyway).
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/167
The correct property for the scroll-direction with scrolling events is
`direction`, no `scroll_direction`. This fixes scrolling in the alt-tab
popup, which broke with the actorization changes.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/167
When the switcherPopup was initiated successfully, we return true,
otherwise the WindowManager will try to destroy it. Since an early
release of the keystroke will also switch to another application and
close the switcher just fine, we should return true to indicate success
here.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/167
Right now the index that gets selected on click and motion events is set
when connecting the event inside the addItem function. If items are
added or removed (for example when an application is closed by pressing
"q"), this index isn't valid anymore and has to be updated.
To fix this, use the items themselves instead of the index as arguments
for the event handlers and lookup the index of the item inside the event
handler.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/167
Set the accessible states of the switcherList items by calling a
function instead of manipulating class-internal variables from outside
the class, which is considered bad practice.
The check whether the item at `_selectedIndex` exists can also be
removed since we always select a new index after an item was removed
(i.e. an app was closed) and destroy the alt-tab switcher right away if
no more items exist (see `SwitcherPopup._itemRemovedHandler`).
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/167
Limit the minimum and maximum value to scroll to inside the box to 0 and
the upper limit, for some reason this was done right in _scrollToRight,
but not in _scrollToLeft.
This fixes the behavior of scrolling to the left: Before, scrolling one
item to the left moved the view to the first element of the list (this
can make the selected element invisible in large lists). Instead, scroll
one item to the left, just like scrolling to the right works.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/167
Make sure the index that's being scrolled to doesn't change while the
scrolling animation is running by using an argument instead of the
this._highlighed class scope variable.
This fixes wrongly shown arrows when selecting new elements faster than
the scrolling animation takes for one index. The check run to disable
the arrow might be checking against a newer index than the one at the
start of the animation which results in the arrow not getting hidden
even if no more scrolling is possible.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/167
Since this._highlighted is always set to the currently highlighted
index, there's no need to save the index to a separate variable. This
obviously depends on getting the new item highlighted as a result of the
item-entered event.
This fixes bugs in situations where the highlighted element changes
after an event that is not calling _onItemEnter, for example after
scrolling or pressing a key. In those cases the _currentItemEntered
variable wouldn't be updated and the old item couldn't be entered
anymore without entering another one before.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/167
Visually the button is just an interactive label, so having the
interactive area extend to the empty space next to the label
is surprising.
Instead, left-align the whole button rather than just the label
inside, so the clickable area corresponds to the visible one.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1046
The 'gdm' user is not going to run a media player, so there is no
point in allowing the corresponding section on the login screen.
All other sections are already disabled, so this is the only reason why
we end up with the message list instead of only showing the calendar.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2241
This reverts commit c0c027c608. Because for
some reason animating external opacity and position is still incurring
internal repaints, which disables offscreening and makes fading of
overlapping actors look wrong. `ON_IDLE` should be fixed in mutter before
it is used (in boxpointer at least) again.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/2270
If the sessionMode does not allow to show the overview, we should also
hide an already visible overview.
This fixes a bug where, if the lockscreen was shown while the overview
was visible, the Ctrl+Alt+Tab popup would allow navigating inside the
overview because the overview actor is still mapped.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1043
If a transition is reversed, the final property values will be the
same as before the transition. However this currently only works
correctly when we actually use a transition; to fix this with a
duration of 0, simply skip the set() call when the transition is
reversed.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1042
While the unread messages indicator is updated when starting a new
session because we call _onSourceAdded() on existing sources, we should
also update the do-not-disturb setting which might still be enabled.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1037
We turned both the auth prompt's cancel button and the switch user
button into icon buttons now, which means they are completely cryptic
when using a screen reader.
Just use the previously used labels as accessible names, which has the
nice side effect of lowering the impact of the string freeze break.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2210
The button is hidden on the lock screen, so it shouldn't be allowed to
activate it, be it via click or keyboard. The latter is still possible
by keynaving to the button and hitting space/enter. Fix that by making
the button unfocusable when we make it unreactive.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2210
Since commit mutter/a2a8f0cda we force the focus surface of the
meta-wayland-pointer to NULL while the pointer is hidden. This
introduced an issue with the magnifier, where we use
`set_pointer_visible` to hide the real cursor and show our own cursor at
the correct position: Because the meta-wayland-pointer is still used to
communicate with Wayland clients, the UI of the windows will not respond
to mouse movement anymore as soon as the real cursor is hidden.
To fix this, use the newly added clutter_seat_inhibit_unfocus() API to
temporarily disable unsetting the focus-surface while the magnifier is
hiding the system cursor.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/993
If we are transitioning the label from 0 to its natural height, we
must set natural-height-set again after querying the preferred height,
otherwise Clutter would skip the transition.
However when transitioning in the opposite direction, setting the
property to true can go horribly wrong:
If the actor hasn't been allocated before, it will store a fixed
natural height of 0. But as there is no fixed min-height, we can
end up with min-height > natural-height, which is a fatal error.
(This isn't an issue when *actually* setting a fixed height, as
that will set both natural and minimum height)
So instead of always setting natural-height-set to true, restore
its previous value to fix the issue.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2255
repeatCount and autoReverse don't play well with animations disabled:
They cause password entries to wiggle themselves off-screen (by ending
up with some off-scale translation-x value).
While we should handle this more gracefully in the transition helpers,
it also makes sense to handle the case directly in wiggle(): As it
uses a chain of three transitions, we would still end up with a crude
one-frame-per-transition wiggle "animation".
Instead, do no animation at all as you would expect when animations are
disabled.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2236
Now that we apply a strong blur effect to the background, it doesn't
make too much sense to use a separate lock-screen background: It will
be mostly unrecognizable anyway.
The alternative would be to turn off the blur effect if a different
background is used (or have a hidden setting for that), but that would
then imply that we must keep the contents readable without blur.
Let's avoid that rabbit hole and just re-use the regular background.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1001
To bypass offscreening in cases where continuous animation is happening.
Offscreening is slower in such cases so this reduces the render time of
animations within offscreenable actors.
On an i7-7700 this reduces the render time of boxpointers for example by
25-30%.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1025
`-slider-handle-radius` is a floating point value and even in the default
theme it's not a whole number. Regardless of the fractional part that's
still going to occupy a whole extra pixel with antialiasing. So make room
for it. Otherwise it looks clipped, which it is by the Cairo context of
its `StDrawingArea`.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1569
Unused at the moment, but add the plumbing so that default key
definitions may specify symbolic icons that will be shown instead
of the text.
This is intended to replace the use of CSS and background-image
to handle those buttons with an icon.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2214
While the gsetting is available for all who needs it, the Shell might
override it given various hueristics. Expose the decision made by the
Shell via a new property.
Intended to be used by gsd-xsettings as well as xdg-desktop-portal-gtk.
This also add a version property to the API, so that semi external
services (xdg-desktop-portal-gtk) can detect what API is expected to be
present.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/757
For reasons not yet fully understood, `Main.uiGroup.add_actor` takes around
10 milliseconds to complete.
Because of this, each `actor.opacity = 0` has a good chance of falling
on a different frame. And when it does, `_opacityChangedId` also lands
on multiple different frames each incurring a separate relayout cycle.
It is this excessive number of relayouts that causes stuttering in the
icon grid animation (#2065). But it is the slowness of `uiGroup.add_actor`
that causes the number to be excessive when it should be one.
By creating the clones and adding them to `uiGroup` early, we then enable
the existing loop starting the animation to complete within a single frame.
And by completing within a single frame all the opacity changes land within
the same frame interval, thus incurring only a single relayout instead of
many.
This issue went unnoticed until 004a5e1042 (!704), after which the slow
emissions of `notify::opacity` became a more visible performance problem.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/2065https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1002
Now that the bind constraint changes the preferred size of
the actor, a major flaw in the AppDisplay code was exposed:
the folder dialog depends on the preferred size of a parent,
and the parent depends on the preferred size of the folder
dialog.
While we know this is not actually true, we shouldn't rely
on broken behavior to achieve this result. What's interesting
is that the bind constraint used by the folder dialog is a
relic of the development phase; we now control the position
and size of the dialog with a combination of CSS, and alignment.
Remove the unnecessary bind constraint.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1027
Since the design of the notification popup changed with the theme
refactor and there are now boxes around the world-clock and weather
sections, the overlay scrollbar that is shown above them looks rather
bad. So simply hide that scrollbar, we still have the vfade effect to
indicate the container is scrollable and we also depend on that in the
new popup app-folders.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1013
Make sure the stylesheet properties of the window-chrome title are
updated before requesting the preferred width of the title to prevent
size changes of the title after we animated the width.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/58
Remove the default icon size of -1 and always set the container StBin to
a real size. This fixes an error where the "width" and "height"
properties get set to -2 (which is -1 * scaleFactor) in the `_init`
function.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1018
To make sure the GC really disposes the KeyboardController object we
need to remove all references to the object, which means we have to
disconnect signals the object connects to, too.
This also fixes a bug where keys remain pressed forever and thus also
break that key on real keyboards. It happens if the OSK gets destroyed
during an OSK-key is being held so the StButton of the key is not
released. That means the key remains pressed in the
MetaVirtualInputDevice that we are now leaking because
KeyboardController isn't garbage collected.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1015
xgettext gained some support for template strings, and no longer
fails when encountering '/' somewhere between backticks.
Unfortunately its support is still buggy as hell, and it is now
silently dropping translatable strings, yay. I hate making the
code worse, but until xgettext really gets its shit together,
the only viable way forward seems to be to not use template
strings in any files listed in POTFILES.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1014
Since quite a few strings of dialogs provided by external programs are
not updated yet and the string freeze is already in effect, make sure we
don't break those dialogs by stripping aways large parts of the
headline.
To do that, detect if the title label is larger than the available width
and if it is, switch to a smaller font-size of 13pt. This makes sure we
still show about the same number of characters in the headline as we did
in previous releases.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1012
With the old screen shield, we were simply hiding the lightboxes to show
the shield when the user became active after activating the shield but
before locking the screen (that is, when using a lock-delay).
However now that the shield is gone, we end up showing the unlock dialog
even though we are not actually locked.
We probably don't want to add back a shield-like mode (that is, a way to
raise the unlock dialog without authentication when we aren't locked),
so just deactivate the whole shield when the user becomes active again
before the lock kicks in.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2213
The design team discussed the ellipses at the end of the hint text of
our entries and, even though they are present in most mockups, it turned
out they don't like them, so remove them.
It also turned out they don't like the prefixes like "Enter" before it,
so remove those, too.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/977
With the new dialog design the descriptions of entries are now
implemented as hint-text of the StEntry. That means the colon at the end
of the descriptions no longer makes sense and should be removed.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/977
Currently separators get all the padding from regular menu items,
which is excessive for non-interactive elements.
Shuffle style classes around a bit to allow overriding the normal
padding for separators.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1004
Shift, caps-lock and friends change the capitalization of following
key presses. It is unexpected for those keys to have side-effects,
so don't switch to the prompt when they are pressed.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2215
We don't want to show a caps-lock warning when showing a non-password
entry, but we also don't want the layout to jump when changing the
label's visibility.
Achieve that by inserting an empty placeholder label that we can
show whenever the caps-lock warning is hidden.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2215
The promptBox is initially fully opaque, so showing it before the
transition can result in a brief flash before fading in.
Just remove the show() call and let the transition handle the
visibility.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2212
Usually, logging in or unlocking the session is made asynchronously,
and AuthPrompt properly manages which entry is currently visible.
External code don't rely on any specific entry to be set, since it
is AuthPrompt's responsibility to select the correct one to be shown.
However, there's one specific case where AuthPrompt must preserve
the password entry: on reset. The reset code preserved whatever
entry was currently displayed, but after fe69dacaf1, it always
changes to the username entry.
Make sure to show the password entry on reset.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/999
In the past, the session menu button was part of the auth prompt widgetry,
so we didn't have to manually hide it when showing the user list. However,
now it is part of the login screen itself.
Hide the session menu button when the user list is shown.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/999
In the common case where we only have a single unread notification
from a particular app, the count doesn't add useful information.
Reduce clutter a bit by only showing the notification count if we
have at least two.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/997
Clicking or typing to reveal the auth prompt are good options for
mouse/keyboard workflows, but awkward on touch devices. Now that
we have SwipeTracker, adding corresponding gestures support is
easy, so do just that.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/972
The current transition between clock and auth prompt uses a simple
crossfade.
"What kind of spatial model is that?!"
T.B.
Root the transition a bit more by adding translation and scale to
the animation.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/972
Hiding the Caps lock warning label changes the layout of
Auth Prompt. This is specially noticeable when logging in
with unlisted users, where we change the visibility of this
label after typing a username, and the whole user widget
moves a bit.
Change the Cap lock label's opacity instead of hiding it.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/922
Currently, when a null user is passed, we don't add any
username label. That makes the layout of user and no-user
cases inconsistent.
Add a ghost label with no opacity to mimic the username
label.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/922
Currently, AuthPrompt is connecting to its own 'next' signal
signal to react to any of the entries being activated, and do
some actions like starting the spinner and answering the PAM
question.
Refactor this code into another method, and don't connect to
our own signal.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/922
Unfortunately, the question that is displayed comes directly
from PAM. It usually is just "Password:", which comes from
pam-unix, but other questions can be set, usually with the
colons, since they are crafted with a CLI workflow in mind.
Manually drop the colons from questions asked by PAM. This
is also done by the PolKit agent, which shows how the stack
is fragile, but it's what we have for now.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/922
This is a regression from the transition to password entry. Both
entries need to be connected to the relevant signals, otherwise
username-based login won't ever work.
Connect both the text and the password entries.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/922
Currently, there is a dedicated label above the entry to
display the question text. According to the new mockups
for the lock screen, this label doesn't exist; instead,
the question is set inside the entry itself, as a hint
text.
Set the questions as hint texts of the entry, and remove
the now unused label.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/922
If username-based login flow is followed, we need a default avatar
for the userWidget. Hence, check if the user passed to userWidget
is (null) which implies a username-based login flow.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/922
Allow vertical orientation for the userWidget so that the user-avatar
can be centered and user's name can be placed below it. The plan
for 3.36 is to use this vertical userWidget layout for both lock
and login screen.
The userWidget is also used while creating the user-selection list
at the login, hence we still need to keep the horizontal layout
for userWidget in place.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/922
Since the blur sigma decides how many pixels get factored in when
blurring and setting a scale factor increases the background texture by
that factor, the sigma value should also be multiplied by the scale
factor.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/991
There is nothing else to be focused in the lock screen itself -- the
top bar is already handled elsewhere, and the dialog manages itself
now.
Remove the lock screen group from the Ctrl-Alt-Tab manager.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/872
AuthPrompt is the set of actors that contain the user avatar,
the username, and the password entry. With the removal of the
screen shield, the unlock dialog (be it UnlockDialog or the
LoginDialog) is always created, and in the case of UnlockDialog,
so is the auth prompt.
This is problematic, though, since for passwordless accounts,
the simple act of creating AuthPrompt authenticates the user,
and lifts the lock screen.
Create the AuthPrompt on demand in UnlockDialog.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/872
As per the latest lock screen mockups, critical notifications must have
a more prominent, solid color.
Add a .critical style class to critical notification bubbles, and make
them darker.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/872
Now that the screen shield is gone (at least, as it used to
be), the corresponding session mode is not necessary anymore
as well.
Remove the 'lock-screen' session mode, and the corresponding
CSS.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/872
Pretty much what the commit title says.
This gives the lock shield actor another role: instead of
being the interactive screen shield, make it the invisible
actor that prevents interacting with windows while the
unlock dialog is sliding down.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/872
Activating a dialog is slightly different from opening it; the
former is about showing the user authentication widgetry, while
the latter is about creating it and pre-allocating the necessary
resources.
Activate the screen shield dialog when necessary.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/872
The 'onPrimary' argument was being passed to dialog.open(). Turns out,
neither UnlockDialog nor LoginDialog use this parameter.
Remove the unnecessary 'onPrimary' parameter, and cleanup the related
code.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/872
The use of the core idle monitor means that focus change events
are also delayed by keyboard interaction. Since the magnifier is
already in the business of pointer tracking, it's easy enough to
fire the pointer rest timeout from here, so focus changes are
accumulated and delayed.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/984
We may get several a11y events setting the caret on the same
coordinates it previously was. Make focus tracking ignore those,
as we're jumping to the same coordinates again during eg. mouse
operation.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/984
If the crosshair is clipped so it doesn't cover the pointer cursor,
the clip rectangle is skewed towards the bottom/right. This was
made so to accomodate the default pointer, but the unevenness stays
on other pointer cursors, and it makes the crosshair look odd on
short crosshair length.
Make all lines clip to an even distance from the center instead.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/984
It is somewhat unexpected that crosshair color and pointer cursor colors
remain the same across changes in color inversion settings, and may lead
to contrast issues. Apply the effect on the common container, so it
applies to these all.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/984
If the icon proper has opacity of zero then that's probably because a
clone of it is animating. So avoid animating the source actor too.
And if there's any other reason for the opacity being zero, still don't
animate it because we can't see it :)
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/2167
So as to guarantee the unmapped state sticks and doesn't get toggled
back to mapped before we return.
Being in a mapped state when `FolderIcon.vfunc_unmap()` returned was
causing an assertion failure in `clutter_actor_set_mapped` and crashed
the shell.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/2170
The portal helper is rather sensitive because potentially-hostile Wi-Fi
networks can decide to launch it whenever they want (by blocking the
user's connection to the nmcheck domain) and load whatever web content
they want into it. So having this unsandboxed is really extraordinarily
risky. Previously it was a risk we had to accept, because WebKit did not
have a web process sandbox, but now it does. So let's bubblewrap all the
things!
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/983
Commit 147a743d8d moved the suspend and power-off actions into
the submenu that contains the log-out and switch-user actions,
but did not update the submenu visibility logic to account for
the additional actions.
As a result, the submenu is hidden when log-out and switch-user
are unavailable (like on the login screen), even if suspend and
power-off are enabled.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2169
While gnome-shell will now check for extension updates, the checks
are performed infrequently. Opening the Extensions app implies that
the user's current focus is on extensions, so it is an appropriate
time to schedule another updates check.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1968
Now that we can download, apply and display extension updates, it is time
to actually check for updates. Schedule an update check right on startup,
then every 24 hours.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1968
Now that we have support for extension updates in the shell, we
need some place to display the updates to the user.
As we are establishing the Extensions app as the primary way for
managing extensions, it's a natural place for that functionality.
Show which extensions have updates available, and offer a log out
button (so gnome-shell can apply the updates when logging back in).
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1968
Until now, it didn't matter whether an extension was installed in the
user's home or system-wide. However with support for uninstallation,
there is now a significant different, as that action is only available
for user extensions.
Account for that by separating extensions by type, so that users don't
have to second-guess which extensions can be fully-managed and which
appear as part of the system.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1968
The newly added expander gives us a place where we can display
more details without cluttering the interface.
Take advantage of that by including the extension website, version
and author.
(Author is in the mockups, but will not actually be shown until
the extensions website is changed to include it in its metadata;
however best to have UI and string in place for the freezes)
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1968
The description can be useful information, but also increases the
visual complexity of the extensions list. Move it into a hidden
details area that can be expanded, which unclutters the interface
while keeping the information readily available.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1968
The current fixed two-line label requires a custom widget, which
make moving to a widget template harder.
As the description will soon move elsewhere anyway, just go back
to a single line with a standard label for now.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1968
Extensions can have a major impact on stability and performance. Now that
the tool will become the main way for users to manage their extensions, it
is an appropriate place to warn the user of that risk.
Add a small info popover to the headerbar to display that warning, together
with the previously removed hint of where to go for finding new extensions.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1968
Currently when the extensions list is scrolled, it is possible to
keynav out of view, as the scrolling doesn't follow the key focus.
Hook up the adjustment to fix that.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1968
Currently the main window is a plain Gtk.ApplicationWindow that is
built and managed from within the application.
As the application becomes more complex, it makes sense to decouple
the two and handle the window from a separate ExtensionsWindow class.
Not least this is a prerequisite of using a widget template for the
window.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1968
GNOME Software will remove its extension support, so we should stop
referencing it in addition to extensions.gnome.org.
In fact, the placeholder is not the best place to hint at where new
extensions can be found, as the user will never see it in case the
distribution includes pre-installed extensions.
So remove the hint altogether, we will add it back in a more prominent
place later.
With the whole placeholder now being much lighter, we can stop dimming
the remaining elements.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1968
If all password entries in dialogs are hidden, there is either an entry
that has visible characters or no entry at all. That means we don't have
to show the caps lock warning at all, so hide it.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/942
Since the headlines of the dialogs now use a much larger font, the
strings need to be shorter so they won't be ellipsized. So use a shorter
strings for those titles and also adjust the title-strings of the
notifications sent by the NetworkAgent to be consistent.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/942
Since the wiggle effect will be used by the redesigned prompt-dialogs
and we always want to use the same parameters, move those as defaults
for the wiggle function to the util.js file.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/942
Since the caps-lock warning adds a lot of spacing to dialogs and the
lock screen, hide it by default and only show it when necessary. To make
the transition smooth instead of just showing the label, animate it in
using the height and opacity.
Also add some bottom padding to the label so we can show or hide that
padding, too.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/952
The caps-lock warning is more related to entries than dialogs and is
also used in gdm, which is not realated to dialogs at all. Rename the
css class to caps-lock-warning-label and move it to the entry
stylesheet.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/952
The Animation class inherits from St.Bin and manages the scale factor
in the image loading, but the widget size doesn't change and doesn't
depend on the scale factor so when the scale factor is different
from 1 the widget size doesn't match the image size.
This patch resizes the Animation widget using the scale factor so the
widget will match the animation images sizes.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1746
Now that we have a way to check for updates and download them, we
should actually apply them as well. Do this on startup before any
extensions are initialized, to make sure we don't run into any
conflicts with a previously loaded version.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/945
While it is possible that an extension has a newer version available
than the previously downloaded update, it's more likely that we end up
downloading the same archive again. That would be a bit silly despite
the usually small size, so we can either use the metadata from the
update, or exclude the extension from the check.
The latter is much easier, so let's go with that for now.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/945
Currently the method installs updates instead of merely checking for
them (or it would do, if it actually worked).
This is not just surprising considering the method name, the whole idea
of live updates is problematic and will not work properly more often
than not:
- imports are cached, so any local modules will stay at their
original version until a shell restart
- GTypes cannot be unregistered
So change the method to only download available updates, and set the
extensions' hasUpdate state accordingly.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/945
The current support for extension updates is half-baked at best.
We are about to change that, and implement offline updates similar
to gnome-software.
As a first step, add a hasUpdate property to the extension state
which will communicate available updates.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/945
Since a11f417cd0, both drag and scroll
gestures are added to Main.layoutManager.overviewGroup actor, while
previously drag gesture was added to Main.overview._backgroundGroup
instead. Since we cannot use 2 different actors for dragging and scrolling
anymore. just disable the swipe tracker while dragging a window.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2151
Since the orientation lock menu entry is a proper menu entry instead of
a icon-only button now, we also show a description-text for that entry,
so update this text depending on whether orientation is locked or not to
better reflect what clicking the menu entry will do.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/964
Since we don't really know what the buttons we're adding to the dialogs
are about, we can't configure a button to "be clicked" when the escape
key is pressed. So add a separate escape key handler to fix that, return
-1 and abort the request.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/961
When updating the buttons of the mount dialogs, compare the new buttons
to the old ones and only create new buttons in case something changed.
This makes sure key focus isn't reset or lost unnecessarily while a
dialog is opened.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/961
Since there is a generic layout for dialogs like that now, use it. Also
remove the functionality of focussing a window when clicking a list
item, it's not discoverable at all and pretty unexpected.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/961
On Wayland, the display server is the Wayland compositor, i.e.
`gnome-shell` itself.
As a result, we cannot spawn `gnome-shell-perf-helper` before
`gnome-shell` is started, as `gnome-shell-perf-helper` needs to connect
to the display server.
So, instead of spawning `gnome-shell-perf-helper` from the perf tool,
start it from `gnome-shell` itself.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/941
When do-not-disturb is enabled, non-critical notifications will not
be shown as banners. It therefore makes sense to indicate that state
to the user, so they don't accidentally miss notifications.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/239
Currently the indicator pad requests a size of 0x0 if the corresponding
indicator is hidden. Right now this is enough to balance out the indicator,
but it won't be when we add spacing to the parent container.
Properly hide the pad with the indicator to avoid that issue.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/239
We've had the ability to temporarily disable notification banners
all the way back to 3.0, but we stopped exposing it in the UI with
the 3.16 notification redesign. With the message list being more
concise nowadays and the "Clear" button reduced to a single icon,
we now have space for a "Do Not Disturb" switch again.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/239
We try to make the OSK 1/3rd as big as the monitor. On landscape
layouts we usually get away with it as there's plenty of horizontal
space to enlarge the OSK while keeping the OSK aspect ratio.
In portrait layout, the horizontal space is a lot more scarce so
it means we'll still have plenty of space after making the OSK as
wide as it can possibly be, which will look as odd blank space in
the OSK panel.
In order to fix this, let the OSK panel height be less than 1/3rd
the monitor size if we are dealing with portrait layouts.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/2132
It will happen before next map anyway, and most notably at times
actor sizes produce correct results.
Fixes oddities in emoji pager visibility after showing the emoji
panel, moving to another page, and hiding the OSK with the downward
arrow button. The next time the emoji panel would be shown, panels
had a chance to remain invisible.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/943
It is already scheduled to be set on first map. Doing so here triggers
size and theme node checks the actor tree is not ready for, as the
toplevel actor is not yet attached to the stage.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/943
This functionality always suffered from discoveribility
problems, and now that the folder dialog can rename the
app folders, there's just no reason to keep it.
Remove the rename popup.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/896
Now that the folder dialog handles the adaptToSize workaround,
there is no need to propagate the call throughout the class
hierarchy.
Remove the propagating calls to adaptToSize, and all the satellite
code.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/896
Now the the folder popup behaves like a dialog, it must be
above the app grid, and not be affected by the scroll view
translation.
Add the folder popup to the AllView itself, instead of the
internal Shell.Stack that is inside the scroll view.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/896
Make the AppFolderPopup behave much more like a dialog than a
popup itself. To do that, remove the BoxPointer and replace it
by a StBoxLayout. The dialog is is also bind-constrained to the
view selector.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/896
Since the overview search results now have a dark background layer, we
can brighten the background image a bit again. As a factor we use 0.5,
since that ensures the texts in the IconGrid are still readable and the
background image is visible, too.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/2133
If a new SwitcherPopup is created and there are no windows or apps to
switch through found, instead of returning from _init(), still
initialize the SwitcherPopup and let the check in SwitcherPopup.show()
return false to terminate the popup.
In both cases, with or without the return statements,
WindowManager._startSwitcher() will call SwicherPopup.destroy(), which
will try to disconnect signal handlers, destroy actors etc. Now if the
constructor can't finish creating the popup, some of the functions
called from _onDestroy() will fail and throw errors.
One of those cases is when window-switcher is limited to the current
workspace, and a WindowCyclerPopup is initiated on an empty workspace.
Because this._highlight hasn't been created, _onDestroy() will fail when
trying to destroy the actor of this._highlight.
Also, the actor of this._switcherList will not get destroyed in case
show() returns because this._items is empty. For example, this will
happen when a new AppSwitcherPopup is initialized with at least 1
running app, but 0 windows on the active workspace.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/168
When pressing the menu key to show the popupMenu inside a ShellEntry,
the menu is currently aligned with the end of the entered text, this
causes a bug in case the text is overflowing the width of the entry: The
menu will be shown outside of the entry field, because it's aligned with
the (invisible) end of the text.
Fix that by simply aligning the popup menu with the cursor of the entry,
which is a behavior that makes sense when pressing the menu-key anyway.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/934
`MessageDialogContent.messageBox` is not really needed and was only
needed to show icons, which is now no longer supported. The styling can
also be done using other CSS classes and this makes it a bit more
straightforward to add actors to the MessageDialogContent.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/886
Since MessageDialogContent.messageBox is going to be removed in a
subsequent commit, move the parts where it's used out of messageBox and
into the contentLayout instead. This will introduce wrong spacings in
some dialogs, which we're going to fix when implementing the redesigned
individual dialogs.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/886
Since the last commit we set the gicon property of StIcon to NULL if an
empty string was given when setting the icon name, this means
`st_icon_get_icon_name()` will return NULL instead of an empty string.
When `getIndicatorIcon()` returns an empty string, the icon_name
property will now be set to NULL, so compare it to NULL here.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/888
Animating the icon spring using the `translation-x/y` properties instead
of the `x/y` properties avoids relayouts. There are still other non-icon
actors moving, but it's a big improvement.
Before: 595 relayouts per spring
After: 94 relayouts per spring
Reducing relayouts reduces reallocation, which reduces CPU-intensive
JavaScript execution.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/926
String.prototype.substr() doesn't support a negative length value
(to subtract from the full length), so we end up with a filename
of '' when hitting that code paths (a relative filename with '.png'
suffix).
Fix this by switching to String.prototype.replace() instead.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2091
Replace existing panning and touchpad scrolling by SwipeTracker.
Since SwipeTracker only references one actor, redirect scroll events
from page indicators to the main scroll view.
Change programmatic scroll animation to use easeOutCubic interpolator
to match the gesture.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/826
Add a unified swipe tracker supporting dragging, four-finger swipe on both
touchscreen and touchpad, and touchpad scrolling.
The shared logic is largely same as the one in WebKit and libhandy.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/826
Commit 24e631ffe2 changed the shield animation to use translation
instead of position.
However once the shield is raised, only an animation will lower it
again, which means the shield is missing when it's supposed to be
shown without animation (for example after an idle blank).
Fix this by resetting the translation-y property in that case.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/927
Together with the forecast icon, the temperature label is the most
important information in the weather section. To emphasize it more,
reduce its space requirement by removing the temperature unit, then
make the text bold.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1143
Since commit 90a08ba0b6, we only open a network secret dialog immediately
in response to user action, and show a notification otherwise.
While for the actual request VPNs are handled separately from other connections,
this isn't true when we show the notification - we need to handle 'vpn' together
with the other types there, or we fall through to the default 'invalid type'
exception.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2008
Now that both ThumbnailsBox and WorkspacesDisplay use single adjustments for
controlling indicator and scrolling, create the adjustment in OverviewControls
and pass it to both objects, effectively syncing indicator to scrolling.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/821
Instead of having a scroll adjustment in each WorkspacesView, and using the
one from primary screen in WorkspacesDisplay, have just one adjustment in
WorkspacesDisplay, and sync the changes between WorkspacesView.
This will allow to share the adjustment between WorkspacesDisplay and
ThumbnailsBox in the next commits.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/821
Instead of using the 'y', which queues a full relayout and
thus forces effects to be reapplied, use the 'translation_y'
property, that doesn't force relayouts and allows a future
blur effect to actually use the cached framebuffers a lot more.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/864
In an earlier iteration of the ease patch set, animatable properties
and easing parameters were different arguments.
This wasn't the case in the final version, so remove the left-overs.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/917
We don't want the icon to fill extra space, so set the alignment
accordingly. Otherwise we get an unexpected result when adding
a background just to the icon part (as far as I can tell: just
system-action-icon).
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/909
The screenshot code has a fair bit of nested callbacks, which means
that it is a good use case for async functions and Promises.
Most code uses GIO's async pattern, which means it can be easily turned
into promises with Gio._promisify(); first handle the couple of cases
that need custom code though, starting with SelectArea.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/903
Some GrabHelper uses are in the form:
doPreGrabStuff();
this._grabHelper.grab({
onUngrab: () => {
undoPreGrabStuff();
},
});
A promise-based variant allows to write this more cleanly as:
doPreGrabStuff();
await this._grabHelper.grabAsync();
undoPreGrabStuff();
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/903
We currently handle the case where the indicator itself is disabled
(read: hidden), but not when the entire top bar is invisible (for
instance when the primary monitor is in fullscreen state).
It is odd to pop up a top bar menu without the top bar, so check for
the indicator's mapped- instead of visible state.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2002
Use the new StPasswordEntry for password entry fields
and remove all direct handling of clutter text of the entry
via clutter_text_set_password_char to show/hide the password
text. StPasswordEntry will provides a peek-password-icon which
will allow to show/hide the password present in the field to
the user in subsequent commits.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/619
shellEntry should not need to query the clutter-text directly
in order to know if the entry is for passport-input purpose.
shellEntry can easily determine a password-entry by querying
if it is an instance of StPasswordEntry and use it's API
whereever relevant.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/619
This is necessary to make DnD operations work from tablet devices on
wayland, as it's not the same onscreen pointer sprite than mice. Fixes
window DnD in the overview on tablet devices, no longer having them stick
to the wrong pointer.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/897
Since commit 87e60ed97843, geoclue no longer pretends that authorization
is useful for system-installed apps (as they can easily lie about their
ID). Unfortunately this broke our auto-location support in case Weather
is installed non-sandboxed, as we are waiting for an authorization that
will never happen.
Unbreak it by only requiring authorization when installed as Flatpak.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1823
Just like switcher popups, popup menus don't play well together with
system modals, and generally have a lower priority. So just like
switcher popups, close popup menus when a system modal dialog pops
up.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1536
As system modal dialogs may open without user interaction (for instance
polkit or network agent requests), it is possible for them to pop up
while the app/window switcher is up.
The current result of having both up simultaneously is clearly broken,
so we can either dismiss the popup or prevent the modal dialog from
opening. Assume that the dialog indicates a more important action and
should therefore take precedence, so go with the former.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1536
Since both the `_items` object and the `_allItems` array include the
same items, the difference between those variables seems unclear. The
real difference between them (except the different data type) is that
`_allItems` is ordered in the same order as the visible grid, so rename
`_allItems` to `_orderedItems` which makes that more obvious.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/799
We have three interactions with an extension's prefs module:
- we import the module
- we call its init() hook
- we call its buildPrefsWidget() hook
The first two are one-time actions where we expect most getCurrentExtension()
calls (local imports, initTranslations() etc.).
However it's still possible that the extension will use the utility function
in buildPrefsWidget() as well, either directly or via other functions like
getSettings(): Make sure getCurrentExtension() returns the correct extension
in that case, not the last one whose preferences were initialized.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/873
The icon grid currently sorts icons by their names. When creating new
folders, the folder may end up being in a different page, and that's
confusing since we don't actually move to where the new folder is.
Move the icon grid to the newly created folder.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/883
We want extended keys to have the same size as their parent key,
but this is currently broken and the keys end up with their
parent key's preferred size (which is smaller than its allocated
size).
This is due to the way ClutterActor's width/height properties work,
which only return the "real" (i.e. allocated) size when the allocation
is valid, and fall back to the preferred size otherwise.
As changing an StWidget's hover state involves adding or removing
the `:hover` pseudo class, this is currently always the case.
Creating the extended keys first means the keyButton's allocation
is probably valid, so do that.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1976
Mutter and Clutter was changed to pass around the current target
framebuffer via the paint context instead of via the deprecated Cogl
framebuffer stack.
The framebuffer stack has also been removed from Cogl so change to use
the one in the paint context instead.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/827
While still leaving them unused, pass around ClutterPaintContext and
ClutterPickContext when painting and picking.
The reason for splitting this change up in two is to make it possible to
bisect easier in between the API change and the change to using the
framebuffer passed around with the temporary contexts.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/827
When commit c6cea277e replaced Shell.GenericContainer, the check
whether the required width exceeds the avilable width was changed
from using the minimum widths of items to the natural width of the
scroll view.
That doesn't work correctly, as the *natural* width may well exceed
the actually used width: SwitcherList bases its width request on
children's minimum sizes to force labels to ellipsize.
Fix this by using the minimum width of the scroll view's child instead.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1834
It is true that delete is a javascript keyword, but that doesn't
prevent it from being used as method name - there are event built-in
types like Map or Set with delete() methods!
So if that hack was ever needed, this hasn't been the case for years
now; just removed the hack now.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/862
When the extension system is loaded, create the
gnome-shell-disable-extensions file in the users runtime directory. This
file is automatically removed 60s later. The sole purpose of this file
is to be consumed by the systemd units. If the file exists, the systemd
units will disable extensions when the gnome-shell fails.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/858
The whitelist is a list of well-known D-Bus names, which we then search
for the unique name we get from the method invocation - unsuccesfully.
Fix this by watching the bus for any name in the whitelist in order
to maintain a map from wel-known to unique name that we can use for
matching.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1916
Since the notification message close button had no border, or mouse
over effect, there was no way to determine whether the mouse cursor
were over the button.
Improve this by adding a message-close-button class for the close
button, and a styling for its hovered state, based on media control
button styling.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/855
Currently when dragging an icon to the space above or below the appGrid
to switch pages, we do so very quickly without checking when the last
page-switch happened. This makes it hard to move icons to pages which
are not the first or the last one, since the other pages are skipped
very quickly.
To fix this, add a timeout of 1 second that blocks switching pages after
a page-switch using drag overshoot occured.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1693
We currently always switch app pages when a dragged app icon
moves outside the grid boundaries, regardless of any previous
page switches. This makes it too easy to switch multiple pages
accidentally, so add a small threshold that the icon has to
move back towards the grid before allowing another page switch.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1693
There's no need for a `inhibitEventBlocker` interface. Since we connect
to "open-state-changed" of our folders in the AllView anyway, we can
just make the event blocker visible while a folder is opened, and hide
the event blocker during DnD.
This allows keeping the eventBlocker reactive at all times and fixes an
issue where DnD to create a new folder is impossible if no folders are
present because the eventBlocker would not get inhibited.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1652
Emitting ::drag-end after changing the slider value via arrow keys
was a cheap way to make the sound feedback work for keyboard input.
But now that the volume indicator plays the sound on ::value-changed
as well, we can stop doing that - after all, key presses aren't drags.
Besides that, this will make the limiting of feedback to actual volume
changes from the previous commit work for key events as well.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/53
gnome-settings-daemon doesn't play the volume change sound when
the volume stayed the same (that is, it is already at its maximum
or minimum). This looks like the right thing to do, so copy its
behavior.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/53
Commit 8d4855f100 accidentally removed the volume change feedback
for scroll events. Add it back to be consistent again with moving
the slider via arrow keys, slider drags/clicks and gsd's media keys
handling.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/53
While those should be concise enough to fit, they may not where
temperatures drop into double-digit negatives. It seems better
to accept some awkward horizontal scrolling in that case than
shorten relevant information.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1926
Commit b779f6f728 added a check to filter out invalid weather forecasts.
However the check is currently done when creating UI for the forecasts,
which means we end up with fewer forecasts than we could display if any
forecasts are invalid.
We can avoid that issue by checking the validity while collecting the
forecasts, so do that instead.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1927
We currently always start with the current weather info, then append
forecasts. This is slightly confusing, as the only hint that the
first item is special is the past (and potentially "odd") time.
Stop doing that and base all items on forecasts.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1927
As we get closer to midnight, we show fewer forecasts than we could
fit, or none at all. It makes more sense to continue the forecasts
into the wee hours in that case, so only exclude past forecasts,
but not ones from following days.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1927
Weather stations can have unwieldy long names, which don't fit the
limited space we have available. City names are usually more suitable,
so use the name of the nearest city instead if possible.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1927
In case of a very long location name, the label may take up all
available space. Make sure there is at least some spacing between
header and location in that case.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1927
The two labels use different font sizes, so they don't align properly.
Unfortunately we don't have BASELINE alignment in Clutter, but at least
END comes closer than the default FILL.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1927
Commit c899453800 lifted the requirement of switcher keybindings
to contain a modifier, however it is currently only possible to
finish it by letting it time out.
Improve that by also accepting space/enter key presses to confirm the
selection immediately.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1883
The noModsTimeout obviously finishes inside a timeout callback, which
means `global.get_current_time()` might return Clutter.CURRENT_TIME (ie.
0) when called inside it, because it's not called while handling an
event. This means when switching apps or activating a window, the
timestamp passed to `activate_window` may be 0, which is the reason why
the altTab switcher is currently broken when using modifier-less
keybindings.
Fix that by using `meta_display_get_current_time_roundtrip`, which
always return a valid timestamp, instead of
`shell_global_get_current_time`.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/847
Remove setCurrentPage() function, introduce setCurrentPosition() instead,
which allows to have fractional positions.
Make inactive dots smaller, filled and partially transparent, as opposed to
larger and fully opaque active dot. Make dots smaller overall, remove
borders. Interpolate each dot between active and inactive state based on
scroll position.
Make it impossible to "uncheck" the active dot.
Thanks Florian Müllner for parts of the code.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1932https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/843
We slightly delay showing the switcher popup to avoid flashing it
briefly in the common case of quickly switching back-and-forth
between two windows.
However some users perceive this delay as slowness. Address this by
showing the popup immediately when another key press is consumed
(that is, a key like Tab is pressed).
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1928
Since the mpris implementation of the notification tray supports showing
multiple notification (one for each player), it doesn't make sense to
have only one global property to store the message, since that only
allows referencing one message at a time.
Instead, handle the MediaMessages completely inside the scope of
`_addPlayer()`, this should allow showing more than one message again,
which broke with commit 4dc44304df [1].
[1] https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/791https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/833
Because the message actor could also be undefined or a already
deallocated ClutterActor, we sometimes fail to show the error message
and get an error from Gjs instead.
So make sure we always log the proper error message and just leave out
the actor.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/833
It may happen that the app icon is destroyed with a drag
monitor still around, in which case, a load of warnings
will be shown.
Make sure to remove any pending drag monitor on destroy.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/841
When removing the last icon of a folder, FolderView first removes
the folder from org.gnome.desktop.app-folders.folder-children, then
proceeds to reset all its keys, which removes the relocatable schema.
That order of operations turns out to be problematic. Removing the
folder from 'folder-children' destroys the folder icon, which in turn
destroys the folder view, which throws a load of warnings in the
journal.
Fix that by removing the folder after resetting the schema keys. In
fact, what we're doing here is not using 'this' anymore.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/841
The variable that holds the list of application icons is
called 'newApps', but that technically was never true,
since we only create new app icons when necessary.
Rename it to 'appIcons'.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/841
The views (AllView and FrequentView) build a list of all applications
they contain. BaseView then diffs between what's currently added, and
what needs to be added, and removed.
This approach has a problem though: creating an AppIcon or a FolderIcon
connects to various signals, and we confuse the garbage collector.
When building the list of applications, instead of always creating new
icons, try to use already existing icons first.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1610
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1694
GWeather.Info.get_value_update() may indicate that the forecast is not
valid, or it may return a timestamp of 0 to indicate the information has
never been updated. In both of these cases, skip creating a widget for
it, as the information will not be accurate.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/835
If the clock is set to 12h, the AM/PM in the weather forecast times
should be clear from the context, because they are the immediately
following hours. This makes it less likely that the times will be
ellipsized (in which case the AM/PM wouldn't be shown anyway.)
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/835
While we support a reasonable list of layouts nowadays, we don't
include many variants like `fr+oss`. Instead of directly falling
back to the `us` layout, try stripping the variant first, as the
base layout is likely closer to the expectation than `us`.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1907
When cancelling the PolkitAgent session before disconnecting the signal
handlers, we receive a "completed" signal where `gained_authorization`
is set to FALSE, which means we show an error message inside
`_onSessionCompleted()`.
This in turn means we show an error message every time we cancel a
session. In practice this wasn't really relevant so far since we only
destroyed the session when an actual error occurred before. Now that the
dialog supports empty passwords, we also call `_destroySession()` when
the user changes and no longer has a password set, and in this case we
want to cancel the current session without showing an error message.
So to fix this, disconnect the signal handlers before cancelling the
session, which makes sure we don't receive the last "completed" signal
in case we cancelled the session ourselves. This change also allows
removing `this._wasDismissed`.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/829
When a user has no password and a polkit authentication is started,
instead of blindly initiating the admin session, show the regular
"Authentication Requested" dialog (but without the password entry). This
makes sure that the user's admin session is only effectively started
after the user chooses to proceed with the authentication, which
provides an extra confirmation step that can be vital for critical
tasks.
To do this, we show the dialog inside `_onUserChanged()` right after the
dialog was created instead of calling `performAuthentication()` from
`_onInitiate()`. The bug mentioned in `_onInitiate()` is no longer an
issue since we show the dialog in all cases now anyway.
Ideally we should use a different wording than "authentication" when the
user has no password set, and use "confirmation" instead. However polkit
already sends the requests with such messages (e.g. "Authentication is
required to configure software repositories"), and it's important to
show those to the user, so this patch keeps the regular wording.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/829
Since `_destroySession()` is not only called before we try to initiate a
new authentication session with Polkit, but also when the dialog is
closed, it's currently possible that key focus is grabbed by the close
button after the dialog was dismissed and hidden. This is causing a bug
where after dismissing one of multiple queued dialogs, key focus goes
away and keyboard navigation with the new dialog is impossible.
Fix this by only resetting the UI of the dialog if the dialog is still
opened/visible at that point.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/828
Just as with c35b4cede5, there's no
default vfunc implemented by any parent which causes gjs to crash when
trying to call it.
So return EVENT_STOP if the key press successfully toggled the button,
and EVENT_PROPAGATE otherwise.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/830
Modifying variables from an outer scope in functions created in a loop
is considered problematic by eslint, because the variable value in the
resulting closure is often not what the coder intended.
In this particular case however, the scoping is correct, so add a comment
to disable the rule locally.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/818
The FolderView class is responsible for creating the 4-item
grid of the folder icon, with the preview of the first four
apps inside the folder.
However, with the deprecation of StAlign as child properties,
the folder icon stopped being horizontally centralized.
Center the folder icon horizontally again.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/817
Since ES5, trailing commas in arrays and object literals are valid.
We generally haven't used them so far, but they are actually a good
idea, as they make additions and removals in diffs much cleaner.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/805
ES6 allows to omit property names where they match the name of the
assigned variable, which makes code less redunant and thus cleaner.
We will soon enforce that in our eslint rules, so make sure we use
the shorthand wherever possible.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/805
If an else block only contains an if statement, the two can be
combined into an if-else block, which cuts down on indentation
and usually helps legibility.
There are exceptions (for instance where the outer if and else
blocks are mirrored), but where it makes sense, change the code
to avoid lonely ifs.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/805
Nesting functions can be helpful for private helper functions, but
here they are accessing some variables from the outer scope and
shadowing others. Split them out to avoid any ambiguity.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/805
The event blocker in AllView is responsible for stealing click events
from the icon grid and closing the folder popup. The event blocker is
kept unreactive when no folder popup is visible, and it's made reactive
as a response to the 'open-state-changed' signal.
Using this signal, though, is problematic. When opening an app folder,
the icon grid first opens space for the folder to fit in; during this
period, it's possible to click on another folder icon, and break the
icon grid state.
Make sure the event blocker is reactive immediately after clicking on
a folder icon.
Related: https://gitlab.gnome.org/GNOME/gnome-shell/issues/1470https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/816
Objects implementing EventSource should have some mandatory methods and
properties, we can ensure this by defining an EventSourceBase abstract
class.
So inherit EmptyEventSource and DBusEventSource from it making sure that
they implement all the needed methods, using native properties and
replacing the 'notify::*' fake signal emissions with proper object
notifications.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/563
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
