As we currently use Tweener for all animations, we have a single place
for hooking up the enable-animations and slow-down-factor settings.
However that will no longer hold true when we'll start to use Clutter's
built-in animation facilities, so add a small helper function that
applies the necessary adjustments.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/22
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
