meta_later_add() is modelled after g_idle_add() and friends, and
the handler's boolean return value determines whether it should
be scheduled again or removed. There are some places where we omit
the return value, add them (although the implicit return value of
"undefined" already gives us the intended result).
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/637
The startup/busy indication in the app menu was left out of commit
22e21ad7d1 because it doesn't use a hard-coded image, but as the
image in the CSS is actually the same used by the spinner class,
drop the "custom" styling and use the regular spinner.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/636
Trying to disable an extension that is enabled by the session mode
currently has no effect, which is clearly confusing. We could update
the various extension UIs to reflect that via sensitivity, but being
unable to configure extensions based on which session the user picked
at login isn't obvious either.
So instead, add a 'disabled-extensions' gsettings key to list extensions
that should not be enabled which takes precedence over 'enabled-extensions'
and can be used to disable session mode extensions.
https://bugzilla.gnome.org/show_bug.cgi?id=789852
Now that extension loading and the extensions map are no longer shared
between the gnome-shell and gnome-shell-extension-prefs processes, we
can move both into the ExtensionManager which makes much more sense
conceptually.
https://bugzilla.gnome.org/show_bug.cgi?id=789852
By direclty using the underlying GSetting, whether or not an extension
appears as enabled or disabled currently depends only on whether it is
included in the 'enabled-extensions' list or not.
However this doesn't necessarily reflect the real extension state, as an
extension may be in error state, or enabled via the session mode.
Switch to the extensions D-Bus API to ensure that the list of extensions
and each extension's state correctly reflects the state in gnome-shell.
https://bugzilla.gnome.org/show_bug.cgi?id=789852
Extensions are used to calling the getCurrentExtension() utility function,
both from the extension itself and from its preferences. For the latter,
that relies on the extensions map in ExtensionUtils being populated from
the separated extension-prefs process just like from gnome-shell.
This won't be the case anymore when we switch to the extensions D-Bus API,
but as we know which extension we are showing the prefs dialog for, we
can patch in a simple replacement that gives extensions the expected API.
https://bugzilla.gnome.org/show_bug.cgi?id=789852
Each row represents an extension, so it makes sense to associate the
rows with the actual extensions instead of linking rows and extensions
by looking up the UUID in the external extensions map in ExtensionUtils.
This will also make it much easier to stop using the shared extension
loading / map in favor of the extension D-Bus API.
https://bugzilla.gnome.org/show_bug.cgi?id=789852
Whether or not an extension can be enabled/disabled depends on various
factors: Whether the extension is in error state, whether user extensions
are disabled and whether the underlying GSettings keys are writable.
This is complex enough to share the logic, so add it to the extension
properties that are exposed over D-Bus.
https://bugzilla.gnome.org/show_bug.cgi?id=789852
The existing 'ExtensionStatusChanged' signal has a fixed set of parameters,
which means we cannot add additional state without an API break. Deprecate
it in favor of a new 'ExtensionStateChanged' signal which addresses this
issue by taking the full serialized extension as parameter.
https://bugzilla.gnome.org/show_bug.cgi?id=789852
Serializing an extension for sending over D-Bus is currently done by the
appropriate D-Bus method implementations. Split out the code as utility
function and add a corresponding deserialization function, which we will
soon use when consuming the D-Bus extension API from the extension-prefs
tool.
https://bugzilla.gnome.org/show_bug.cgi?id=789852
Extensions are currently enabled or disabled by directly changing the
list in the 'enabled-extensions' GSettings key. As we will soon add
an overriding 'disabled-extensions' key as well, it makes sense to
offer explicit API for enabling/disabling to avoid duplicating the
logic.
For the corresponding D-Bus API, the methods were even mentioned in
the GSettings schema, albeit unimplemented until now.
https://bugzilla.gnome.org/show_bug.cgi?id=789852
While public methods to enable/disable extensions make sense for an
extension manager, the existing ones are only used internally. Make
them private and rename them, so that we can re-use the current
names for more useful public methods.
https://bugzilla.gnome.org/show_bug.cgi?id=789852
The extension system started out as a set of simple functions, but
gained more state later, and even some hacks to emit signals without
having an object to emit them on.
There is no good reason for that weirdness, so rather than imitating an
object, wrap the existing system into a real ExtensionManager object.
https://bugzilla.gnome.org/show_bug.cgi?id=789852
It makes sense to keep extension-related enums in the same module instead
of spreading them between ExtensionSystem and ExtensionUtils.
More importantly, this will make the type available to the extensions-prefs
tool (which runs in a different process and therefore only has access to
a limited set of modules).
https://bugzilla.gnome.org/show_bug.cgi?id=789852
Commit bd18313d12 changed to a new naming scheme for battery icons,
and used to old icon names as fallback-icon-name for compatibility
with older/other icon themes.
However that fallback code isn't working correctly, as GThemedIcon's
default fallbacks will transform a name of `battery-level-90-symbolic`
to a list of names:
- `battery-level-90-symbolic`
- `battery-level-symbolic`
- `battery-symbolic`
The last one frequently exists, so instead of the intended fallback,
we end up with a generic battery icon.
Address this by specifying the icon as GIcon instead of an icon-name,
where we have more control over how the icon is resolved.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1442
Just as we did for the workspace switcher popup, support workspaces
being laid out in a single row in the window picker.
Note that this takes care of the various workspace switch actions in
the overview (scrolling, panning, touch(pad) gestures) as well as the
switch animation, but not of the overview's workspace switcher component.
There are currently no plans to support other layouts there, as the
component is inherently vertical (in fact, it was the whole reason for
switching the layout in the first place).
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/575
While mutter supports a variety of different grid layouts (n columns/rows,
growing vertically or horizontally from any of the four corners), we
hardcode a fixed vertical layout of a single column.
Now that mutter exposes the actual layout to us, add support for a more
traditional horizontal layout as well.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/575
Extension preferences Application class is just a container for a GtkApplication
so instead of using composition we can inherit from the base GObject class.
Also replace signal connections with vfunc's.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/631
In some cases the style-changed signal hasn't been emitted when
_computeLayout() is called, resulting in the use of the default spacing
and item size values for the calculations.
One case where this happens is when starting a search. Right after the
initialization of GridSearchResults, _computeLayout() is called from
_getMaxDisplayedResults() and the style-changed signal hasn't been
emitted yet. The computed layout will be wrong and the maximum
number of results will also be wrong.
To prevent this from happening, make sure the style has been updated
before doing the calculations in _computeLayout().
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/110
The calculation of how many results can be shown in GridSearchResults is
broken: The width of the parent container (resultsView.actor) we're
using as the maximum width right now is the width of the scrollView of
SearchResults (which always expands to the whole screen size). This
width will only be correct if the scrollView (ie. the whole screen) is
smaller than the max width of searchResultsContent, which only is the
case for screens smaller than 1000px.
To fix the calculation, use the width of our own actor and don't get it
using clutter_actor_get_width(), but using the last allocation of the
actor. This way we don't get the preferred width if the actor is not
allocated at this point (it's hidden by _ensureProviderDisplay() when
starting a new search).
Then, when the allocation of the actor changes, rebuild the grid search
results by calling updateSearch() with the old arguments to ensure the
number of visible results is correct. The fact that we're only listening
for allocation changes here is the reason why we never want to use the
preferred width of the actor inside _getMaxDisplayedResults(): While
the actor is hidden clutter_actor_get_width() would return the preferred
width, which we'd then use the as the maximum width. But if the actor
had a correct allocation before, no notify::allocation signal will be
emitted when the actor is shown again because the allocation is still
the same, and we'll end up using the preferred width as maximium width
forever.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/110
The functionality the searchResultsBin container provides can easily be
moved into a subclass of St.BoxLayout, no need for an additional StBin.
The "searchResultsBin" css class isn't used in the stylesheets either.
Same with the scrollChild container.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/110
Object.prototype.hasOwnProperty() is more precise than checking for
falsiness, for instance the following is true:
{ foo: undefined }.hasOwnProperty('foo');
However when checking for a handler ID, a more relaxed check is more
appropriate, as particularly 0 is not a valid handler ID.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/626
For some reason, people are still seeing those after commit d5ebd8c8.
While this is something we really should figure out, we can work around
the issue by keeping the view actors hidden until the update is complete.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1065
Window previews are sometimes shown translucent, for example during
drags or animations. They can also have attached dialogs, in which
case the opacity should affect the combination of all windows instead
of being applied to each window individually, blended together, so
make sure they are redirected as a whole when necessary.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/774
Whether people love or hate the hot corner depends in large extents
on hardware sensitivity and habits, which is hard to get right
universally. So bite the bullet and support an option to enable or
disable hot corners ...
https://bugzilla.gnome.org/show_bug.cgi?id=688320
GNOME Shell is spitting out some errors in the journal due to its attempts
to speak to PackageKit, which is not present on Endless OS, so let's add
some runtime checks to make sure that PackageKit is actually available
before assuming so and using its proxy to decide which kind of UI to
show to the user when ending the session.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/369
The first parameter to Object.assign() is the same target object that
will be returned. That is, since commit 46874eed0 Params.parse() modifies
the @defaults object. Usually we pass that parameter as an object literal
and this isn't an issue, but the change breaks spectacularly in the few
cases where we use a re-usable variable.
Restore the previous behavior by copying the object first.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/615
Standard javascript now has Object.assign() which is very similar to
Params.parse(), except that the latter by default disallows "extra"
parameters. We can still leverage the standard API by simply
implementing the error check, and then call out to Object.assign()
for the actual parameter merging.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/612
Braces are optional for single-line arrow functions, but there's a
subtle difference:
Without braces, the expression is implicitly used as return value; with
braces, the function returns nothing unless there's an explicit return.
We currently reflect that in our style by only omitting braces when the
function is expected to have a return value, but that's not very obvious,
not an important differentiation to make, and not easy to express in an
automatic rule.
So just omit braces consistently as mandated by gjs' coding style.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/608
While we have some style inconsistencies - mostly regarding split lines,
i.e. aligning to the first arguments vs. a four-space indent - there are
a couple of places where the spacing is simply wrong. Fix those.
Spotted by eslint.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/608
We are currently inconsistent on whether case labels share the same
indentation level as the corresponding switch statement or not. gjs
goes with the default of no additional indentation, so go along with
that.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/608
Starting an object literal with a comment throws off eslint's rules
for brace style (newline between brace and properties for both opening
and closing brace or neither) as well as indentation (fixed four-space
indent or align with the previous argument).
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/608
Using multiple spaces after property names in order to align the
values isn't something we do elsewhere.
Instead, align the values by using a fixed 4-space indent as preferred
by gjs nowadays.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/608
The current code is carefully avoiding an overly wide line length as
well as adding literal new lines to the string due to indentation. It's
clever and barely legible.
Instead, use one string per line similar to how they appear in the actual
output, and join them together when setting the clipboard text.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/608
When destructuring multiple return values, we often use trailing commas
to indicate that there are additional elements that we are ignoring.
There isn't anything inherently wrong with that, but it's a style that's
too confusing for eslint - on the one hand we require a space after a
comma, on the other hand we require no space before closing brackets.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/607
We are currently inconsistent with whether or not to put a space
after catch clauses. While the predominant style is to omit it,
that's inconsistent with the style we use for any other statement.
There's not really a good reason to stick with it, so switch to
the style gjs/eslint default to.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/607
While allowed by the syntax, they are problematic because the
variable is in the scope of the switch() statement, but only
valid if a particular case clause is reached.
Add braces to limit the variables' scope to the corresponding
case clause to avoid that problem.
Spotted by eslint.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/607
Converting a variable to a particular type can be done explicitly (with
functions like Number() or toString()) or implicitly by relying on type
coercion (like concatenating a variable to the empty string to force
a string, or multiplying it with 1 to force a number).
As those tend to be less readable and clear, they are best avoided. So
replace the cases of string coercion we use with template strings, and
clarify the places that can be confused with number coercion.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/607
We can use that newer method where we don't care about the actual position
of an element inside the array.
(Array.includes() and Array.indexOf() do behave differently in edge cases,
for example in the handling of NaN, but those don't matter to us)
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/152
Control flow statements like return, break or continue are considered
unsafe in finally blocks, as they take precendence over any control
flow statement in the try and catch blocks, which may be unexpected.
This isn't the case here as the statement in the finally block is the
only one, but we can just as well avoid the finally block altogether
and use a regular return statement.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/606
This vfunc override has been introduced to ensure app icons are always
squared, but since the container of the AppIcon gets a square allocation
anyway if the 'square' property of the SwitcherButton is set, there's
no need to return a special width here.
Without the override we can also stop setting the size of the iconBin
manually. And since shell_app_create_icon_texture() uses logical pixels
but clutter_actor_set_size() uses screen pixels, that means we now no
longer set the size of the icon back to the unscaled value after it was
already correct.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1325
We're calculating icon sizes for the alt tab switcher early and at a
point where the style attributes of this._list are not loaded yet. To
make sure the value of this._list.spacing is correct, call
ensure_style() on this._list before accessing the spacing.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/587
The polkit password dialog has a spinner that gets displayed
while the users password is being verified.
Unfortunately, the spinner stop method unintentionally calls
back into itself after the stop fade out animation is complete.
The stop method is called at startup, so the looping begins as
soon as the dialog is visible and continues until the dialog is
dismissed.
This commit fixes the loop by having the stop method cease
calling itself, and instead having it call the stop method on the
superclass.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/602
The polkit password dialog has a spinner that gets displayed
while the users password is being verified.
Unfortunately, the spinner stop method unintentionally calls
back into itself after the stop fade out animation is complete.
The stop method is called at startup, so the looping begins as
soon as the dialog is visible and continues until the dialog is
dismissed.
This commit fixes the loop by having the stop method cease
calling itself, and instead having it call the stop method on the
superclass.
While the confirmation dialog for extension installation is simpler
than - say - authentication dialogs, it still makes sense to re-use
the common content layout instead of duplicating it.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/600
Using one variable to initialize all gestures will update the address of
the "gesture" pointer with every newly initialized object. This means
that event handlers which also use the "gesture" pointer like the
'keyboard-visible-changed' handler will update a different gesture as
soon as the pointer is changed.
This lead to a bug where the handler of 'keyboard-visible-changed'
wrongly nabled the unfullscreen gesture. Fix that by assigning each
gesture its own variable.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/598
In practice this has been seen to fail:
JS ERROR: TypeError: active.get_devices(...)[0] is undefined
ensureActiveConnectionProps@resource:///org/gnome/shell/ui/status/network.js:73:22
_getMainConnection@resource:///org/gnome/shell/ui/status/network.js:1791:13
_syncMainConnection@resource:///org/gnome/shell/ui/status/network.js:1809:32
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1406
Since commit 520cea9394, the opacity of icon grid children is used
both to skip children outside the current viewport and to hide the
real icons while animating icon clones.
As a result, a grid animation during an animation now ends up showing the
icons that are being animated. Avoid that glitch by leaving children's
opacity alone when there's an ongoing animation.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/582
AllView's adaptToSize is called as part of viewStack allocation vfunc, and this
makes the adjustment value to be reset while relayouting.
So, fix this by delaying this using the Meta later that we already had for
pageIndicators operations.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/1392
Since the repositioning is now done during allocation, we can just queue
a relayout when setting the boxpointer positioning via the source actor.
As per this _relayout() and _updateFlip now needs to be called during allocation
only and with an allocation box set.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/576
Changing the arrow side might need to reposition the boxpointer, however
if this happens during allocation, we don't need to trigger a new relayout since
we'd set the new allocation once _updateFlip's _reposition call is terminated,
otherwise if the position has changed, changing the boxpointer coordinates
will trigger a relayout anyways.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/576
As per commit 044572cb60 boxpointer uses its own coordinates to position itself.
However this would lead to warning when mutter-clutter is compiled with debug
options as we'd might try to set the box coordinates during the allocation
cycle.
So, when calling _reposition during allocation, instead of setting the actor's
coordinates we just pass the allocation box and we adjust its origin, in order
to set it properly in the vfunc.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1382https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/576
Hiding a child implies a parent reallocation, and IconGrid does it for the
children that doesn't fit in the available space, but this could lead to an
allocation recursion cycle. This has been introduced by commit 0e0574a0 to
reduce CPU usage not to using JS vfuncs.
To avoid this, toggle the children opacity instead so that we can achieve the
same visibility result, without any reallocation need.
In this way we also fix the case where hidden children can be shown again,
as _getVisibleChildren doesn't filter-out transparent ones, restoring the
pre-commit 0e0574a0 behavior.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1336https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/559
Background is monitoring the whole `org.gnome.desktop.background` gsettings keys
for changes connecting to the non-specialized 'changed' signal and re-emitting
this as-is.
This means that when the background is changed via control-center, we get
multiple 'changed' signal events from GSettings, and for each one of this we
recreate a Background and a BackgroundActor.
Avoid this by using an idle to delay the emission of the 'changed' signal
grouping the events.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/558
The same Meta.Background could be used by multiple instances of background
actors, and so should not be disposed when the actor using it is destroyed.
Instead of calling `run_dispose` directly on it, just nullify the reference
on destroy method, leaving the job of doing the proper disposition to the
gabage collector that keeps the proper reference count on the Meta.Background.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/501https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/558
Adds the UI part for the pointer accessibility features.
The various timeouts running are notified using a pie-timer showing
under the pointer.
For dwell-click type selection, we use a drop-down menu. Users can
use the dwell-click to select the next type of dwell click to be
emitted.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/474
Starting from commit 7bb84dae, GrabHelper requires the owner to be an Actor as
we pass this to pushModal that assumes it to be as well.
So check that GrabHelper owner is an actor and throws an error if it is not the
case. This helps in tracking down issues such as gnome-shell-extensions!68
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/565
The `switch-to-application-n` shortcuts are essentially "launch the nth
app in the dash" actions, so they are at the very least confusing when
the dash isn't available because the overview itself is disabled (for
example in initial-setup mode).
So disable the shortcuts when the overview is disabled, but delegate the
decision to a separate function so that extensions like 'panel-favorites'
which expose favorites by some other means can easily re-enable them.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1333
A menu item activation might lead to a call to `itemActivated` which eventually
will close the menu which leads to a `PopupMenu.removeAll` that destroys all the
items, stopping the emission of the 'activate' signal for them.
Before commit 4258ae3e this was not happening because destroy'ing a javascript
object wasn't really disposing it and thus stopping the signal emissions.
So, ensure that `itemActivated` is called after that all the other callbacks
have been consumed, and so that the menu is closed as last thing.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1326https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/557
Upon construction of the CDMA modem proxy, _reloadCdmaOperatorName()
is called and the value of the Sid property is read.
That property is defined as UINT32 in the D-Bus interface, but the
value may not be loaded yet after the proxy is constructed, in which
case its value will be null.
In _findProviderForSid(), we'll end up calling lookup_cdma_sid(null)
which fails with the following assertion:
gnome-shell[1082]: nma_mobile_providers_database_lookup_cdma_sid: assertion 'sid > 0' failed
This commit changes the (sid == 0) check in _findProviderForSid()
to (!sid) which will also catch the null case.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/555
The 'destroy' signal is emitted at the end of the destroy() method.
However the implementation of destroy() can end up emitting one of the
signals we connect to on the window, causing us to re-enter destroy
from its callback.
That will in turn lead to some objects getting disposed twice, which
produces a stack trace like the following one.
This commit fixes the issue by overriding the destroy() method instead
of connecting to the signal, which allows us to disconnect the signal
handlers from the window at an earlier time and avoid re-entrancy.
--
gnome-shell[1082]: Object Gio.Settings (0x7f0af8143f00), has been already deallocated — impossible to access it. This might be caused by the object having been destroyed from C code using something such as destroy(), dispose(), or remove() vfuncs.
org.gnome.Shell.desktop[1082]: == Stack trace for context 0x5627f7d1e220 ==
org.gnome.Shell.desktop[1082]: #0 5627f9e801a8 i resource:///org/gnome/shell/ui/messageTray.js:238 (7f0aefa9eca0 @ 22)
org.gnome.Shell.desktop[1082]: #1 5627f9e80108 i resource:///org/gnome/shell/ui/messageTray.js:802 (7f0aefaa2ee0 @ 28)
org.gnome.Shell.desktop[1082]: #2 5627f9e80070 i resource:///org/gnome/shell/ui/windowAttentionHandler.js:79 (7f0aef7b29d0 @ 62)
org.gnome.Shell.desktop[1082]: #3 7fffa69fbfc0 b self-hosted:979 (7f0aefa515e0 @ 440)
org.gnome.Shell.desktop[1082]: #4 5627f9e7ffe0 i resource:///org/gnome/shell/ui/messageTray.js:121 (7f0aefa9e1f0 @ 71)
org.gnome.Shell.desktop[1082]: #5 5627f9e7ff38 i resource:///org/gnome/shell/ui/messageTray.js:1408 (7f0aefaa58b0 @ 22)
org.gnome.Shell.desktop[1082]: #6 5627f9e7fe80 i resource:///org/gnome/shell/ui/messageTray.js:1237 (7f0aefaa51f0 @ 729)
org.gnome.Shell.desktop[1082]: #7 5627f9e7fde8 i resource:///org/gnome/shell/ui/messageTray.js:1055 (7f0aefaa3d30 @ 124)
org.gnome.Shell.desktop[1082]: #8 7fffa69ff8e0 b self-hosted:979 (7f0aefa515e0 @ 440)
org.gnome.Shell.desktop[1082]: #9 7fffa69ff9d0 b resource:///org/gnome/gjs/modules/signals.js:142 (7f0aefccb670 @ 386)
org.gnome.Shell.desktop[1082]: #10 5627f9e7fd58 i resource:///org/gnome/shell/ui/messageTray.js:479 (7f0aefaa0940 @ 50)
org.gnome.Shell.desktop[1082]: #11 5627f9e7fcb8 i resource:///org/gnome/shell/ui/messageTray.js:808 (7f0aefaa2ee0 @ 99)
org.gnome.Shell.desktop[1082]: #12 5627f9e7fc28 i resource:///org/gnome/shell/ui/windowAttentionHandler.js:69 (7f0aef7b28b0 @ 13)
org.gnome.Shell.desktop[1082]: #13 5627f9e7fb80 i resource:///org/gnome/shell/ui/main.js:566 (7f0aefcd8820 @ 216)
org.gnome.Shell.desktop[1082]: #14 5627f9e7fad0 i resource:///org/gnome/shell/ui/windowAttentionHandler.js:103 (7f0aef7b2c10 @ 27)
org.gnome.Shell.desktop[1082]: #15 5627f9e7fa58 i resource:///org/gnome/shell/ui/windowAttentionHandler.js:43 (7f0aef7b2700 @ 17)
org.gnome.Shell.desktop[1082]: #16 7fffa6a03350 b resource:///org/gnome/gjs/modules/signals.js:142 (7f0aefccb670 @ 386)
org.gnome.Shell.desktop[1082]: #17 5627f9e7f9d0 i resource:///org/gnome/shell/ui/messageTray.js:471 (7f0aefaa08b0 @ 22)
org.gnome.Shell.desktop[1082]: #18 5627f9e7f950 i resource:///org/gnome/shell/ui/calendar.js:752 (7f0aefaabdc0 @ 22)
org.gnome.Shell.desktop[1082]: #19 7fffa6a048f0 b self-hosted:979 (7f0aefa515e0 @ 440)
org.gnome.Shell.desktop[1082]: == Stack trace for context 0x5627f7d1e220 ==
org.gnome.Shell.desktop[1082]: #0 5627f9e801a8 i resource:///org/gnome/shell/ui/messageTray.js:239 (7f0aefa9eca0 @ 42)
org.gnome.Shell.desktop[1082]: #1 5627f9e80108 i resource:///org/gnome/shell/ui/messageTray.js:802 (7f0aefaa2ee0 @ 28)
org.gnome.Shell.desktop[1082]: #2 5627f9e80070 i resource:///org/gnome/shell/ui/windowAttentionHandler.js:79 (7f0aef7b29d0 @ 62)
org.gnome.Shell.desktop[1082]: #3 7fffa69fbfc0 b self-hosted:979 (7f0aefa515e0 @ 440)
org.gnome.Shell.desktop[1082]: #4 5627f9e7ffe0 i resource:///org/gnome/shell/ui/messageTray.js:121 (7f0aefa9e1f0 @ 71)
org.gnome.Shell.desktop[1082]: #5 5627f9e7ff38 i resource:///org/gnome/shell/ui/messageTray.js:1408 (7f0aefaa58b0 @ 22)
org.gnome.Shell.desktop[1082]: #6 5627f9e7fe80 i resource:///org/gnome/shell/ui/messageTray.js:1237 (7f0aefaa51f0 @ 729)
org.gnome.Shell.desktop[1082]: #7 5627f9e7fde8 i resource:///org/gnome/shell/ui/messageTray.js:1055 (7f0aefaa3d30 @ 124)
org.gnome.Shell.desktop[1082]: #8 7fffa69ff8e0 b self-hosted:979 (7f0aefa515e0 @ 440)
org.gnome.Shell.desktop[1082]: #9 7fffa69ff9d0 b resource:///org/gnome/gjs/modules/signals.js:142 (7f0aefccb670 @ 386)
org.gnome.Shell.desktop[1082]: #10 5627f9e7fd58 i resource:///org/gnome/shell/ui/messageTray.js:479 (7f0aefaa0940 @ 50)
org.gnome.Shell.desktop[1082]: #11 5627f9e7fcb8 i resource:///org/gnome/shell/ui/messageTray.js:808 (7f0aefaa2ee0 @ 99)
org.gnome.Shell.desktop[1082]: #12 5627f9e7fc28 i resource:///org/gnome/shell/ui/windowAttentionHandler.js:69 (7f0aef7b28b0 @ 13)
org.gnome.Shell.desktop[1082]: #13 5627f9e7fb80 i resource:///org/gnome/shell/ui/main.js:566 (7f0aefcd8820 @ 216)
org.gnome.Shell.desktop[1082]: #14 5627f9e7fad0 i resource:///org/gnome/shell/ui/windowAttentionHandler.js:103 (7f0aef7b2c10 @ 27)
org.gnome.Shell.desktop[1082]: #15 5627f9e7fa58 i resource:///org/gnome/shell/ui/windowAttentionHandler.js:43 (7f0aef7b2700 @ 17)
org.gnome.Shell.desktop[1082]: #16 7fffa6a03350 b resource:///org/gnome/gjs/modules/signals.js:142 (7f0aefccb670 @ 386)
org.gnome.Shell.desktop[1082]: #17 5627f9e7f9d0 i resource:///org/gnome/shell/ui/messageTray.js:471 (7f0aefaa08b0 @ 22)
org.gnome.Shell.desktop[1082]: #18 5627f9e7f950 i resource:///org/gnome/shell/ui/calendar.js:752 (7f0aefaabdc0 @ 22)
org.gnome.Shell.desktop[1082]: #19 7fffa6a048f0 b self-hosted:979 (7f0aefa515e0 @ 440)
gnome-shell[1082]: g_object_run_dispose: assertion 'G_IS_OBJECT (object)' failed
gnome-shell[1082]: Object Gio.Settings (0x7f0af8161750), has been already deallocated — impossible to access it. This might be caused by the object having been destroyed from C code using something such as destroy(), dispose(), or remove() vfuncs.
gnome-shell[1082]: g_object_run_dispose: assertion 'G_IS_OBJECT (object)' failed
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/555
Make the dialog a widget itself, removing the `_group` property used for
handling the actor.
Update all the inherited classes to be also GObject implementations, moving all
the signals to proper object ones.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/55
Since version 1.50.0, gjs defines GObject.NotImplementedError for throwing
errors when a "virtual" method that requires a subclass implementation is not
defined.
So use this instead of a generic JS Error in such cases.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/549
This extends the ShellMountPasswordDialog by widgets which allow
specifying parameters supported by TrueCrypt and VeraCrypt compatible
volumes (TCRYPT). This includes:
- Whether the volume to be unlocked is hidden.
- Whether the volume to be unlocked is a system partition.
Note: TrueCrypt and VeraCrypt only support encrypting Windows
systems [1], so the label for this option is "Windows System Volume".
- Whether to use a PIM [2].
- Whether to use keyfiles. Unfortunately, GMountOperation doesn't
support TCRYPT keyfiles, so if this checkbox is checked, we tell the
user that they should unlock the volume with Disks, which supports
unlocking TCRYPT volumes with keyfiles.
[1] https://www.veracrypt.fr/en/System%20Encryption.html
[2] https://www.veracrypt.fr/en/Header%20Key%20Derivation.htmlhttps://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/126
App IDs in gnome-shell don't match AppStream, Flatpak or Snap IDs. For the
desktop portal, the latter two are more relevant, so include it in the
returned information.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1289
The top_window_group is used for windows like popup menus, which should
appear above shell chrome like the panel.
Since we want important actors such as the screen keyboard or modal
dialogs to be shown above those windows, add their actors after adding
global.top_window_group to this.uiGroup and provide a new function
addTopChrome() to add important chrome above the top_window_group.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/917https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/358
Don't use composition for PopupBaseMenuItem, but instead inherit from BoxLayout.
So remove the internal actor, making all the menu items actor themselves.
Add an actor property as fallback to avoid warnings for usage in menus.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/499
Our search for system actions is currently inconsistent with searching
for applications: While we match terms anywhere within keywords, GIO
will only match at the beginning of words.
In order to get the same behavior, split keywords into single words
and only match terms at the beginning of a word.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/745
gjs now supports an optional GTypeFlags value for GObject subclasses
defined with GObject.registerClass(), so it is not possible to define
abstract classes on the gobject-level, just like from C.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/517
When toggling keyboard various times, we might get an error because trying to
disconnect an idle that isn't set anymore.
This is because when we remove the idle, we don't unset the ID.
Also clear the idle when destroying the keyboard.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/540
The current page is going to be destroyed as part of _onKeyboardGroupsChanged
cleanup, however we don't unset its pointer, and thus we'd might try to call a
function using an invalidated pointer.
So, unset the this._current_page reference when its get destroyed, connecting
to destroy signal when setting it and disconnecting when changing page.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1281https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/540
The interface name when a device is added may not be the final one. For
example when using USB tethering, it will first appear as 'usb0' before
being renamed to something like 'enp0s20f0u1' depending on the port the
phone is plugged in.
As a result, we will ignore the new interface name in that case and fail
to associate the correct connection with the device: Instead of the
correct "USB Ethernet" (or user-customized name), it will show up as
"Ethernet".
Fix this by updating names and connections when a device's interface
property changes.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/534
This makes it possible to drag a window which appears connected with the
panel, even if it is not in focus. As a result, it should be easier to
manipulate side-by-side windows.
https://bugzilla.gnome.org/show_bug.cgi?id=679290
To prevent a small gap between windows in the workspace switching
animation, we temporarily shift windows up or down by the height of the
panel. This obviously breaks the animation for fullscreen windows, those
will overlap with the ones on the other workspace since there is no
panel shown in that case.
Fix this by checking whether the old or new workspace includes a
fullscreen window and don't shift the windows if there is one.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/757https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/322
Dialog's subtitle or body could not be properly wrapped, while it's ellipsized
when the text's width doesn't exceed the container size.
Clutter text has an `ellipsize` property, however in dialog's subtitle and body
we have been setting the `ellipsize-mode` property to Pango.EllipsizeMode.NONE
that is not present in the underlying GObject.
Not being an error in javascript, gjs didn't warn us about this, while at the
same time the St.Label's default Pango.EllipsizeMode.END was used.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/922https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/531
If an actor's allocation is outdated, clutter_actor_get_allocation_box()
will queue a relayout. That's why it's advised to not use the function
unless the allocation is known to be valid (namely during paint), but
in particular not from within get_preferred_width/height vfuncs.
Using the :allocation property (which may be outdated) would be better,
but in this case we can simply delegate the request to the correct actor.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1065
We were cleaning up self._groups, but the actors for all previous
groups/layers/modes would remain attached to the aspect container,
simply hidden.
Under some circumstances this can really make the amount of actors
in the shell stage to quickly ramp up, it's not just a "leak" but
also has potential side effects on performance.
We should destroy all child actors of this._aspectContainer, except
the static ones (emoji and keypad).
While at it, fix this._groups re-initialization, as it's actually an
object, not an array.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/523
Closes?: https://gitlab.gnome.org/GNOME/mutter/issues/556
We currently assume that every location has an associated timezone.
While this is sound in the real world, in practise it depends on
whether or not libgweather can find a corresponding timezone DB
entry.
This used to be a fringe case, but has become more likely when commit
https://gitlab.gnome.org/GNOME/libgweather/commit/d7682676ac9 moved
weather stations from cities to countries - the station itself is un-
likely to have a timezone entry, and the country may be part of more
than a single timezone.
It would be good for libgweather to return a timezone for those
locations again, but we should defend against the case anyway.
We cannot tell what time it is at a particular location without
knowing the timezone, so simply filter them out.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1062
The top bar handles allocating all its children itself, so there's
little value in chaining up to st_widget_allocate() and get the
default layout manager allocating all children again (and possibly
differently).
If this happens, we end up with an infinite allocation cycle with
corresponding performance penalty. Fix this by just doing and what
Shell.GenericContainer did before commit 286ffbe2b6 replaced it,
and not chain up to StWidget.
Thanks to Robert Mader for debugging the issue.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1054
On one hand, we were using a path instead of an URI on
rsvg_handle_set_base_uri(). This broke at some point in librsvg
(presumably for the best, handling paths there sounds non-standard)
leaving a blank svg (As the base image wouldn't be accessed).
On the other hand, we use this with the deprecated rsvg_handle_write()
which we should drift away from.
Using rsvg_handle_new_from_stream_sync() neatly solves both. We use
newer API based on input streams and GFiles, and it internally does
the right thing, bringing the pad OSD back to life.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/1220
Classes that are sub-classes of GObject don't use a constructor per se, so we
can't check for new.target (as this is undefined) in _init.
Then compare the current constructor name instead.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/503
Classes that are sub-classes of GObject don't use a constructor per se, so we
can't check for new.target (as this is undefined) in _init.
Then compare the current constructor name instead.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/503
Unlike regular keys that generate key events from a virtual device,
emoji keys rely on the input method to insert the character. However
as the compositor cannot inject IM events into ibus, this only works
in the shell's own entries on X11.
We shouldn't expose mostly broken functionality to the user, so limit
the feature to the wayland session.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1172
Move the signal handlers for changed settings to be connected after the
creation of the menu items to make sure a reference to the item is set.
While it also worked fine before, this solution certainly looks cleaner.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/512
At the point it is disabled, it has got signal handlers connected but
this._workspacesView is uninitialized. This triggers:
(gnome-shell:3993): Gjs-WARNING **: 18:49:53.281: JS ERROR: Exception in callback for signal: cancel: TypeError: this._workspacesViews is undefined
_endTouchGesture@resource:///org/gnome/shell/ui/workspacesView.js:527:25
_emit@resource:///org/gnome/gjs/modules/signals.js:142:27
set enabled@resource:///org/gnome/shell/ui/windowManager.js:478:13
WorkspacesDisplay<@resource:///org/gnome/shell/ui/workspacesView.js:482:9
ViewSelector<@resource:///org/gnome/shell/ui/viewSelector.js:167:35
ControlsManager<@resource:///org/gnome/shell/ui/overviewControls.js:405:29
init@resource:///org/gnome/shell/ui/overview.js:234:26
_initializeUI@resource:///org/gnome/shell/ui/main.js:184:5
start@resource:///org/gnome/shell/ui/main.js:124:5
@<main>:1:31
On startup. Shuffling these two lines prevent this from happening.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/506
The port away from the old Shell.GenericContainer actor turned many JS
classes with a corresponding actor property into Clutter.Actor subclasses.
For compatibility reasons, those properties were kept around for a while.
They were now removed and any code that still uses them should be adjusted.
Facilitate that transition by defining the compatibility property on
Clutter.Actor itself, but log a warning every time it is accessed.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/487
It may not be immediately obvious that the windows section is a
list of open application windows, as titles like "Downloads" can
easily be confused with an action. Add a section heading to avoid
confusion.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/968
We currently copy the app icon menu behavior, which puts a separator
between windows from the current workspace and windows from any other
workspace. It is more useful to have the windows section appear as a
clearly marked group, so drop the separator.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/968
Work around a known regression from [1] that caused the volume bar in
the OSD window to never be hidden, even if the volume is set to 0. This
happened because the border radius of the barLevel is always drawn
without ensuring that the actual bar is visible.
So simply check if the value to draw is 0, and if it is, don't draw the
border radius of the bar at all. This will still result in incorrect
representation of values that have a width smaller than 2*border-radius,
but at least the bar looks right for a width of 0 now.
[1] https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/2https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/384
If a window gets destroyed right before it's resize
animation starts the user can get confronted with an undead
zombie clone that doesn't go away.
This commit makes sure said clones get reaped with their
actors.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1166
When determining the biggest icon size that fits the available height,
we first subtract the additional space requirements of icons (spacing,
padding, running indicator etc.) and then divide the result by the
number of icons to get the maximum size available to each icon texture.
In the above, the additional space requirement of each icon is taken
from the first icon (as all icons are assumed to be the same), and
calculated as the difference between the icon button's preferred height
and the currently used icon size.
To make sure that the icon is actually using the dash's current icon
size (even while animating to a new icon size), we enforce its height
during the size request and restore its original height afterwards.
However after some recent changes, that step is causing troubles:
For some reason, the original height may be 0, and when we restore it,
we end up forcing a fixed non-height that bypasses the regular size
request machinery.
While it is unclear where exactly the zero height comes from (maybe
waiting for a valid resource scale?), it is clear that it's best
to avoid forcing a fixed height. So instead of making the icon
texture comply with the assumed icon size, adjust the calculations
to use its current height request.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1053
We recently added offsets to world clocks that represent the location's
timezone as UTC offset. However for most users, that representation is
overly technical and less helpful than the difference to their local time.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1157
We currently use the city name for all location except named timezones.
However locations only have a city name if they are of level CITY or
DETACHED, or if they are of level WEATHER_STATION with a parent of level
CITY.
So when libgweather commit d7682676ac9 moved weather station locations from
cities to countries, it broke their names in the world clocks section.
To fix this, stop making assumptions about when we can use the city name
and simply try it first for all locations and fall back to the plain name
if its not available.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1150
After the Adwaita refresh, the button shows up oval rather than
circular. To address this, make sure that the "image-button" class
is applied as well by using the dedicated setter function.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/482
Compute the source actor workarea and allocation when repositioning and keep it
cached so that we've not to calculating it again in _calculateArrowSide.
Since _calculateArrowSide only is called inside _updateFlip that is always
called just after reposition, we can be sure that the computed values are still
correct.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/435
Currently all the widgets using BoxPointer and so popup actors are always drawn
at screen origin and then shifted at paint time in the proper position.
This doesn't work when using resource scale, since the widgets need to know
in which monitor they currently are in order to use properly scaled resources.
So, basically revert commit 22c22e0d7 and go back using the actual actor
coordinates for positioning and the actor translation for animating it, as the
relayouting issues of the past seem to be gone now.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1008https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/435
