Start using the new methods to simplify signal cleanup. For now,
focus on replacing existing cleanups; in most cases this means
signals connected in the constructor and disconnected on destroy,
but also other cases with a similarly defined lifetime (say: from
show to hide).
This doesn't change signal connections that only exist for a short
time (say: once), handlers that are connected on-demand (say: the
first time a particular method is called), or connections that
aren't tracked (read: disconnected) at all.
We will eventually replace the latter with connectObject() as
well - especially from actor subclasses - but the changeset is
already big enough as-is :-)
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1953>
The animation was removed in commit 6a00a504d4 for consistency with
other menus. However commit a9b12d5d73 then *added* animations to
those just four minutes later.
So add back the original animations for consistency, both with menu
closing and with other menus.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1595
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
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
If an active grab on pointer events happens during multi-touch operations,
all non-pointer-emulating touches will be muted. This may leave the
Clutter.ClickAction incomplete if triggered by one of those sequences,
just to have a gesture take over and trigger a compositor grab, which would
leave the capture-event handler stuck eating events.
So listen for grab-op-begin from the display, and ensure the action is
released if such grab begins.
and the capture event handler stuck.
Right now we have three "dummy cursor" widgets between the background
menu, the message tray menu, and the IBus candidate popup. Consolidate
these into one "dummy cursor" widget which is tracked in the layout
manager.
If monitor-changed fires at startup, it will destroy all of the
backgrounds, but since this._isStartup is true, won't recreate any
of them. Additionally, since _bgManagers is indexed by monitor index,
if the primary index is not 0, it could become a sparse array (e.g.
[undefined, undefined, primaryBackground]), and our for loop will
crash trying to access properties of undefined.
Fix both of these issues by always creating background managers for
every monitor, hiding them on startup but only showing them after
the startup animation is complete.
One thing we need to watch out for is that while LayoutManager is
constructing, Main.uiGroup / Main.layoutManager will be undefined,
so addBackgroundMenu will fail. Fix this by passing down the uiGroup
to the background menu code.
https://bugzilla.gnome.org/show_bug.cgi?id=709313
And reverse menu order in order to avoid it reading "Change Background… Settings"
"System Settings" shouldn't be used because it's not used to mean the control-center in any other place.
https://bugzilla.gnome.org/show_bug.cgi?id=694290
BackgroundMenu must ensure the actor it attaches to is reactive, and
the layout manager must create a background menu for the first background
too.
https://bugzilla.gnome.org/show_bug.cgi?id=694227
