Notifications use a transition that overshoots the target value, however
we can only really do that for the position and not the opacity where
some values would end up out of the valid range.
We currently address this by proxying the actual opacity property in a
javascript property, and clamp it to the valid range in an onUpdate()
callback.
This won't be an option if we want to use Clutter animations, so instead,
use separate tweens for opacity and position.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/22
Unlike Tweener, which doesn't know or care about actor state, Clutter
will skip implicit animations on actors that aren't mapped. This makes
sense of course, but it will break the page indicator animation we
do on map: When we get notified about the container being mapped, the
individual indicators (which are the actors being animated) are still
unmapped.
Resolve this by deferring the animation to a LaterFunc.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/22
For animating the arrows on the screenshield, we currently use a custom
transition function that tweens the opacity from 0 to maxOpacity in the
first half of the animation, and from maxOpacity back to 0 in the second
half.
This doesn't easily translate to Clutter's own animation framework, so
replace the custom transition with two consecutive tweens which do.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/22
Dash items are currently animated via the custom "childScale" and
"childOpacity" properties. However since commit efb3025d8c, those
properties actually control the scale-x/scale-y and opacity properties
of the actor itself (not the child), so cut out the intermediate
custom properties in favor of the "real" ones.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/22
When expanding a submenu, we currently use a single tween to animate
both the submenu actor and the source arrow. We do this by tweening
a monkey-patched JS property on the main actor, which we then use
to update the arrow's GObject property on updates. As Clutter cannot
animate random JS properties, this trick will prevent us from using
implicit animations here.
The only reason I can think of for using a single tween is to keep
both animations in perfect lock step, but as expansion and rotation
are visually quite distinct, this shouldn't be required, so just
set up separate animations for each actor.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/22
Now that redisplaying is a lightweight operation that only
adds and removes what changed, we can not be concerned about
redisplaying on folder changes.
Redisplaying will be necessary when custom order in the app
grid is implemented, in order to update not only which icons
are hidden, but also their position.
Call _redisplay() in AllView when folders change.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/645
FolderView and AllView currently check if the item is
present in the BaseAppView._items map, in order to avoid
adding the same icon multiple times.
Now that BaseAppView._loadApps() has a different role --
it returns a list with all app icons, and BaseAppView
diffs with the current list of app icons -- checking the
BaseAppView._items map is wrong.
Make sure there are no duplicated items in the temporary
array returned by all _loadApps() implementations. Remove
the now unused BaseAppView.hasItem() method.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/645
BaseAppView currently removes all icons, and readds them, every
time the list of app icons needs to be redisplayed. In order to
allow animating app icon positions in the future, however, we
cannot destroy the actors of the app icons.
Previous commits paved the way for us to do differential loading,
i.e. add only the icons that were added, and remove only what was
removed.
Make the BaseAppView effectively implement differential loading.
The BaseAppView.removeAll() method is removed, since we do not
remove all icons anymore. BaseAppView._loadApps() now returns an
array with the new apps, instead of putting them directly at the
BaseAppView lists.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/645
Next commit will introduce differential loading of
app icons, and will reorganize this part of the
codebase.
When doing that, the ideal symmetry of the new code
would be:
* Update BaseAppView._allItems array
* Update BaseAppView._items map
* Update BaseAppView._grid actor
Move the code in _loadGrid() into _redisplay() so that
we can check in-place which new icons need to be added.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/645
Now that the three views follow the exact same loading routine
(remove all + load apps + load grid), we don't need each view
call loadGrid() directly anymore.
This is an important step in order to animate adding and removing
icons, since now we can diff old and new app icons properly.
Move all calls to BaseAppView.loadGrid() to a single one after
BaseAppView._loadApps(). Also add the underscore prefix, since
this is now considered a protected function.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/645
FrequentView is another view that is slightly not unified with how
BaseAppView expects subclasses to load app icons. Instead of using
BaseAppView.addItem() and then calling BaseAppview.loadGrid(), it
adds the app icons directly to the icon grid.
Make FrequentView add icons using BaseAppview.addItem(), and load
the icons using BaseAppView.loadGrid().
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/645
Future patches will diff the old and new icons of views, in order to
animate them when necessary (e.g. adding an app icon to a folder, or
from a folder back to the app grid). In order to do that, all views
must be streamlined in how they load app icons.
Currently, FrequentView and AllView are already following the behavior
expected by BaseAppView, but FolderView isn't. Its icons are loaded by
FolderIcon, and FolderView doesn't implement BaseView._loadApps(),
which makes it impossible to diff old and new apps.
Move the app icon loading routine from FolderIcon to FolderView, by
implementing the _loadApps() method.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/645
The different units - seconds for Tweener and milliseconds for
timeouts - are not a big issue currently, as there is little
overlap. However this will change when we start using Clutter's
own animation framework (which uses milliseconds as well), in
particular where constants are shared between modules.
In order to prepare for the transition, define all animation times
as milliseconds and adjust them when passing them to Tweener.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/663
Since commit 007d30573 we use an actor effect to apply the radial effect and
we pass the effect to the tweener in order to animate it.
However, we always still remove the previously added tween from the actor,
instead that from the actual target.
So, depending the radial effect state, remove the tweens from the proper target
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/653
We currently assume that user icons are square, which is the case when
set by the users settings panel, but not enforced by AccountsService.
Handle that case by moving the pixel size back to the actor and using
an appropriate background-size style property of 'cover' (which means
the smallest dimension of the image is scaled to fit the desired size).
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1144
A generic, introspectable Shader effect is not only more flexible
than a shader actor, it will also make it much easier to turn
Lightbox into an actor subclass and replace Tweener with Clutter's
own animation support.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/651
Due to typecasting being done when converting floats to integers in
gnome-settings-daemon, a volume of 0.9% in g-s-d will end up as 0% in
gnome-shell. This can lead to a mismatch of icons between the volume OSD
(the icon to use is determined by g-s-d itself) and the shells own
volume indicator (the icon to use is determined by the shell using the
volume received from g-s-d).
To fix this, simply get rid of the conversion from float to percentage
in g-s-d and back to floats in the shell and just send a float/double
value on DBus.
https://gitlab.gnome.org/GNOME/gnome-settings-daemon/merge_requests/78https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/385
LevelBar is not really used, all the checks are implemented inside
BarLevel as well and the accessible name is wrong because the osdWindow
doesn't only show the volume, but also the brightness and other things.
The workaround for updating the bars width is also no longer needed now
that we have BarLevel.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/385
There are some cases (for example when tweening value changes), where
the level will be set to the same value it already is at. Avoid those
unnecessary repaints by checking whether the value is already used and
returning if it is.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/385
AppIcon makes itself draggable, and handles the various DnD
routines such as 'drag-begin' and 'drag-end' by making the
Overview emit the appropriate signals.
However, when destroyed, the AppIcon does not try to finish
any drag operations that started. That causes the event
blocker in AllView not to be updated correctly when dragging
icons to outside folders.
Make AppIcon emit 'item-drag-end' when a drag operation
started and it's destroyed.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/643
For GObject properties, we follow the convention of all-lowercase,
dash-separated names. Those translate to underscores in getters/setters,
so exempt them from the newly added "camelcase" rule.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/627
While we aren't using those destructured variables, they are still useful
to document the meaning of those elements. We don't want eslint to keep
warning about them though, so mark them accordingly.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/627
Those unused arguments aren't bugs - unbeknownst to eslint, they all
correspond to valid signal parameters - but they don't contribute
anything to clarity, so just remove them anyway.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/627
This was left-over in commit 2743f18af, and probably is the real reason
why the busy spinner wasn't using the shared AnimatedIcon.Spinner class:
The animation there was much slower.
Still, let's keep the code as-is for now, if we really need a different
animation time, we can add an optional constructor parameter to the
Spinner class.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/640
At the moment the only way to open a folder icon is to click on it;
there's no API to open the icon programmatically.
This commits adds an open method and makes the click handler use
it.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/628
When a FolderIcon is opened, it asks the parent view to allocate
space for it, which takes time. Eventually, the space-ready
signal is emitted on the view and the icon can make use of the new
space with its popup. If the icon gets destroyed in the
interim, though, space-ready signal handler still fires.
This commit disconnects the signal handler so it doesn't get called
on a destroyed icon.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/628
It is important that the FolderView of a FolderIcon always
gets destroyed before the AppFolderPopup, since the view
may or may not be in the popup, and the view should
get cleaned up exactly once in either case.
This commit adds a destroy handler on FolderIcon to ensure
things get taken down in the right order, and to make sure
the view isn't leaked if it's not yet part of the popup.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/628
At the moment AppFolderPopup calls popdown on destruction,
which leads to open-state-changed getting emitted after
the actor associated with the popup is destroyed.
This commit handles ungrabbing and closing from an
actor destroy handler to side-step the open-state-changed
signal.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/628
If an icon already exists in an app view with the same id, the
duplicate is not added on a call to addItem. Unfortunately,
since it's not added, the icon actor gets orphaned and leaked.
This commit address the problem by introducing a new hasItem
method and disallowing callers to call addItem with a duplicate
in the first place.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/628
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
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
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
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
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
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
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
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
Inserting a workspace is implemented by appending a new workspace, then
shifting all windows after the "new" workspace up. This has an unintended
side effect on sticky windows, as changing its workspace will unstick it.
Fix this by excluding sticky windows - there's little point in moving them
anyway, given that they should be on all workspaces (including the original
workspace and the target one).
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1151
The monitor index is not something that gnome-shell and
gnome-settings-daemon seem to be agreeing about. Using the connector
string is a much more reliable method of identifying a specific screen
and we are indeed using this already for monitor labling.
So switch over to use the connector rather than the monitor index. If a
user tries to use the old API, then the OSD will simply show up on all
monitors (which is the status quo currently anyway).
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/489
This API has been broken for quite some time now as the corresponding
mutter function meta_monitor_manager_get_monitor_for_output was removed.
If anyone tries to use it, we would just run into a backtrace.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/490
Selecting a screen area for a screenshot isn't the same as selecting
items in an icon view, so there's no strong rationale for picking
up the style from GTK. We stopped doing that for other elements like
tile previews long ago, so just use our own style here too.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/481
Now that the existing touch/touchpad gestures in windowManager only
handle normal mode, add corresponding gestures for the overview and
hook them up to the existing workspace scroll animations.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/516
The window group is hidden while in overview, so the stick-to-content
animation isn't visible either. Worse, the gestures messes up the
position of window actors in that case. Just limit the gesture to
normal mode for now, we will soon add it back in the overview with
its own animation handling.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/516
The touch/touchpad gestures to switch workspace currently hard-code
the modes in which we want the gestures to work. While these modes
are correct, the existing switch animation only works in NORMAL mode,
not in the overview where the window group is hidden. The easiest way
to address this is to handle both cases completely separately, namely
use separate actions in- and outside the overview.
Make the existing usable in that way by making the list of allowed
modes a constructor parameter.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/516
The same code for reading the current magnifier state is repeated in both
shell-recorder, shell-screenshot and magnifier itself.
So to move this inside a property of st-settings so that we can refer to it
all over the places removing duplications.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/473
There's no point in keeping the cursor sprite texture around all the time,
and to listen for its changes, we just need this when the magnifier is active.
So, initialize the magnifier texture and monitor for the sprite changes on
activation, while disconnect from the signal and nullify the texture when
the magnifier is deactivated.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/443
In order to paint all the color channels of the content texture we need to
set the color channels to 255, so instead of doing this manually we can just
reuse the static color definition for white.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1020
ClutterContent's get_preferred_size should return a boolean weather the
preferred size is valid, so in javascript we've to return this state value
before out width and height.
Since this was not happening, clutter was considering the width as the state
(converting the non-zero value to true), the height as the width, while ignoring
the returned height (that was then defaulted to 0)
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1020
The default ZoomRegion is created at startup and only updated if it is active
when the monitor setup changes. Thus when reactivating the magnifier after a
display change, the viewport used is still the one that been computed with the
old screen geometry values.
Move screen update code inside a function and call it both when activating
the zoom region and when the monitor changes during a zoom session.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1120
NetworkManager added support for a new device - NMDeviceWifiP2P - but
did not add the corresponding enum value in NMDeviceType. The return
value for nm_device_get_device_type() is therefore "illegal" for the
newly added device, and gjs throws an exception.
This should ultimately be fixed in libnm, but as errors when adding
one device shouldn't interfere with adding any other devices, catching
exception is a good idea anyway, so do just that.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1023
The current scripting module makes heavy use of pre-standardized
iterator/generator/promise APIs, at least for some of those support
was pulled in SpiderMonkey 58.
Port to the new standardized replacements to get the module back into
a working state.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/440
Commit 1b169655ac removed the system indicator from the list of children
that are considered for the overall menu width, because we do want the
log-out submenu to adapt to the available width.
However as a side effect, action buttons no longer contribute to the
width either, so if extensions add additional buttons, the menu is
likely to overflow.
Avoid this by only adding the button group to the list of size children.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1094
This call just went through stomping over previous drag operations if any,
_maybeStartDrag() accounted for this, but other callers (well, WindowClone
in workspace.js) don't. This must bail out early even if a drag operation is
requested, luckily all callers account for it already.
This broke shell state by preserving connected captured-event handlers if
one tried to drag multiple windows simultaneously through multitouch. We
of course don't support that, now more elegantly.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/455
The bind constraint that replaced the Shell.GenericContainer in commit
f4682748fa is subtly different from the previous code:
It forces the actor to have the same size as the stage, rather than just
requesting that size.
This breaks the magnifier which relies on the UI being able to be bigger
than the display size. Fix by going back to using a custom actor.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/646
The texture cache now returns an actor with an appropriate ClutterContent
rather than a ClutterTexture. That actor uses the CONTENT_SIZE request
mode, which means that it will unconditionally request the preferred size
of the content. That is, setting an explicit size no longer has an effect.
Fix this by making sure the image is already loaded with the desired
dimensions.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1024
It is convenient for the OSK so it eg. doesn't appear centered in the
available space (eg. on very narrow portrait layouts), plus it will also
be convenient to align other AspectContainers to the same baseline.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/439
While it is possible to register accelerators in-bulk, there is no
proper way to unregister them again. This adds the corresponding call
for UngrabAccelerator to allow ungrabbing multiple accelerators at the
same time.
The idea is that g-s-d can use this in the future to simplify the
keybinding reload logic.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/429
Commit 8f15193b4 changed the `policy` property from a regular JS property to
a getter. This was necessary to avoid calling an overridden _createPolicy()
method before a subclass is properly initialized, but it broke the second
way of using notification sources:
Don't create a Source subclass, but use the base class directly and change
its `policy` property.
There's no good reason why we should no longer allow this, so add a setter.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/431
The dialog doesn't change the `destroyOnClose` property from its default,
so it is already destroyed automatically on close. So if we also destroy
it explicitly, we end up (rightfully) with one of gjs' infamous "invalid
access" warnings.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/430
Ouch, this went unnoticed for a long time: As the minimum size of menu
items is generally small (because its label can be ellipsized), we are
requesting the unellipsized width of the last "size child" instead of
the widest one.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/996
Here's a template string with '/' that escaped commit 94423151b2,
resulting in an xgettext warning when generating the .pot file.
Simply move it into the resource like the other interface descriptions
to make xgettext happy again.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/407
The top drag gesture is not of any use if the topmost window is not
a fullscreen window and will only block events near the important top
screen edge (i.e. the panel). To fix this, only enable this gesture if
the focus window is a fullscreen window.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/552
If the user's real name is too long to fit the menu comfortably, we are
supposed to use the username instead. However since commit f8e5e3e435,
we no longer set a max-width on the menu as a whole, but instead base
the width request on only "unellipsizable" children. For some reason
the system menu ended up there, so the name is now allowed to grow
indefinitely.
Remove it from the list of size children to get the intended behavior
back.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/400
The menu grabs the key focus when opened, which takes focus away from
whichever actor triggered the keyboard. And as the menu doesn't have
any text entries, the keyboard is popped down as a result.
Prevent this by making the menu items unfocusable, so the keyboard
focus just stays where it is. Considering that the menu is part
of the on-screen keyboard itself, not being keyboard-navigatable
isn't a big deal here.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/171
Menu items use a single 'active' state that follows both hover and
keyboard focus. It therefore makes sense for the active item to always
grab the focus, in particular as an item that is sensitive but not
focusable by keynav would be rather weird.
As it turns out, we do have a case that is weird enough where we want
exactly that, so only grab focus if the actor's :can-focus property
allows it.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/171
Window titles aren't restricted in length, so the menu may end up unwieldily
width. Commit 0bec76b6ee therefore limited the app context menus, but that
got accidentally dropped in commit 0ded0dbfd5. Add back the limitation and
extend it to the new app menu as well.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/624
Top bar icons are supposed to by symbolic, but not all applications
provide a symbolic icon. Make the stick out less by desaturating
the appmenu icon if a symbolic style is requested.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/624
With the app menu being phased out entirely, there's no good reason to
keep support for the fallback app menu in decorations either - the number
of applications that set an app menu and haven't embraced client-side
decorations is extremely small, and they should already have alternative
fallbacks for non-GNOME environment in place.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/624
Since the plans to retire the app menu were announced, nobody objected to
the removal of the menu content, however some concerns were raised about
the menu's secondary role as indicator.
Account for that by not removing the existing app menu, but replacing it
with a built-in menu similar to the existing app icon context menu.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/624
The GtkSettings was originally introduced to inform applications about
the desktop shell's capabilities, but users soon started to use it to
force GTK+ to show the app menu inside the application. We eventually
caved and also handled the setting ourselves to hide the in-shell app
menu to allow users to "move" it.
But now the remote app menu is in the process of being retired[0], and
will be replaced with a simple indicator that cannot be moved, so
stop following the GtkSetting.
[0] https://gitlab.gnome.org/GNOME/Initiatives/wikis/App-Menu-Retirementhttps://gitlab.gnome.org/GNOME/gnome-shell/issues/624
Certain keybindings should continue to work even when a popup
menu is on screen. For instance, the keybinding for showing
the app menu and the keyinding for showing the calendar are
examples.
This is achieved by putting in place a special "POPUP" action
mode, whenever a popup menu is active. This mode replaces
the (e.g., "NORMAL" or "OVERVIEW") action mode that was in place
for as long as the popup menu is active.
But those keybindings should not work when the user is at the
unlock dialog (which uses an action mode of "UNLOCK").
Unfortunately, since commit c79d24b6 they do.
This commit addresses the problem by forcing the action mode
to NONE at the unlock screen when popups are visible.
CVE-2019-3820
Closes https://gitlab.gnome.org/GNOME/gnome-shell/issues/851
We shouldn't allow toggling menus that aren't supported by the
current session mode, but as indicators are hidden rather than
destroyed on mode switches, it is not enough to check for an
indicator's existence.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/851
This keyboard works similar to GTK+'s emoji chooser (actually, both pull
from the same JSON file). Emojis are categorized in sections and variants
and kept in a "model".
The EmojiPager actor then uses this model to generate pages on-the-fly as
the user swipes around. This is an important optimization since the amount
of actors would rival with the rest of the shell otherwise.
The EmojiSelection object puts the EmojiPager, the page indicators and
a KeyContainer with the bottom row of emoji section shortcuts together to
implement the emoji panel as a whole.
The Keyboard object hooked this to an "emoji" key, which is just visible
on the Clutter.InputContentPurpose where showing an emoji would be
meaningful. Otherwise the surrounding buttons are made a bit wider to
cover up for it (i.e. as it was before).
In order to cater for emoji panel usage, we want something like PageIndicators
except:
- It should have horizontal disposition
- It should not be animatable (?)
- It should not be reactive
Separated PageIndicators into a base, non-animated widget, and an
AnimatedPageIndicators that can be used on appDisplay.js. Reactiveness is
set through an extra method, and layout is set as a construct argument.
This will be useful as we want other panels (eg. emoji) to preserve aspect
ratio with the rest of the OSK. Separate the aspect ratio management logic
into this container that will be the parent of them all.
Since commit 447bf55e45 we turn the top bar translucent when
free-floating. While this looks fancy and reduces the appearance
of cutting into the available screen space, it has also had a
negative effect on legibility.
Nobody stepped up to address those issues in two years, so revert
back to the fully opaque top bar.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/408
While the current textual forecast is non-intrusive, it may be too
much so, making it less effective to spot the current conditions
at a glance.
Refresh the section to use a more conventional graphical representation,
similar to the one used by gnome-weather itself.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/262
Having Unity-like shortcuts for activating the first nine applications
in the dash has been a long requested feature, but somehow nobody got
around to implement it.
As the shortcut is most useful outside the overview where the dash is
not visible, only consider favorite apps as they have a predictable
order.
https://bugzilla.gnome.org/show_bug.cgi?id=648000
Since the overlays we show on hover above the window clones are no
longer only a close button, but the window title, a border and a close
button, rename a few variables so it's easier to understand what they're
for.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/346
In order to replace GTK+'s GtkDirectionType. It's bit-compatible with it,
too. All callers have been updated to use it.
This is a purely accessory change in terms of X11 Display usage cleanup,
but helps see better what is left.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/317
In order to replace GTK+'s GtkPolicyType. It's bit-compatible with it, too.
All callers have been updated to use it.
This is a purely accessory change in terms of X11 Display usage cleanup,
but helps see better what is left.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/317
This is actually papering over bugs in toolkits. On X11 the Xserver will
send crossing events when the stage input shape changes. As those go
end up ignored in GTK+, this warp call aims (and randomly manages) to send
a motion event that wouldn't go unlistened by the drag source window (the
one holding the grab).
This bug actually manifests in other ways, eg. by changing the window
beneath the pointer with alt-tab while DnDing. This should be fixed
altogether in the client side.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/317
This gdk_display_sync() call was added in commit a40daa3c22 so the alt-f2
dialog is able to spawn commands that trigger grabs on startup (eg. xmag/
xkill).
This seems worthwhile to do only on the X11 backend, and handling it in
mutter backend code seems cleaner.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/317
Allow notifications to set a x-gnome-privacy-scope hint, with values in
['system', 'user']. If all the notifications in a particular source hint
that their privacy scope is ‘system’, don’t hide the notification
details on the lock screen.
This is aimed at fixing the particular case of power notifications: they
contain information which is not private to the user (it relates to the
system: battery state or AC state, which is obvious to anyone who can
see the machine), so hiding the details of a power management
notification when the screen is locked is pointless.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/gnome-shell/issues/726
Most often it is a bug if the condition part of a for-loop contains the
assignment operator rather than the comparison one, so tools rightfully
emit a warning.
Clarify that the assignment is intentional in this case by adding
parentheses.
Spotted by eslint.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/375
Just like the "in" operator in the previous patch, "instanceof" has
a lower precedence than negation, resulting in the nonsense condition
of "true instanceof BaseIcon".
Add parentheses to get the intended behavior.
Spotted by eslint.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/375
The "in" operator has a lower precedence than negation, so we are
actually testing whether the favorites map contains "false".
Add parentheses to get the intended behavior.
Spotted by eslint.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/375
The Magnifier class uses a small subtree of actors to track the
current cursor's position and sprite. Specifically, it uses the
deprecated ClutterTexture to paint the cursor sprites.
Add a new, very simple ClutterContent implementation to track the
cursor sprite, and replace the ClutterTexture by a ClutterActor.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/371
The last patch in the series, this one adapts StShadowHelper
to received a CoglFramebuffer. This is where we first touch
JavaScript with Cogl types, and as such, it depends on the
latest Mutter. Earlier versions of Mutter didn't have its
Mutter-Clutter GIR to generate types for various Cogl types.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/283
With the recent port to JS6 classes, the trailing
comma after functions in the syntax of classes has
been removed.
However commit c2961f21 accidentally reintroduces
one trailing comma after a newly created function,
leading into g-s throwing an exception and not
starting anymore.
Therefore, remove this trailing comma to solve
this problem.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/366
Besides the device grab on the drag device, also set up a captured-event
handler to catch other devices (except the keyboard) while the DnD
operation is ongoing. This makes DnD operations exclusive to others.
Also, disallow it in less aggressive ways if maybeStartDrag() gets called
while there is a current draggable.
This might definitely be nicer (eg. having other grabbed devices emit
leave/end events), but can't be done without major surgery to Clutter.
In the case where the draggable has an actor of its own, state could be
left broken when dragging on a place that would not accept the DnD op.
After button release, drag state is set to "cancelled" and the animation
begins. After the animation is finished, the drag actor would be destroyed
before disconnecting from its destroy handler.
Within the destroy handler, the grab would be undone but drag state would
be left on "cancelled" state for subsequent operations. This results in
DnD oddities and stuck grabs.
In order to fix this, double check in the actor destroy handler that we
are actually dragging before setting the "cancelled" state.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/540
Instead of fetching the CLUTTER_POINTER_DEVICE device. It will
be wrong if drags get initiated from tablet pointers. This allows
for DnD operations to be started, moved, and more importantly
finished through tablet devices.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/540
Whenever the AllView needs (re)populating, we used to do one general
g_app_info_get_all() to get all GAppInfo, plus one per app folder in order
to check the ones that fall within that category. This calls results in a
fair amount of I/O blocking the main loop.
In order to ease this, keep the GAppInfo list around in AllView, and make
the AppFolders use it when figuring out the contained apps. Since reloading
the AllView results in AppFolders regenerated from scratch, the app info
list is ensured to be up-to-date for any later change within the AppFolder
(eg. through the GSettings key changing).
As the list was already filtered in the first place, we can also remove
the try{}catch() in AppFolder in order to discard desktop files with
invalid encoding.
Related: https://gitlab.gnome.org/GNOME/gnome-shell/issues/832
When connecting to a Wi-Fi router that supports the WPS button method
(PBC, push button connection) the user can simply press the button on
the router. Show an explanation in the PSK prompt when this is
possible.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/329
ES6 finally adds standard class syntax to the language, so we can
replace our custom Lang.Class framework with the new syntax. Any
classes that inherit from GObject will need special treatment,
so limit the port to regular javascript classes for now.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/361
When using dynamic workspaces, it is possible to try to change to a
non-existent one if the user defines hotkeys for changing to desktop
1, 2, 3... This case is not detected, and gnome shell shows an error:
JS ERROR: TypeError: workspace is null
actionMoveWorkspace@resource:///org/gnome/shell/ui/windowManager.js:2130:13
wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22
_showWorkspaceSwitcher@resource:///org/gnome/shell/ui/windowManager.js:2104:13
wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22
This patch adds a check before trying to change the workspace, to avoid
switching to a non-existent one.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/365
When an InputSourceIndicator is destroyed, the InputSourceManager it was
connected to could (and probably will) outlive it (since the manager is
a singleton). If the InputSourceManager emits any subsequent signals,
the callbacks from the finalised InputSourceIndicator could be invoked,
and will reference finalised objects.
This can be triggered by running `pkexec true` from a gnome-terminal
window, then calling `pkill pkexec` from another terminal (on a
different VT or via SSH). This causes the dialogue to be cancelled by
polkitd.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/357
Otherwise the user object could outlive the dialogue, emit a subsequent
signal, and the callback from that signal could reference finalised
objects/widgets from the dialogue. The likely mechanism for the user
outliving the dialogue is caching of user objects within
libaccountsservice.
This can be triggered by running `pkexec true` from a gnome-terminal
window, then calling `pkill pkexec` from another terminal (on a
different VT or via SSH). This causes the dialogue to be cancelled by
polkitd.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/357
Rather than explicitly destroying the session after calling close(),
destroy it from the `closed` signal handler.
This also means we can make the method internal.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/357
In case there are any internal ways the dialogue can close itself
without calling its own close() method, it’s probably better to do all
our cleanup on a handler for the `closed` signal instead.
This should introduce no functional changes except ensuring the
polkitAgent cleanup is always done.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/357
Otherwise the session could outlive the dialogue, emit a subsequent
signal, and its callback would reference finalised objects/widgets from
the dialogue. The PolkitSession object is implemented by
libpolkit-gobject, so we have no guarantees about its reference counting
— the session object could keep itself alive in another thread, or be a
singleton. In all likelihood, the session hangs around for longer than
the dialogue due to differences in when the two objects are garbage
collected.
This can be triggered by running `pkexec true` from a gnome-terminal
window, then calling `pkill pkexec` from another terminal (on a
different VT or via SSH). This causes the dialogue to be cancelled by
polkitd.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/357
This avoids the following warning sometimes happening later:
JS WARNING: [resource:///org/gnome/shell/ui/search.js 701]: reference to undefined property "searchInProgress"
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/357
The built-in calendar isn't meant to replace a full-fledged calendar
app, which is why clearing event messages only hides the event in
gnome-shell rather than deleting the actual event. This has turned out
to not be overly useful and often confusing - it creates a discrepancy
with visible events in apps, isn't revertible in a non-obscure fashion
and non-obviously limited to the current date.
As we are considering moving events out of the message list and back to
the calendar, it looks like a good time to remove that ability and keep
notifications as the only removable messages.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/262
We currently deliberately avoid chaining up in derived policy
constructors to not override properties with their defaults.
That's a neat trick that will stop working when porting to ES6
classes, as chaining up is necessary to actually initialize the
object there (including "this").
Address this by turning all properties into (overridable) getters
that are backed by private properties by default.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/350
The _createPolicy() method of a subclass usually depends on some
constructor parameters that need to be set before chaining up to
the parent. This works fine with Lang.Class, but will break with
ES6 classes, as "this" is only initialized after chaining up.
Prepare for this by not creating the policy in the constructor,
but when it is first accessed.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/350
Check via Polkit if the current user is actually allowed to enroll
devices before trying to do so. If not, show a notification that
explains that a system administrator needs to authorize the device.
Clicking on the notification will guide the user to the thunderbolt
control center panel. Before this patch, when the current user was
not allowed to enroll a device a polkit dialog would pop up which
is confusing because it did not contain any information why it was
shown. This patch implements the behavior as designed (see [1],
section "Multi-user environments").
[1] https://wiki.gnome.org/Design/Whiteboards/ThunderboltAccess
Since commit 5fb8d4f730, a NotificationMessage's notification property
is reset to null when the notification is destroyed. However at that
point we still have connected signal handlers around that we'll try
to disconnect later.
Avoid the warnings by disconnecting and resetting the handler IDs at
the same time as the notification.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/308
In contrast to generic animated icons, it is reasonable to expect
spinners to be invisible while inactive. Implement that behavior
in the new Spinner class and optionally animate the transitions.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/316
If the session mode doesn't allow access to Settings, the language
menu should respect that and not expose the "Region & Languages"
panel. Using the dedicated method instead of manually constructing
the menu item takes care of that and makes for less code.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/780
The picked target actor may be destroyed (e.g. hover style change
resulting in the ClutterTexture to be destroyed). If we don't handle
this, GJS will abort when it sees the exception caused by Javascript
code trying to access the destroyed target actor.
To handle it, listen on the 'destroy' signal on the target actor, and
repick, so a valid actor is passed to the next motion callback.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/632
When a fullscreen application is focused,
toggling the overview via hot-corner is disabled,
even when the overview is currently visible.
This only makes sense, when the overview is
hidden to not to disturb the behaviour of the
fullscreen application, but leaves an
inconsistency when the overview is visible since
it should work there like when a non-fullscreen-
application is focused.
So, always allow hiding the overview using the
hot corner when the overview is visible.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/429
Add a D-Bus API that allows the API user to introspect the application
state of the shell. Currently the only exposed information is list of
running applications and which one is active (i.e. has focus).
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/326
The intention of commit 4dc20398 was to disable unredirection while
banners are shown, but the ::done-displaying signal currently used for
re-enabling unredirection is only emitted under some circumstances, so
it's possible that unredirection is left disabled indefinitely, whoops.
Fix this by tying disabling unredirection explicitly to the lifetime
of the banner actor.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/799
The only reason for `vfunc_paint` and `vfunc_pick` existing was to
implement a culling optimization. Although that optimization actually
made performance worse than none at all because it forced the painting
and picking cycles to spend more time calling into JavaScript.
Turns out we don't have to choose between native code and culling though.
Just reimplement the culling using native ClutterActor functions and we
get the benefits of both.
Performance on an i7-7700:
Moving the cursor over the icon grid:
Before: 70% CPU, 5.5ms per frame
After : 60% CPU, 4.5ms per frame
Scrolling the icon grid:
Before: 60% CPU, 4.4ms per frame
After : 50% CPU, 3.3ms per frame
Helps with https://gitlab.gnome.org/GNOME/gnome-shell/issues/174
Destroy the DashItemContainer's child from the same handler as the tooltip. This
will prevent invalid reads when the item is destroyed while its quicklist is
still open.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/781
Back in the day, there was a proposed system of tracking apps in a
specific context.
The inspiration was that you may have used apps in multiple modes:
Firefox may have been used in both "Programmer Reference" and
"Kitten Videos" contexts. Early user response to the feedback wasn't
too positive - context switching is something that humans have trouble
doing implicitly, let alone explicitly. The old codebase still has a
few remnants of this around; let's finally put them to rest.
Note that we still write out a dummy context tag to the XML file - old
versions of the shell will flat out crash if you don't have one of those
in there, so just leave it in for compatibility sake.
https://bugzilla.gnome.org/show_bug.cgi?id=673767
The pending-charge state means AC power is on but the battery is not
being charged. This can happen because its charge is above a certain
threshold, to avoid short charging cycles and prolong the battery's
life, or because the PSU is not powerful enough to charge the batteries.
Instead of lying to the user about something being estimated, we should
simply tell the truth and set the label to "Not Charging".
Closes: #701.
When we started to only show a single caption at a time, we allowed
title captions to be wider than their corresponding window preview.
But while overlapping neighboring previews is fine, we shouldn't
allow the captions to leak outside the workspace area itself and
overlap unrelated elements like workspace switcher or dash.
This partly reverts commit b3b30f239d.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/214
Instead of defaulting to a natural scroll behavior,
have the workspace switch action use the natural-scroll setting
in org.gnome.peripherals.touchpad to determine the correct
direction of travel when swiping. 4 finger swipes will then
match the behavior of the rest of the UI.
Reference: https://gitlab.gnome.org/GNOME/gnome-shell/issues/516
While this sounds counter-intuitive, the image-path hint value might also
be used with URIs or icon names.
As per freedesktop standard:
The "app_icon" parameter and "image-path" hint should be either an URI
(file:// is the only URI schema supported right now) or a name in a
freedesktop.org-compliant icon theme (not a GTK+ stock ID).
Thus the image-path hint should also be parsed as it happens for the
app_icon.
Reuse same logic, by falling back on _iconForNotificationData with the
hint value.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/285
We have a callback that will call close() when the notification is
destroyed, and a callback that will call destroy() on the notification
when the message is closed.
Currently, if the notification is destroyed we'll execute our callback
that will call again destroy() on the notification. That's bad
practice in general, and it also has the side effect of resetting the
destroy reason.
This commit avoids re-destroying the notification by dropping the
notification reference on destroy.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/258
Differently from the fd.o notifications, Gtk notifications do not
have a mechanism to update themselves. Instead, when a new
notification is received for an ID already known to the notification
daemon, the old notification is dismissed and a replaced with a new
one.
Currently though, there is no way to distinguish a notification that
was dismissed because of an user interaction, or because it was
replaced. That is an useful piece of information, so add a new value
to the NotificationDestroyedReason enum to account for it.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/258
When gnome-shell receives the signal of 'set-content-type' from ibus,
gnome-shell calls KeyboardManager.holdKeyboard() and
KeyboardManager.releaseKeyboard() and the functions change the current
input focus in GNOME Xorg and it could result in closing a popup window
which has a password entry by focusing on the entry.
The solution is to stop to call the APIs on 'set-content-type' signal.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/391
We don't usually show notification banners while the monitor is in
fullscreen, but when we do - the notification is urgent - we should
actually show the banner, even if the top-most window is unredirected.
To achieve that, disable unredirection while the banner is showing.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/430
The `reactive` property of icon actors was being restored multiple times
over the course of the pulse animation, all at slightly different times
as each icon finished animating at different times.
The problem is that toggling `reactive` on an `StWidget` incurs a style
change of the `insensitive` pseudo class, and style changes would quickly
queue relayouts incurring full stage reallocation. This occurred many times
during a pulse animation, limiting its smoothness and performance.
The solution is to not toggle the `reactive` property in the pulse
animation at all, which avoids incurring multiple full stage relayouts.
As a bonus, this means the icon under the cursor pulses with the correct
selection highlight, appearing more seamless and responsive.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/261
The `reactive` property of icon actors was being restored 24 times over
the course of the spring animation, all at slightly different times as
each icon finished animating at different times.
The problem is that toggling `reactive` on an `StWidget` incurs a style
change of the `insensitive` pseudo class, and style changes would quickly
queue relayouts incurring full stage reallocation. This occurred many times
during a spring animation hogging the CPU and limiting the frame rate.
The solution is defer and batch the cleanup for all icons until after the
last icon has finished animating. This way the CPU impact of the style
change and stage relayout isn't felt during the animation so the frame
rate remains higher and smoother. The overall CPU usage of the animation
is also reduced as the remaining relayouts are much more likely to be
grouped into a single frame.
Icon spring animation performance on an i7-7700:
Before: 83% CPU and 47 FPS
After : 78% CPU and 54 FPS
which is about a 22% increase in performance per clock (FPS/CPU).
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/253
The switcher popup is a large, mostly transparent actor that
should cover all the clickable area of GNOME Shell. In Clutter
terms, it should cover the whole stage.
By binding it to the primary monitor, the Alt+Tab behavior
becomes a bit inconsistent. For example, by not hiding when
clicking at empty spaces at other monitors.
Fix that by binding the SwitcherPopup to the whole stage,
and not only the primary monitor.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/647
If no password or a wrong password is entered after automounting an
encrypted device, then the password should be reasked. However, this
does not happen because the relevant udisks error messages for this
cases are missing in the exception handler that calls _reaskPassword.
Fix this issue by adding the relevant udisks error strings to the
exception handling in the _onVolumeMounted method.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/640
We currently only ignore minimized windows, not windows that are
hidden for other reasons - namely on wayland windows are initially
hidden until they are placed.
This fixes a flicker in the transparent top bar on wayland when the
"position" of an unplaced window wrongly suggests the window is
overlapping the top bar.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/693
Since we started to show OSD windows on all monitors, OSD windows are
destroyed when the corresponding monitor is disconnected. We shouldn't
leave any signal handlers around in that case - they prevent the object
from being garbage collected, and trigger warnings for accessing proper-
ties of invalidated GObjects.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/602
When maxLevel is > 100%, first OSD appearance was capping the current
level to 100%. Consecutives key press were then OK.
Ensure we setMaxLevel before setting Level itself, so that correct cap
value is applied.
App folder popups take a grab when opened, and as we don't pass any
particular pushModal() parameters, all keybindings are blocked. While
this makes sense for most keybindings that would interfere with the
popup interaction, others like volume/brightness keys or screenshots
can be allowed safely.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/648
Add exception to handle a keypress if numlock is enabled as we already do for
capslock. This uses Clutter.ModifierType.MOD2_MASK because at the moment there
is not a more explicit way to refer to the numlock mask.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/550
Instead of taking care of the PanelMenu.ButtonBox.container
destruction by itself, delegate that to the very object that
created it in the first place: PanelMenu.ButtonBox itself.
This is the last remaining usage of Shell.GenericContainer
in the codebase, and posed small challenges compared to the
other removals.
A new St.Widget subclass called InputSourceIndicatorContainer
was added as a replacement to the Shell.GenericContainer. It
was needed because GNOME Shell needs to override the regular
size allocation functions, but InputSourceIndicator already
is a St.Widget with its own size allocation overrides.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/153
Because we're late in the cycle, and don't know how many
extensions actually rely on this API, this commit adds
back the BoxPointer.show() and .hide() functions, with
warning messages to notify consumers that this is going
to be removed.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/153
Pretty much like dd4709bb2, BoxPointer's show() and hide()
functions will clash with Clutter.Actor's ones.
In addition to that, on a conceptual level, the current API
is not great, because calling boxPointer.hide() won't result
in boxPointer.actor.visible == false.
For these reasons, rename show() and hide() to open() and
close(). A compatibility layer will be added in a following
commit, warning about the usage of show() and hide().
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/153
LayoutManager is currently a pure JavaScript class that
relies on the rudimentary Signals.addSignalMethods() to
handle signals. This is an inefficient implementation of
one of the most central classes in GNOME Shell.
In addition to removing Shell.GenericContainer, then,
turn LayoutManager into a proper GObject.Object subclass.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/153
In the next commit, we will turn PanelMenu.ButtonBox into a
St.Widget subclass. As a domino effect, PanelMenu.Button will
become one too, and so will Panel.AppMenuButton.
When that happens, the current show() and hide() functions in
Panel.AppMenuButton will clash with Clutter.Actor's ones.
To avoid that, rename these functions to fadeIn() and fadeOut()
and avoid a name clash.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/153
This is another straight port from Shell.GenericContainer.
The important thing to notice is that the calculation is
broken if the StThemeNode helpers (adjust_preferred_* and
adjust_for_*) aren't used.
The downside of this patch is that it removed the skip_paint
from the thumbnails. Keeping it would add an unecessarily
large amount of code.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/153
Removing Shell.GenericContainer from the IconGrid class was
challenging because it needs the "skip paint" API from it.
This API was added, too, as a workaround to the inability
to override vfuncs from GJS.
The overrides are largely copy-pasted and translated versions
of the Shell.GenericContainer code.
The IconGrid:key-focus-in signal was renamed to :child-focused
to avoid clashing with ClutterActor:key-focus-in.
In GridSearchResults, the internal IconGrid had it's y_expand
set to false, so it doesn't push other search elements (the
list results mainly) to the bottom of the screen.
Because skip paint wasn't and still isn't a GObject property,
rename it to _skipPaint to reflect that.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/153
As part of our quest to obsolete Shell.GenericContainer, IconGrid will
become a Clutter.Actor subclass. As the ::key-focus-in signal would
clash with Clutter.Actor::key-focus-in, rename it to ::child-focused.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/153
DashItemContainer currently animates the scale and opacity
of its child when zooming in. This is visible when adding
a new favorite item to the dash; the items will zoom in from
the center.
After the previous commit, however, the zoom animation got
slightly broken, and looked like the icon was coming from
the bottom instead of the center.
Fix that by setting the scale and opacity of DashItemContainer
itself, instead of its child. Remove the unused code after that
too.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/153
Pretty much like the previous patches, this extends St.Bin. The
most interesting aspect of this patch is that most of the sizing
routines of the icons is now delegated to the actors and layout
managers, removing quite a bunch of code.
The 'spacing' theme property is now redirected to StBoxLayout's
spacing property. Also adjust the Dash code to stop forcing a
potentially invalid width in the first icon too.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/153
This commit removes all the uses of Shell.GenericContainer from
SwitcherPopup.SwitcherList. Compared to the other patches, this
one was specially trickier to get right, and a few invasive
changes needed to be done.
The most noticeable one is that the allocation of the items is
done entirely by St.BoxLayout -- we don't manually allocate them
anymore. To make it work, get_preferred_width() had to calculate
the correct value. It now assumes that:
* Minimum width: the minimum width of the widest child.
* Natural width: the minimum width of the StBoxLayout (use it
instead of the natural width to force the labels to ellipsize
when too long.)
The AppIcon class became a St.Widget subclass as well, to override
get_preferred_width() and be able to keep the squared shape.
Besides that, add a new SwitcherButton class to reimplement squared
icons without having to resort to hacks in the size allocation
machinery. This class has a single vfunc override to ensure that it
is squared when the SwitcherList is.
The arrows indicating multiple windows are now in this._list
actor to the SwitcherPopup itself, since this._list automatically
manages its own children now.
At last, adapt (but preserve) the hack in CyclerPopup.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/153
Instead of overriding vfunc_get_preferred_width|height(), use the
already available Layout.MonitorConstraint to bind SwitcherPopup
to the primary monitor.
This commit turns SwitcherPopup.SwitcherPopup into a St.Widget
subclass, and gets rid of Shell.GenericContainer usage. Subclasses
were adapted to that too.
This class introduced a new challenge: it overrides show(). As per
discussions, we now call this.visible = true inside show().
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/153
In the process of purging all usages of Shell.GenericContainer
of GNOME Shell, one specific problematic situation that might
occur is when classes have functions that would clash with any
ClutterActor or StWidget function name.
One of such example is SwitcherPopup.destroy(). Right now, this
class is a pure JavaScript class that wraps a real actor, but
soon this will change, and it'll become a St.Widget subclass.
Another problem with functions that mimic the toolkit ones is
the predictability of them; after calling destroy(), that widget
is expected to not be available anymore. In SwitcherPopup case,
it is still available for a short while. In this case, that's not
a big problem, but the show() and hide() functions in other clases
are more problematic because the actor's visibility does not
follow that.
This commit is a first step in cleaning that up, and changes the
SwitcherPopup.destroy() to fadeAndDestroy().
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/153
Shell.GenericContainer exposes the size negotiation machinery
through the use of signals. Signals are not specially performant.
One of the reasons is that they acquire a global lock for signal
handlers lookup. GNOME Shell has more than 2,000 actors at any
given point in time, up to 20 levels deep in hierarchy, making
size negotiation and painting non-trivial tasks. Such a critical
section of Clutter's machinery shouldn't rely on signals
whatsoever.
Regardless of that, Shell.GenericContainer is a workaround to
a non-existing issue anymore. It shouldn't be used anyway, and
any performance improvements that removing it can potentially
yield are bonuses to it.
This commit starts this work by removing Shell.GenericContainer
usage from Panel.Panel class. The class now extends St.Widget,
and as such, it has no "this.actor" field set anymore. A couple
of places where this actor field was used are adjuste as well.
It is important to notice that we now allocate the Panel itself
inside vfunc_allocate(). This was previously done before emitting
the signal by Shell.GenericContainer.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/153
When adding a favorite, we add the ID to the list of favorites, save the
setting and add the new app to the favorites map. However as writing the
settings value already results in reload() to update the favorites map,
the new app is usually already in the map when we add it.
The only exception is when the ID was found in the RENAMED_DESKTOP_IDS map,
in which case we end up adding both the renamed app and the original one.
Fix this by simply relying on reload() to properly update the map, just like
we already do in _removeFavorite().
https://gitlab.gnome.org/GNOME/gnome-shell/issues/471
On X11, reactive chrome must be added to the input region in order
to work as expected. However that region works independently from
any window stacking, with the result that the unresponsive-app dialog
currently blocks all input in the "covered" area, even in windows
stacked above the unresponsive window.
The correct fix would be to track the unobscured parts of the dialog
and set the input region from that, but that's quite cumbersome. So
instead, only track chrome when the corresponding window is focused
(or the dialog itself of course).
https://gitlab.gnome.org/GNOME/gnome-shell/issues/273
As a mount operation's UI may be reused (for example after mistyping
the password), we only close the operation once the mount has finished
(successfully or with error).
We therefore need to track ongoing operations, which we currently do
by monkey-patching the corresponding volume object. However while the
underlying GVolume object indeed remains the same through-out the
operation, the JS wrapper object isn't referenced anywhere and may
thus be garbage collected, resulting in a stuck dialog.
Fix this issue by tracking active operations explicitly, so that all
involved objects are referenced until the end of the operation.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/565
The `hints` and `settingName` parameters to the agent call may define
the specific list of secrets NM actually needs from the user. This
seems to have been the intended use of these two parameters but only
recently did NM with the IWD backend start to use this to request 802.1x
secrets. So if `hints` is provided, ask user for the specific secrets
listed there and don't even look at what type of EAP method is in use.
Only the three types of secrets actually in use by NM's IWD backend are
supported for now -- they happen to be the same three that
_get8021xSecrets() had already supported.
This attribute was previously only assigned in show(). hide() compares
this attribute to 0. If hide() is called before show() is first called,
the comparison would give the correct result (undefined > 0 is false)
but log a warning:
JS WARNING: [resource:///org/gnome/shell/ui/workspacesView.js 529]:
reference to undefined property "_restackedNotifyId"
Initialize this attribute in _init(), alongside _scrollEventId and
_keyPressEventId which are also used in hide().
dialogContent is set to one of the elements of the list DialogContent,
but not all of those have a checkBoxText property. When logging out (as
opposed to shutting down), this causes a warning:
JS WARNING: [resource:///org/gnome/shell/ui/endSessionDialog.js
763]: reference to undefined property "checkBoxText"
(The line number corresponds to this line in 3.28.3.)
The warning is apparently not triggered if the undefined property is
used as part of a boolean expression:
gjs> var x = {};
gjs> x.a;
typein:2:1 strict warning: reference to undefined property "a"
gjs> if (x.b) { log('oh no'); }
gjs> x.c || ''
""
_setCheckBoxLabel() just checks the truthiness of its 'text' argument,
and the empty string is false-y, so passing '' rather than undefined has
no functional effect.
In recent Fedora 29, connecting to wifi access points from the
user menu (top-right menu) does not work. Clicking the 'Connect'
button just animates it but does nothing else. The logs show an
error "JS ERROR: Error: Expected type utf8 for Argument
'specific_object' but got type 'undefined'".
Looking into this, it seems the problem is these uses of the
`path` property of an NMAccessPoint. NMAccessPoint inherits
from NMObject, and NMObject *does* have a path property:
https://developer.gnome.org/libnm/stable/NMObject.html#NMObject--path
so at first glance this seems fine. But I poked around a bit
using libnm via Python (which goes via introspection, just like
this JS code does), and found that indeed AccessPoint objects
don't seem to have a `path` property there either.
Looking at the libnm code, this actually makes sense, because
the property is marked "(skip)":
https://github.com/NetworkManager/NetworkManager/blob/master/libnm/nm-object.c#L1291
and the introspection docs suggest that means it should be left
out of introspected output:
https://wiki.gnome.org/Projects/GObjectIntrospection/Annotations#Symbol_visibility
I'm a bit concerned that this was only found recently - whereas
the change to use `.path` in gnome-shell dates from October 2017
(d71af5e5) and the property has been marked (skip) in NM since
at least 2016 - but this all seems to add up. The obvious fix is
to replace use of `.path` with `.get_path()`, which returns the
path and is *not* marked (skip) and so *is* available via
introspection. I tested that this works in Python and also did
a test build of gnome-shell with this change and installed it on
an affected system, it does seem to fix the bug.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
In GNOME-3.24, pressing Super+P or a similar function key would cause
a switch to the next available monitor configuration.
However, in GNOME-3.26, this was reimplemented in mutter and gnome-shell
and the behaviour is now different: pressing Super+P and releasing will
cause no change in montor configuration[1]. In this new design you have
to press Super+P and keep holding Super in order to keep the switcher
open, then press P again (or use the arrow keys or mouse) to
select the next one in the list.
This is incompatible with many Asus products such as Asus X530UN, where
pressing the presentation mode media key (Fn+F8) actually generates
the following keypress events from the keyboard controller:
Fn pressed: nothing
F8 pressed: nothing
F8 released: Super press, p press, p release, Super release (quick burst)
Fn released: nothing
With this firmware behaviour it's not possible to hold the keys and have
the dialog come up so that you can select another new mode.
To solve this, when the switcher is opened, select the next available
display config by default, which is more similar to the pre-GNOME-3.26
behaviour. Now pressing Fn+F8 on this laptop will result in the display
mode switch taking place.
[1]: The mentioned desired behaviour will at least happen after
https://gitlab.gnome.org/GNOME/mutter/issues/281 has been fixed
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/208
Since we always keep the active workspace until the user switches
to a different one, we may end up with two empty workspaces at
the end. It's not obvious to users why this happens, and there's
indeed no good reason for the behavior - just remove the trailing
workspace in that case.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/536
Meta.ScreenDirection no longer exists. This fixes window menus on
multi-monitor systems.
JS ERROR: TypeError: Meta.ScreenDirection is undefined
_buildMenu@resource:///org/gnome/shell/ui/windowMenu.js:135:17
`NMConnectionDevice._sync()` is responsible for setting up the active
connection that we'll end up displaying. It expects the active
connection to already be in a map `_connectionItems`. If it isn't in
there, we get a null dereference and the indicator can get into a weird
state where it doesn't display devices / connections properly.
Let's change this expectation. If there is an active connection,
`_deviceAdded()` will eventually get to it and call `_sync()` to set up
the active connection state. We make `_sync()` tolerate there being no
active connection when it's called.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/140
We must remove the GFile reference from the representing object when an
extension has been unloaded as this won't be used anymore later (e.g. as cached
ref).
Throw an error using an informative message in case a mode uses a stylesheet
that can't be loaded, instead of crashing later because the theming can't be
properly computed, and thus the minimum size of the actors.
We currently assign the stylesheet to an extension whenever the file exists,
regardless of whether it actually loaded successfully or not.
And thus we load an extension that ships a stylesheet even if that file can't
be used.
There is no point in trying to load an extension if its stylesheet wasn't
loaded in the first place, so make sure this happens only on success.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/188
Ensure that the search provider operations (just getResultMetas requests
in the current implementation) in progress are properly cancelled when we
clear the UI, otherwise returned results might still be added when not
needed.
This is triggered for each provider by the SearchResults reset.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/205
Currently when the overview is hidden, any pending search is kept alive,
not only at remote search provider level (as per issue #183), but even
the shell providers proxies continue to get and process data. This happens
even if this is not needed anymore, while the UI reset is performed only
next time that the overview is shown (causing some more computation
presentation time).
In order to stop this to happen, when the overview is hidden, we have to
unset the search entry to an empty value as this would make SearchResults
to have empty terms list and that would make the proxies cancellable to
be triggered (without causing any further search to start).
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/205
If the volume is removed before AUTORUN_EXPIRE_TIMEOUT_SECS seconds, we can stop
the timeout earlier as there's nothing to unset, while the volume instance
won't be valid anymore.
https://bugzilla.gnome.org/show_bug.cgi?id=791233
The _sync function for Message only updates the close button visibility,
so we can safely stop doing that if the close button get get destroyed earlier
(as it happens when clicking on it).
https://bugzilla.gnome.org/show_bug.cgi?id=791233
We need to avoid that we use the _dragActor instance after that it has
been destroyed or we'll get errors. We now set it to null when this
happens, protecting any access to that.
Add a DragState enum-like object to keep track of the state
instead of using booleans.
Remove duplicated handler on 'destroy' and just use a generic one.
https://bugzilla.gnome.org/show_bug.cgi?id=791233
Previously mutter listened to Xsettings (via GTK) to get notified
whether the shell showed the app menu. After X11 support was changed in
the direction of being less central, listening to this particular
Xsettings were removed with the intention of having the Shell tell
mutter directly whether it was showing the menu or not.
This commit makes that happen. It still travels through Xsettings (still
via Gtk), as the shell still gets that state from Xsettings, but fixing
this is out of scope for this particular fix.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/276
Flag some actors that are good candidates for caching in texture memory
(what Clutter calls "offscreen redirect"), thereby mostly eliminating
their repaint overhead.
This isn't exactly groundbreaking, it's how you're meant to use
OpenGL in the first place. But the difficulty is in the design of
Clutter which has some peculiarities making universal caching
inefficient at the moment:
* Repainting an offscreen actor is measurably slower than repainting
the same actor if it was uncached. But only by less than 100%,
so if an actor can avoid changing every frame then caching is usually
more efficient over that timeframe.
* The cached painting from a container typically includes its children,
so you can't cache containers whose children are usually animating at
full frame rate. That results in a performance loss.
This could be remedied in future by Clutter explicitly separating a
container's background painting from its child painting and always
caching the background (as StWidget tries to in some cases already).
So this commit selects just a few areas where caching has been verified
to be beneficial, and many use cases now see their CPU usage halved:
One small window active...... 10% -> 7% (-30%)
...under a panel menu........ 23% -> 9% (-61%)
One maximized window active.. 12% -> 9% (-25%)
...under a panel menu........ 23% -> 11% (-52%)
...under a shell dialog...... 22% -> 12% (-45%)
...in activities overview.... 32% -> 17% (-47%)
(on an i7-7700)
Also a couple of bugs are fixed by this:
https://bugzilla.gnome.org/show_bug.cgi?id=792634https://bugzilla.gnome.org/show_bug.cgi?id=792633
Instead of consuming the event in front of the input method. Enter
is sometimes overriden by those, so it seems better to let the IM
handle the key event, and react later to it if it got propagated
anyway. That is what ::activate does, so use this signal.
This used to work before ClutterInputMethod/InputFocus because the
IM received the events directly from stage captured events. This
is not the case anymore.
Closes: #440
We used to keep the workspace switcher slid out when the user made use
of workspaces. This was changed in commit 2d84975 to give more space
to window previews, but it turned out to make the switcher quite a lot
more difficult to interact with (rather than only being a question of
discoverability). So go back to the previous behavior.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/161
During global grabs, actors miss enter and leave events required
for correct hover tracking. This can cause the workspace switcher
to get stuck while slid out, so ensure the actor's hover state is
synced after drag operations.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/161
We show a cover pane on top of the overview during transitions to
prevent issues caused by clicks and mouseover events when the overview
is not ready. Right now, this pane is only being shown on the primary
monitor, which obviosly allows interactions to happen before the
animations are finished on the secondary monitors.
To fix this, use the size of the whole stage for the cover pane.
Emitting it that soon results in JS warnings, as we don't have
everything in place yet. The position-changed signal will be
emitted from other locations as soon as we have it.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/464Closes: #464
When trying to close a window in the overview by clicking the close
button and the window doesn't get closed but a dialog is added to the
window afterwards, we close the overview and show the dialog.
Instead of adding a separate listener for the window-added signal to the
WindowOverlay, let the WindowClones remember that the close button was
pressed and activate themselves if a dialog is added after that.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/180
When a dialog is added to a window while the overview is shown, we get
its parent using get_transient_for() so we can add it to the right
window clone.
If we have multiple layers of dialogs we have to do this recursively
until we find the root ancestor. This case currently results in an
infinite loop: Since parent is always set to the same window, the
while-condition will always be true.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/180
For the OSD, all parameters except for the icon are optional - if the
caller doesn't include the 'label' option, the OSD won't show a label
etc.
While this makes sense for an API, it means that we have to be careful
to correctly differentiate an option that was omitted and an option
that has a 'falsy' value like false or 0.
Unfortunately since commit ccaae5d3c we no longer do, with the result
that OSDs meant for the first monitor will show up on all, and a level
of 0 is presented as no level bar instead of an empty one, whoops.
https://bugzilla.gnome.org/show_bug.cgi?id=791669
GSettings now recognizes per-desktop overrides that can be used
to change schemas' default values for a particular desktop. This
is not entirely unlike our existing custom override mechanism in
mutter, except that it is not limited to keys in org.gnome.mutter,
and it doesn't require a separate schema - the latter means that
we (and gnome-teak-tool) no longer have to figure out the correct
schema for the current login session and just use the original one.
https://bugzilla.gnome.org/show_bug.cgi?id=786496
Show an overamplified volume icon if volume is louder the max normalized one.
Use a similar logic as gnome-settings-daemon to delimit values, restricted
to output.
The purpose is to help users remember that visiting some websites or
using some apps can get LOUD.
https://bugzilla.gnome.org/show_bug.cgi?id=790280.
Implement for barLevel an overdrive area. This is a zone represented via a
different styling to indicate that you are bypassing the normal zone of
a given level, without reaching yet the maximum limit.
https://bugzilla.gnome.org/show_bug.cgi?id=790280.
Depending on hardware and recorded volume level, turning up the speakers
to the maximum volume may not be enough and the user will want to amplify
the volume above 100%. Currently this requires opening the sound Settings
panel which gets cumbersome when required repeatedly.
To support this case better, allow raising the sound volume above 100%
directly from the system menu if the feature is enabled via the
`allow-volume-above-100-percent` key in `org.gnome.desktop.sound`.
Allow osd representing levels that can be more than 100% by accepting
an optional parameter setting that maximum level.
gnome-settings-daemon will use this to indicate volume levels above 100%,
which our own volume indicator will soon support as well.
Ensure that both barLevel and slider can support a higher maxValue than 1
and computes various positions based on it.
It defaults to 1 if not set.
https://bugzilla.gnome.org/show_bug.cgi?id=790280.
Reuse the BarLevel class to get similar drawing behavior as Slider.
Rename theme css impacted properties and ensure that the osdWindow
remains accessible.
Ensure we don't force setting a custom border color like on the OSD.
https://bugzilla.gnome.org/show_bug.cgi?id=790280.
In a9ad91c831, a bug was introduced in the following code:
```c
this._settingsAction.connect('clicked',
this._onSettingsClicked().bind(this));
```
Notice that the callback is being executed! This commit
fixes that by removing the '()' from the callback.
As strings are guaranteed to use UTF-8 in the GNOME platform, generic
file APIs like g_file_load_contents() return raw data instead. Since
gjs' recent update to mozjs60, this data is now returns as Uint8Array
which cannot simply be treated as string - its toString() method boils
down to arr.join(',') - so use gjs' new ByteArray module to explicitly
convert the data.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/179
The settings action button in the system menu simply launches
gnome-control-center, so we want its icon (and accessible name)
to always match the app. So instead of keeping the button in-sync
with Settings, just look up that information from the app itself.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/433
We can simply request the symbolic variant from CSS so that we don't
have to append '-symbolic' to all the names. This will always make
it easier to pick up that information from external sources (like
.desktop files).
https://gitlab.gnome.org/GNOME/gnome-shell/issues/433
Commit e5c95b910d refactored the workspace animation to also handle
animations that involve all surrounding workspaces, but due to an
ill-advised review comment (guess whose) it broke the animation
for non-neighboring workspaces.
Update the code to handle correctly whether in a given direction:
- we have the target workspace of a given index
- we have a neighboring workspace
- we don't need to animate anything
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/182
Add a debug command (to be executed manually via Alt+F2) to check
that all of gnome-shell's file descriptors have the CLOEXEC flag set.
This is important so that internal file descriptors do not get passed
to apps when they are launched.
It prints a warning message for every fd that does not have the flag set.
fdwalk() is used from the standard library if available (it is not
available in glibc), otherwise we use the same implementation as glib
has internally.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/132
When 4fg swipe motion happens, set up early the workspace switching
animation with all surrounding workspaces. This allows us to move
all content back and forth in any direction. This works on both
touchcreens and touchpads.
When the gesture is activated, the same data is reused to follow
up with the tween animation.
The threshold has been also doubled, it was fairly small to start
with, and feels better now that workspaces stick to fingers.
https://bugzilla.gnome.org/show_bug.cgi?id=788994
Besides the separation into distinct functions, the stored data has
been made able to generically store windows from all surrounding
workspaces. All while keeping a special mode to animate between two
workspaces (The usual till now), this is the only mode exercised so
far.
In order to ease animations, all window groups are now children of
a common container, which is then animated.
A custom callback type is more convenient, but only as long as no
other callback type is required. We are about to add functionality
that does not return the filename to a screenshot saved on disk, so
prepare for that by moving to GIO's generic async callback pattern.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/286
Fullscreen windows cannot be restored by touch device users unless the
application adds support for it.
As it is unlikely to change all application lets introduce a top edge
drag gesture which unmakes fullscreen windows.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/123
Make the indicator for active remote access use the warning color, to
indicate the severity of allowing remote access.
This only makes the indicator icon orange; the icon in the system menu
is still white.
Add an indicator for when there is something access the display server
remotely. This could be 1) remote desktop, 2) screen cast or 3) remote
control, but all effectively applications using
org.freedesktop.portal.ScreenCast or org.gnome.portal.RemoteDesktop as
well as gnome-remote-desktop using the corresponding org.gnome.Mutter
APIs directly.
As it is now, it'll simply show a single icon for when anything is
having an active session, and a single action "Turn off" that'll close
every active session.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/160
If we're started by systemd, we won't be in the user's display session.
However, this is still the session that will get locked & unlocked. Ask
logind what the 'display' or 'greeter' session is, and watch for the
Unlock signal for that session to know when to unlock.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/137
For windows, the cursor location needs to be adjusted by the frame
offsets. However we cannot assume that there is a window, as the
shell itself can have the key focus.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/414
Maximized and tiled windows can be restored with a drag gesture,
not only from their titlebars, but also from any non-reactive
parts of the top bar above the window. Currently this only works
for actual pointer devices, extend the behavior to handle touch
as well.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/112
If the Escape key is used for a window/app cycler/switcher shortcut
(such as "Switch windows directly"), then there is no way to cancel
the switching/cycling operation with the keyboard.
This change allows cancelling such an operation by pressing the Tab
key, but only if Tab is not already being used by the current
switcher/cycler shortcut.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/315
Key events involved in a keyboard shortcut are not completely consumed by
Mutter. That means that if the popupMenu is bound to a shortcut (e.g.
Alt<Space>) and the user keeps the keys pressed, the same key-event will be
delivered to the popupMenu. We can workaround this issue filtering out all the
events where a a modifier is down (except capslock).
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/372
Destroying and recreating the entire events list on every change is not only
wasteful, it also breaks the clear functionality as messages scheduled for
removal are replaced with "new" messages after the first message has been
removed.
Address both issues by keeping track of all messages and re-use them
whenever possible.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/325
And stop using FocusCaretTracker for caret position purposes. This
new object uses 1) the text-input protocol in wayland and 2) Info
from IBusPanelService for X11 (which is meant to work for XIM too).
This drops the usage of AtspiEventListener for OSK purposes, which
is best to avoid.
If a clone gets destroyed before the corresponding MetaWindow is
removed from the workspace, we will still find it in the list of
clones and try to destroy it again. Avoid the resulting warnings
by updating the list of clones immediately when a clone is destroyed.
https://bugzilla.gnome.org/show_bug.cgi?id=791233
If a clone gets destroyed before the corresponding MetaWindow is
removed from the workspace, we will still find it in the list of
clones and try to destroy it again. Avoid the resulting warnings
by updating the list of clones immediately when a clone is destroyed.
https://bugzilla.gnome.org/show_bug.cgi?id=791233
Remove any usage of MetaScreen, as it has been removed from libmutter
in the API version 3. The corresponding functionality has been moved
into three different places: MetaDisplay, MetaX11Display (for X11
specific functionality) and MetaWorkspaceManager.
https://bugzilla.gnome.org/show_bug.cgi?id=759538
This may be the case where keyboardIndex is -1, which may be the
case where either the keyboard monitor hasn't been set yet, or
the keyboard is being unmanaged and meta_window_get_monitor
returns -1
https://bugzilla.gnome.org/show_bug.cgi?id=788882
When middle-clicking an app icon on the Dash, it will always try to open
a new window of that app, even if the app doesn't support multiple
windows. Meanwhile, Ctrl+click on an app will only open a new window if
the app allows it.
This change prevents middle-clicks on app icons from opening new windows
for apps without multi-window support.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/316
When the actor that has the key focus is destroyed, Clutter moves
the focus to the stage. In case the destroyed actor was inside a
ModalDialog, this breaks any keyboard interaction: keynav is broken
because the stage isn't in any focus chain, and access keys like
Escape because they are handled on the dialog's parent.
The only dialog that may destroy a child without recreating the dialog
buttons (and thus moving the key focus there) is the WirelessDialog,
fix it by keeping the key focus within the dialog when removing networks
from the list.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/76
Just like we did for the window list in app icons' context menu,
provide a fallback for window captions in the window picker rather
than showing blank items to the user.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/26
The app icon's context menu contains a list of open windows,
identified by their title. As we currently don't handle the
case where the app didn't set a title, we end up with empty
menu items which looks clearly broken. Fall back to the app's
name in that case.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/26
The close dialog for non-responding windows is closed automatically
when we detect that the window is responding again. However as we
currently only ping the window in response to certain user actions
(like focusing the window or opening the window menu), this can
easily go undetected.
Address this by periodically pinging the window while the close
dialog is shown.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/298
The dialog won't be visible when unredirection is in place (for example
while a fullscreen window is focused), so disable unredirection while
the dialog is up.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/298
Similar to what it's done when the main connection changes, we need
to make sure that the icon in the panel gets updated before calling
_syncConnectivity(), so that the icon gets always updated if needed,
regardless of whether there's an active connection or not.
This is needed because there's at least one case when an icon should
be shown when the computer is not connected to any network: when a
hotspot has been enabled, which can be useful even if there's not
an internet connection to share (e.g. to easily allow connecting
other devices to the computer.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/214
While the libnm-glib version of the function returns a GByteArray*
that gjs can directly cast to the required gutf8*, the libnm function
returns GBytes* from which we need to explicitly fetch the data.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/136
Commit f285f2c6 changed Scripting.createTestWindow() to accept a parameter
object instead of a parameter list but forgot to remove the width and height
arguments. This breaks the "core" test as all windows are created with default
settings.
We use the close() method to disconnect signal handlers set up in
init(), however the handler ID is only valid in the first call in
case the method is called more than once.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/221
If we get an error during device enrollment, the message might be
prefixed to indicate that the error came from the remote peer. We
are presenting that message to the user so strip that prefix away
if it was there.
The devices emitted (device, error) while the connected handler
was expecting (error, device). The former is more consistent
with the rest of the code (so change it to device, error).
Modes, extensions and other GNOME Shell assets are searched in appropriate
subdirectories of each directory in XDG_DATA_DIRS, falling back
to global.datadir.
However, this isn't the case for themes, which are currently always expected
in global.datadir, even when referenced by a mode in a different XDG_DATA_DIR.
The fix is to have the theme finding pattern follow the same logic as other
elements.
Fixes#167.
The HIG discourages the use of icons in menus except for "noun" items
(files, bookmarks, ...). While those should be rarely used in the
application menu, it still makes sense to support them in the few
cases where they are used.
https://bugzilla.gnome.org/show_bug.cgi?id=760985
Otherwise it happens that porthole is computed again after that the
overlay is hidden (triggered by a layout reallocation) and thus not
regenerated again afterwards.
https://bugzilla.gnome.org/show_bug.cgi?id=792687
Since commit 78a92fb6be we no longer pop up authentication dialogs
on the lock screen, however any dialog that is already open at that
time remains open. This is unexpected, so hide the dialog until
the screen is unlocked again.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/166
Since commit 1939e22c22, we move the keyboard focus with the hover
highlight. However while this makes sense when interacting with
the window picker, it interferes with keyboard navigation of other
components like dash or top bar. Address this by only moving the
focus when the previous focus was already inside the window picker
or unset.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/50
The original UTC support in GWeather piggy-backed on the existing API, but
as "country" or "city" don't make sense in the context of UTC or AoE, the
concept of "named timezones" was introduced. Handle those explicitly to get
back labels for those locations.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/150
We don't toggle the overview if the request happens too close to the
last activation, to filter out double-clicks or activation by both
the hot corner and a click. However as the check is based on the
real time, the check breaks if the system clock moves backwards and
the last activations appears to be in the future. Fix this by using
monotonic time which is guaranteed to only move forward.
https://bugzilla.gnome.org/show_bug.cgi?id=763886
While polkit requests *should* be the result of a user action, that's
not always the case in practice and authentication dialogs can pop up
out of nowhere at any time. That's always annoying, but particularly
bad on the lock screen. If we disabled the polkit component altogether,
the fallback GTK-based agent would kick in, so instead handle the case
explicitly and postpone showing the dialog until the session is unlocked.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/179
boltd 0.2 gained a property that indicates if it is authorizing
devices or not. If it indeed is not authorizing then we wont
try to enroll new devices because that would otherwise lead to
and error.
When we move keyboard focus to the search entry, we replay the key press
that triggered the move to the entry using ClutterActor's event() method.
Since commit 3b293e91e we specify that the event is in the capture phase
to make it work with StIMText, but now that commit 83accce24 removed it,
we have to return to the expected non-capture flag that matches the orig-
inal event to unbreak find-as-you-type functionality.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/72
Find-as-you type was never automatically handled by StIMText, but
by the existing stage key-press handler. The functionality broke
for a different reason, we will fix it after reverting the recent
captured-event changes.
This reverts commits bc4462cd0c and e4ee944d8d.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/72
Since commit c4f2bb5f, close buttons are hidden by making them fully
transparent rather than setting their visibility to false to keep
the overall message layout stable. As a result, the buttons now work
even when invisible, which is clearly unexpected - fix this by updating
the reactive property appropriately.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/66
When not using arrow notation with anonymous functions, we use Lang.bind()
to bind `this` to named callbacks. However since ES5, this functionality
is already provided by Function.prototype.bind() - in fact, Lang.bind()
itself uses it when no extra arguments are specified. Just use the built-in
function directly where possible, and use arrow notation in the few places
where we pass additional arguments.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/23
imports.misc.ibusManager.IBus is declared as const, so referencing it
from another module triggers a warning with recent mozjs. As of commit
083d11a032 IBus is mandatory, so just make it a regular import to avoid
the warning.
This is pseudo-class is added on .shift-key-uppercase whenever the shift
state is latched, a matching selector would be:
.keyboard-key.shift-key-uppercase:latched {}
https://gitlab.gnome.org/GNOME/gnome-shell/issues/46
Drop the UTF8 glyphs from those, and add style classes so those can be
specifically themed and given a background image. The style classes are:
.keyboard-key.enter-key{}
.keyboard-key.shift-key-lowercase{} /* applies while lowercase */
.keyboard-key.shift-key-uppercase{} /* applies while uppercase */
.keyboard-key.layout-key{}
.keyboard-key.hide-key{}
https://gitlab.gnome.org/GNOME/gnome-shell/issues/46
Do the finicky checks to adjust key widths and whatnot based on other
values than the label. This makes the label exclusively used for
presentation (i.e. setting up a St.Label).
https://gitlab.gnome.org/GNOME/gnome-shell/issues/46
Instead of latching all states, make shift unlatched by default, and only
latched when making a long press on the key. When not latched, the keyboard
will switch to the first level (alphabetic lowercase) after the first key
press.
Also, move the actual level switch to Key::pressed, so it feels more
reactive on long press.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/46
It was mistakenly connecting twice to the 'released' signal. Also, move
level changes to key release, since it will be more convenient to hook
latched states on long press.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/46
These objects created this.actor being the St.Button, and a surrounding
this.container actor that is the actual actor callers care about. Turn this
around and make this.actor be the parent-less actor, and this.keyButton the
contained internal button. This is more consistent with gnome-shell style.
Commit 8fdf47ea5b removed _addKeys(), but forgot one caller. We just want
to regenerate the keyboard for the current group, so call into the
_onGroupChanged function.
While the scale factor is taken into account for app icons, we set
an explicit size when combining the into a folder icon - unless we
take the factor into account, the result will be too small on HiDPI
displays.
https://bugzilla.gnome.org/show_bug.cgi?id=792259
The captured-event handler just redirects focus there on the first keypress,
what it doesn't account for is that other entries may be active while the
Activities overview is opened (eg. alt-f2, or other modal dialogs). Play
along with other entries, and make it only steal focus if no other entry
is selected.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/33Closes: #33
Similar to what has been done for the apps switcher, this allows closing
windows pressing W or F4 while operating the windows switcher popup or
the apps switcher popup while navigating the list of windows for an app.
https://bugzilla.gnome.org/show_bug.cgi?id=620106
This will be mainly useful for closing apps from the applications
switcher, but can be implemented generically enough to select the
nearest existing item after removal if there's any, or destroying
the popup's actor otherwise.
Specifically for the apps switcher, doing this also removes the need
of having to manually either update the current app in AppSwitcher
and highlight it, if there are still any items after the removal, or
simply destroy the AppSwitcher otherwise. Besides, calling _select()
in the handler for item-removed makes sure that the list of thumbnails
in the switcher is always closed, if open, when quitting the app.
https://bugzilla.gnome.org/show_bug.cgi?id=620106
Make sure that the items from the applications switcher and the windows
switcher are removed when the related applications get stopped, or some
of the associated windows closed.
https://bugzilla.gnome.org/show_bug.cgi?id=620106
glibc 2.27 introduced new format specifiers for the month names.
It's obligatory to use them in several languages already and it's
encouraged to use them for all languages because it is not destructive
for any language. As more languages are expected to follow this
standard it's better to use the "%OB" format specifier now so it will
start working correctly automatically.
See also: https://sourceware.org/bugzilla/show_bug.cgi?id=10871
This standard has been also working in BSD and OS X since 1990s,
if anyone tries to use gnome-shell in these systems.
Note: This will not work correctly with glibc < 2.27, there is no
detection whether the system is old or new.
https://bugzilla.gnome.org/show_bug.cgi?id=780957
We keep track of the lock state and restore it on startup to prevent
a crash from bypassing the screen lock. However on wayland, a crash
doesn't result in gnome-session restarting gnome-shell, but brings
down the entire session - that is, restoring the lock state does not
actually protect the existing session in that case, but forces the
user to authenticate twice in order to start the next session. This
is clearly not helpful, so avoid this by not saving the state when
running as wayland compositor.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/17
Align and center the date entry with the workspace's workarea.
This way, maximized applications have their window aligned with the top date
entry.
This doesn't change anything for desktops with no docks or when left/right
workareas are aligned with the monitor.
The offset is leftOffset - rightOffset:
(workArea.x - monitor.x) - (monitor.width - ((workArea.x - monitor.x) +
workArea.width))
https://bugzilla.gnome.org/show_bug.cgi?id=792354
We will now basically act as "policy provider" for thunderbolt
peripherals by using org.freedesktop.bolt service: when new
devices are connect and session is a unlocked user session
we will automatically enroll (authorize and store in the database)
them.
If new devices are connected but the session is locked a message
will be shown informing the user that the device needs to be
reconnected to properly work.
The org.freedesktop.bolt service is provided by the "bolt" daemon.
Currently the language options displayed pretty much mirror those of the
top bar keyboard layout selection popup. It may make sense in the future
to only list languages, and automatically switch to the enabled IMs that
the OSK can benefit from (eg. by filling in suggestions).
The focused window will move up/down together with the OSK if the focus
area happens to be covered by the area to be covered by the OSK. This
state is reverted whenever the window loses focus, given it wasn't
relayout in between.
We do not need the parent Keyboard object to handle those specially, the
code can be self-contained enough. The Key object will simply emit
pressed/released events containing the keycode/string, be it from the
parent key or one contained in the BoxPointer.
StIMText used to handle key events for IM consumption in the capture phase,
this made the search box work automagically with nothing explicitly focusing
it. Since it's no longer the case, it has to be done somewhere.
Instead of manually resizing each key everytime the keyboard needs to
relayout, have a special grid container that will preserve aspect when
resized.
This actor works in two stages though, first the keys need to be added
and then layoutButtons() need to be called for the actors to be
reparented to the container with the right attachment options.
This is a ClutterInputMethod implementation using IBus underneath. The
input method will interact with the currently focused ClutterInputFocus,
be it shell chrome or wayland clients through the text_input protocol.
The keys possibly need resizing after a (new) layer has been set, there's
however calling places that don't. Instead, fold this._redraw() into
setActiveLayer().
Getting the necessary "setting enabled, or input from touchscreen"
conditions to have the OSK shown are not enough on the lack of a
current focus. As we are setting up the caret tracker here, wait for
the focus in event before showing the keyboard.
This fixes 2 issues, with the setting disabled it became really hard
to get the OSK hidden on eg. touchscreen->pointer device switches,
as visibility only depended on the a11y setting here. And secondly,
enabling the setting would always end up with the OSK being shown
regardless of focus, while it should stay hidden if there's no text
edition.
https://bugzilla.gnome.org/show_bug.cgi?id=788188
If the underlying X11 input driver creates multiple devices from a single
device node, we may end up picking up the wrong device. So, instead of
picking the first device based on node and bailing out if it's not a pad,
pick the first pad that has that device node, and bail out if there is
none.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/10Closes: #10
It turns out that NetworkManager does export the directory as pkg-config
variable after all, so use that instead of building the path ourselves
from the prefix.
https://bugzilla.gnome.org/show_bug.cgi?id=789811
We want touch events to enable the keyboard and focus tracking, but
not to actually show it right away. Implement that behavior by only
changing the visibility of the keyboard when triggered by a GSettings
change.
https://bugzilla.gnome.org/show_bug.cgi?id=788188
We enable the keyboard when it is either enabled explicitly via
a11y settings or when using a touch device. We'll soon want to
special-case changes to the GSettings, so track its value in a
dedicated property.
https://bugzilla.gnome.org/show_bug.cgi?id=788188
When the agent doesn't work (e.g. when the screen is locked), it shouldn't be
registered with NM. Otherwise it will keep cancelling the requests that
could happily be serviced with system secrets.
https://bugzilla.gnome.org/show_bug.cgi?id=789811
The native agent already forgets about the request at the point it's
serviced and the further attempt to use it (e.g. cancel it when the screen
is locked) will trigger an assertion failure:
** (gnome-shell:30862): CRITICAL **: shell_network_agent_respond: assertion 'request != NULL' failed
https://bugzilla.gnome.org/show_bug.cgi?id=789811
Show a dialog informing the user each time the keyboard accessibility
flags are changed by one of the clutter backends (either from toggle
keys or two-keys-off modifiers).
https://bugzilla.gnome.org/show_bug.cgi?id=788564
The background code allocates a GnomeWallClock when its first created,
but neglects to drop a reference to that clock at destroy time.
The undestroyed clocks lead to a timerfd leak that eventually prevents
the shell from functioning.
https://bugzilla.gnome.org/show_bug.cgi?id=791655
If there are locations unknown to the libgweather version gnome-shell is
using, don't crash.
JS ERROR: TypeError: b.location is null
WorldClocksSection<._clocksChanged/<@resource:///org/gnome/shell/ui/dateMenu.js:141:1
WorldClocksSection<._clocksChanged@resource:///org/gnome/shell/ui/dateMenu.js:139:9
https://bugzilla.gnome.org/show_bug.cgi?id=791148
Since commit ef1e27966d turned DashItemContainer into an StWidget,
the destroy() method overrides the ClutterActor method, which is at
the very least bad style. Instead, follow the usual pattern of using
a ::destroy handler.
https://bugzilla.gnome.org/show_bug.cgi?id=791233
Labels are currently destroyed from both animateOutAndDestroy()
and destroy(), which now (rightfully) triggers a gjs warning. As
the label is created unconditionally since commit 36e5ae4a25,
mirror that and always release it in destroy() and hide it
elsewhere.
https://bugzilla.gnome.org/show_bug.cgi?id=791233
In the current code it could happen that we've menuItems and indicatorLabels
for sources that aren't anymore around, because in case a source is removed
we don't cleanup the their container objects.
Also, we should nullify InputManager's _currentSource when sources change
or it might point to some invalid data again.
So it could happen that we try to access an invalid menuitem or label
if a source change happens mentioning a source that has been deleted.
https://bugzilla.gnome.org/show_bug.cgi?id=788931
These end up emitting item-drag-end/window-drag-end pretty much
without checks. Given the MetaDnd object may end up emitting
::drag-leave as a result of the plugin ending its grab, this
would result on spurious emission of those events and subsequent
warnings.
For extra paranoia, the _inDrag variable has been split into
_inItemDrag/_inWindowDrag so we can't cross the streams.
https://bugzilla.gnome.org/show_bug.cgi?id=784545
While window attention notifications are created by the shell itself
rather than applications (most likely as a result of focus stealing
prevention), users still commonly link them to the application for
which they are shown. It makes therefore sense to follow the appropriate
policy set by the user rather than showing them unconditionally.
https://bugzilla.gnome.org/show_bug.cgi?id=779974
Since 0b02f757f8 we track the button that should have key focus
when the dialog is opened. However when the dialog is reused, the
button may get destroyed - clear the initial focus in that case to
allow setButton() to set a new one.
https://bugzilla.gnome.org/show_bug.cgi?id=788542
This D-Bus property was never been added here, which caused inconsistencies
under some scenarios (e.g. coming back from suspend) if some devices were
previously paired, since _sync() would then make the bluetooth menu visible
unconditially, because of the proxied property evaluating to 'false'.
Adding this to the D-Bus interface makes sure that it's no longer undefined
and returns the right value, fixing the bug.
https://bugzilla.gnome.org/show_bug.cgi?id=789110
Commit 28ca96064b added support for setting PopupImageMenuItem's icons
via GIcons as well as via strings. However as the check whether an object
implements the GIcon interface only works on GObjects, specifying an icon
name was broken. Fix that to actually allow both strings and GIcons.
https://bugzilla.gnome.org/show_bug.cgi?id=789018
The idea behind always showing the icon on the login screen is that
the users' needs aren't known at that point. However we can achieve
the same behavior by including the 'always-show-universal-access-status'
key in GDM's presets, so drop the special-case.
https://bugzilla.gnome.org/show_bug.cgi?id=788943
We were handling being initially headless by only setting the primary
and bottom monitor if there was any primary monitor, then checking the
primary monitor reference before making calls assuming there was any
monitors.
What we didn't do was unset the primary and bottom monitor when going
headless, meaning that temporarly disconnecting a monitor while having
windows open caused an assert to be triggered due to various code paths
taking the path assuming there are valid monitors.
Unsetting both the primary and bottom monitor when going headless avoids
the code paths in the same way as they were avoided when starting
headless.
https://bugzilla.gnome.org/show_bug.cgi?id=788607
We are already closing top bar menus on session mode changes, but
as this behavior makes sense for any other menus as well - dash
context menus or the background menu for instance - just generalize
the behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=787676
Commit 1c7a3ee61b broke setting the initial key focus for default
buttons added via addButton(). Fix this by allowing the dialog class
to provide a different default widget to ModalDialog than the entire
dialog itself.
https://bugzilla.gnome.org/show_bug.cgi?id=788282
We don't use different hover- and focus indications for window previews,
so using keyboard navigation after hovering a clone often has surprising
results when the previous focus window wasn't the selected one. Address
this by simply moving the keyboard focus with the highlight.
https://bugzilla.gnome.org/show_bug.cgi?id=786546
By default the focus chain uses the same order as the list returned
by clutter_actor_get_children(), which corresponds to the z-order.
This doesn't work well in the window picker, where clones follow
the stacking of windows to ensure a correct overview transition,
but previews are laid out purely based on space efficiency. As
a result, the order in which window previews are navigated when
tabbing around is essentially random. Fix this by providing a
focus chain implementation that is based on the visual layout
of the previews rather than the stacking.
https://bugzilla.gnome.org/show_bug.cgi?id=786546
Don't assume there will always be a primary (logical) monitor, or any
(logical) monitor at all. This includes not allocating / layouting /
styling correctly when being headless.
The initial background loading will also be delayed until there are any
(logical) monitors connected.
https://bugzilla.gnome.org/show_bug.cgi?id=730551
On the screen shield, the only possible interaction is lifting the
shield. The on-screen-keyboard is not useful for that, and the drag
gesture from the bottom may in fact conflict with dragging up the
shield, so disable it.
https://bugzilla.gnome.org/show_bug.cgi?id=788339
As notification icons now align with the title, it makes sense for
them to follow the text size in case a text-scaling-factor other
than 1 is applied.
https://bugzilla.gnome.org/show_bug.cgi?id=788265
Not doing this will throw a backtrace when running on headless mode and
trying to show a notification, due to Main.layoutManager.primaryMonitor
being undefined, so it's better to return early.
https://bugzilla.gnome.org/show_bug.cgi?id=730551
When making any D-Bus call through the GDBus' proxy wrapper with an
invalid D-Bus object path, gnome-shell hangs.
Supposedly FdoApplicationProxy constructor should validate the passed
D-Bus object path and throw an error if the path is invalid. Since it
does not do that, we work it around by making sure that the deduced
D-Bus object path is valid or throw an exception if the path is not.
https://bugzilla.gnome.org/show_bug.cgi?id=787902
Some application IDs contain hyphens, which are not allowed in D-Bus object
paths, so we need to update the translation by converting them to something
that's a valid object path. This is consistent with what GApplication does.
https://bugzilla.gnome.org/show_bug.cgi?id=787902
Commit 289f982949 broke all remote providers when adding support for
non-auto-started search providers: Whether the provider should be
auto-started needs to be known in the constructor, so setting the
property on the constructed object doesn't work.
https://bugzilla.gnome.org/show_bug.cgi?id=787986
Ensure that key-above-tab for selecting window application is consistent
with the down key.
After focus an application in the switcher:
- if you press down, the window thumbnails are previewed, and first element
is selected
- if you press key-above-tab, the window thumbnails are previewed, however
the second element is directly selected.
Make both interactions always select the first element.
https://bugzilla.gnome.org/show_bug.cgi?id=786009
This would be used by search providers which only operate on data in the
running instance, such as the terminal's search provider which finds the
shell in the tab matching the search text.
https://bugzilla.gnome.org/show_bug.cgi?id=785380
Using a unicode character here means it may look quite different
from the intended style (for instance with emoji fonts). Avoid
this by providing a custom icon and use that instead.
https://bugzilla.gnome.org/show_bug.cgi?id=766368
It's not exactly clear what changed - gobject-introspection, gjs - but
the newly added gweather_condition_to_string_full() API no longer works
like it used to. The replacement code does look more idiomatic anyway,
so just fix the code without investigating the reason of the breakage.
https://bugzilla.gnome.org/show_bug.cgi?id=787423
If a source actor is set, use that for determining the arrow side (i.e.
whether the BoxPointer widget should expand in a certain direction).
This is better because it ensures that the popup is displayed on the
same monitor as the widget it originates from.
Without this, entering text with a vertically aligned input method
close to the bottom of a monitor would expand the BoxPointer downwards
on the monitor beneath it, instead of upwards, which is what one would
expect.
https://bugzilla.gnome.org/show_bug.cgi?id=786886
Now that full-sized window previews are allowed again it makes sense to
align the window previews with the pixel grid to prevent unscaled
windows from looking blurry in the overview.
In anticipation of showing the system actions in
the search results, it is fit to move action
specific code to its own module in order to
reuse it.
https://bugzilla.gnome.org/show_bug.cgi?id=691900
The current behavior wasn't designed, but was introduced in commit
84efaac52b to work around technical limitations when we were still
using external tools like gnome-screensaver or gnome-session-quit
to handle the actions. Those limitations are long gone, so it makes
sense to make the actions consistent with the corresponding keyboard
shortcuts: Leave the overview when launching an application, and leave
it alone otherwise.
https://bugzilla.gnome.org/show_bug.cgi?id=691900
Users already have to trust their OS, so asking whether an OS component
should be allowed to perform an OS operation is odd at best, if not
confusing. Account for this by allowing system components that require a
keyboard grab to work - namely Setting's keyboard shortcuts panel - to
do so without triggering the permissions dialog.
https://bugzilla.gnome.org/show_bug.cgi?id=786146
This drops the requirement that SwitcherPopups need a modifier based
keybinding to work.
The existing behavior for modifier based keybindings is kept but if
the popup is triggered from a no modifiers keybinding, instead of
finishing when the modifier is released, we use a timer that
automatically finishes the popup. The timer is reset on every key
release to allow navigation to happen.
https://bugzilla.gnome.org/show_bug.cgi?id=783550
GWeather now provides us with API to request strings that don't
use sentence capitalization, so we can use it for summaries that
don't start a sentence to make for more natural phrases.
https://bugzilla.gnome.org/show_bug.cgi?id=779873
As in commit b2b2f65 and furthermore it doesn't make much sense to
change the menu item according to the number of connections since all
connections here are of the same type.
https://bugzilla.gnome.org/show_bug.cgi?id=786520
The new control-center shell split wifi configuration from the network
panel, and moved all other devices into a flat list. So instead of
manually spawning the app with the 'show-device' subcommand, we can
now simply launch the appropriate settings panel.
https://bugzilla.gnome.org/show_bug.cgi?id=786520
To make search more efficient, users don't need to move the actual
keyboard focus away from the search entry to activate the first
result. However the shift+f10 shortcut to pop up the context menu
via keyboard still acts on the actually focused widget, which is
the entry. It makes more sense to open the context menu of the
selected result instead, as that's what's highlighted and responds
to keyboard activation.
https://bugzilla.gnome.org/show_bug.cgi?id=675315
Otherwise the smaller icons will try to take too much space since the
texture rendering the icons will be scaled up on HiDPI displays according
to the scale factor, which will push the size of the StBin containing the
texture up, causing them to completely fill the folder's total space.
Explicitly setting the size of the StBin container in this case, in a
similar fashion to what we do when creating the empty placeholders (in
case where there are less than 4 apps in a folder), ensures that each
"cell" of the grid-like widget representing the folder does not take
too much space.
https://bugzilla.gnome.org/show_bug.cgi?id=786145
We need to consider the scaling factor in effect when updating the user's
avatar, and also make sure to update it as well whenever the scaling
factor changes.
https://bugzilla.gnome.org/show_bug.cgi?id=786120
The legacy tray introduced as part of the notification redesign in
3.16 was meant as a stop-gap solution to encourage applications to
move away from the concept of status icons, but it hasn't really
done anything except of getting in the way. Given that the large
majority of apps that still make use of status icons work perfectly
fine without them, we decided that it is time to drop this unloved
bit of UI altogether. Users who still want them (or use one of the
odd cases where an app really depends on the icon) can install one of
various extensions that are available, either based on the XEmbed
support that is still kept around or implementing the DBus-based
StatusNotifier spec.
https://bugzilla.gnome.org/show_bug.cgi?id=785956
Currently the chrome layer decides itself which events on the window
clone should show or hide the chrome, which makes it harder to extent.
Instead, move the decision to the window clone by letting it emit
show/hide-chrome events when appropriate.
https://bugzilla.gnome.org/show_bug.cgi?id=783953
Previews are currently limited to at most 70% of the actual window
size. This was done to indicate more clearly that the overview is
active and the window cannot be interacted with. However since then
other indications like the vignette effect have been added, so
artificially limiting the preview size doesn't look necessary anymore.
https://bugzilla.gnome.org/show_bug.cgi?id=783953
Now that only one window title is visible at any time, it no longer
matters if a title extends into other window previews, so we can
always show the full title.
https://bugzilla.gnome.org/show_bug.cgi?id=783953
While the new title position gives the previews more space, they now
overlay the content which may hide valuable information. Address this
by only revealing the title as additional information on hover, like
we do for other auxiliary elements.
https://bugzilla.gnome.org/show_bug.cgi?id=783953
We consider the window previews the primary way to identify a window,
so it makes sense to give them as much space as possible. So in order
to not have title captions take up too much vertical space, overlay
them on top of the preview borders.
https://bugzilla.gnome.org/show_bug.cgi?id=783953
We currently expand the workspace switcher when workspaces are being
used, that is when there are any windows on a non-active workspace.
While this helps with the switcher's discoverability, it does eat into
the space available for window previews. By now the component should
be well established, so we can afford opting for space efficiency and
only expand the switcher while the user actually interacts with it.
https://bugzilla.gnome.org/show_bug.cgi?id=783953
The overview's window picker is primarily about windows, and as the
previews that represent them are more effective the bigger they are,
it makes sense to scale down competing elements; start by reducing
the size of workspace thumbnails on the right ...
https://bugzilla.gnome.org/show_bug.cgi?id=783953
Instead of potentially loading a background mid-way when it changes, and
loading it again for every file monitor event, leverage
CHANGES_DONE_HINT events, which allow us to ignore CREATED and CHANGED
signals from the file monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=747794
About every other situation can do with synchronizing keyboard visibility,
and keyboard layout changes are already handled internally in the Keyboard
object.
A downside of this approach is that once created, there will always be a
Keyboard instance and its full actor hierarchy. Seems reasonable to do that
since we can't tell it won't ever be needed.
https://bugzilla.gnome.org/show_bug.cgi?id=785309
In case where a method- and property name overlap, using the method
is less unambiguous than I thought - mozjs52-based gjs will only see
the method, while mozjs38-based gjs will only see the property. We
are in luck though, and the real property name contains dashes that
allow us to refer to the property in a way that works for all gjs
versions.
https://bugzilla.gnome.org/show_bug.cgi?id=785090
ClutterActor has both a has_pointer() method and a :has-pointer
property (that we represent as 'has_pointer'). So far gjs was
able to deal with the name overlap, but now trying to use the
property will instead test for the availability of the method.
Just avoid the conflict by switching to the method, which is
unambiguous.
https://bugzilla.gnome.org/show_bug.cgi?id=785090
We now cancel animations on override, however we also want to cancel
animations altogether on unmap (that is, when hiding the overview)
to avoid icons swarming into the void.
https://bugzilla.gnome.org/show_bug.cgi?id=736148
Until now we were waiting the animation to complete to allow the user to
make a new animation. This could bring some problems and annoy nervous
users.
Instead of that, destroy clones on new animations triggers and
create a new animation with the new direction.
https://bugzilla.gnome.org/show_bug.cgi?id=736148
The animation needs the icons' final positions, so we currently defer
it to a ::notify::allocation handler; however as starting the animation
during an allocation cycle would trigger a Clutter warning, it is
further deferred to a MetaLater. While this usually works, it is possible
that the allocation is already valid when we connect the signal, in which
case the animation is triggered at a later unexpected time. Switch to
a more robust ::paint handler instead, which also allows us to get rid
of the double-delay.
https://bugzilla.gnome.org/show_bug.cgi?id=736148
Any symbols (including class properties) that should be visible
outside the module it's defined in need to be defined as global.
For now gjs still allows the access for 'const', but get rid of
the warnings spill now by changing it.
https://bugzilla.gnome.org/show_bug.cgi?id=785084
Symbols that are defined with 'let' are no longer visible outside
the module that defines them. To unbreak the code base, define all
non-private properties as global.
https://bugzilla.gnome.org/show_bug.cgi?id=785084
The first time that the session is started, it can happen that the
AT SPI hasn't been correctly initialized, and this results in a crash
when attempting to register the caret or focus listeners.
In order to avoid this, these changes check the result of initializing
the AT SPI, to allow further attempts when it has failed.
https://bugzilla.gnome.org/show_bug.cgi?id=785047
Customization of keycombo actions for strips/rings was lost in the
porting to new incarnation of Wacom support.
The UI here is slightly different, instead of requiring the user to
rotate/swipe in each direction to map each keycombo, the UI will
navigate the user through edition of both options, first one, then
the other.
https://bugzilla.gnome.org/show_bug.cgi?id=782033
