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
