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