Remove transitions of the `slide-x` property of the layout manager
before we set the property to a fixed value, otherwise the transitions
might still be running and change the value after we set it.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/707
As pointed out by designers, fading it signals that the
icon grid is not a drop target, when now it actually is.
Remove the fade effect applied to the icon grid when
dragging. Since this is the only caller of fadeIn() and
fadeHalf(), also remove these methods.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/664
Properties that aren't marked as animatable don't support *implicit*
animations, but they can still be animated with explicit transitions.
Use the newly added convenience method to cut down further on Tweener
usage.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/666
Clutter animations work on GObject properties on animatables. The
last commit took care of the latter by turning all animated objects
into actor subclasses, now it's time to make all properties used
in Tweens into GObject properties.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/666
We now have everything in place to replace Tweener for all animatable
properties with implicit animations, which has the following benefits:
- they run entirely in C, while Tweener requires context switches
to JS each frame
- they are more reliable, as Tweener only detects when an animation
is overwritten with another Tween, while Clutter considers any
property change
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/22
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
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
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
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
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
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
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
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
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
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
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
Both the Overview::scroll-event and actions added via addAction()
are meant to work anywhere in the overview, but for now only work
on the primary monitor. Move the handling to the background group
that is known to span all outputs to fix.
https://bugzilla.gnome.org/show_bug.cgi?id=766883
The message tray is now empty and about to be removed, so an indication
at the bottom edge of the overview becomes an odd location to convey the
status of the summary. We will eventually display an indication in the
top bar that unseen messages are available, for now just remove the
existing indicator.
https://bugzilla.gnome.org/show_bug.cgi?id=744850
Tray icons make for a terrible UI on their own, but trying to
shoehorn them into the notification system has only made them
worse. At least for the time being this removal is temporary
and support for tray icons will be back, but no longer as part
of the notification system.
https://bugzilla.gnome.org/show_bug.cgi?id=744815
Commit a4475465f1 fixed the wrong alignment for the fully visible
control, but regressed the partially slid-out one; take the slideX
factor into account to get the right offset for both cases.
Controls that slide left are located on the left, so the offset to
align them with the corresponding edge is always 0. It's controls
on the right that need a different offset when the available width
exceeds the child's width.
https://bugzilla.gnome.org/show_bug.cgi?id=728899
Commit 12845f0eef reset translationX to 0 to fix the slide-in
animation of the dash when dragging a search result, but 0 is the
wrong value for the thumbnail slider - the next time it will be
shown, it will just pop up instead of sliding in due to translationX
already being at its target value.
Fix this by making _updateTranslation take the actual visibility into
account and call that to set the correct translation in dragBegin.
Controls are slided in by animating translationX from the actor's
width to 0; however as _updateTranslation() will skip the animation
when the property is already at its target value and 0 happens to be
the initial value of translationX, the initial animation is skipped.
Fix this by initializing translationX to undefined, which will always
differ from a valid target value.
The comment is right, updating the translation should be deferred
to pageEmpty, or else overview controls will just pop up instead
of sliding in. So revert that part of commit 6a7fa52879.
Currently we are overriding the explicit calls to slideIn
given that it's called also with the signal of showing overview.
It was necessary because of the bug that previous patch fixed,
so now we can just delete that.
https://bugzilla.gnome.org/show_bug.cgi?id=732901
The workspace switcher should be expanded when workspaces are in use.
Our current implementation assumes that workspaces are used when there
are windows on at least two workspaces. However workspaces are already
used when moving from a non-empty workspace to an empty one (presumably
with the intention to launch something on that workspace), so tweak the
heuristic accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=662457
As far as I can tell, the only behavior change of a transient source
is that they auto-destroy after viewing their summary box pointer.
Since all transient sources are only associated with transient
notifications, it seems that we can never get to their summary box
pointer in the first place! Remove support for this.
https://bugzilla.gnome.org/show_bug.cgi?id=710115
`a + b ? c : d` is parsed as `(a + b) ? c : d`, not the more intuitive
`a + (b ? c : d)`.
This was causing a bad slide animation and Clutter warnings when coming
out of the overview.
Not because ClutterActor is bad or wrong, but because I always get
confused on the difference, and having them both in SlideLayout
makes the code a bit easier to read and understand.
The parent SlidingControl had an onOverviewShowing, but we had
overridden it with the same code in both subclasses. Just move it
back to SlidingControl.
In order for the workspace thumbnails box to have the correct size,
we need to constrain the width of the thumbnails box to the height we're
given, instead of assuming an unlimited height.
https://bugzilla.gnome.org/show_bug.cgi?id=694881
