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