After porting the more complex cases - in particular those that
affect a module's API - we are left with straight-forward D-Bus
method calls that can be moved to promise-based wrappers in one
go.
For consistency, this also switches from Remote to Async where
the call result is ignored.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2344>
Introduce a new class, EventEmitter, which implements signal
handling for pure JavaScript classes. EventEmitter still
utilizes GJS' addSignalMethods internally.
EventEmitter allows static typechecking to understand the
structure of event-emitting JS classes and makes creating
child classes simpler.
The name 'EventEmitter' mirrors a common name for this pattern
in Node and in JS libraries.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2043>
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 Message class this is derived from unconditionally adds a close
button with 0 opacity that only gets shown on hover for messages that
can actually be closed. The MPRIS MediaMessage however can never be
closed and having a close button can cause the title to be cut short
unexpectedly.
Similarly the secondary text which other notifications use to display
the notification time is always left empty here as well.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3664
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1632>
Most media players have a media player that shows the title of a song
and artists in the song. In those media players the title is
highlighted (bold text) and the list of artists is under the title.
Shell does the exact opposite in the player in the notification area.
Example media players: Spotify, Rhythmbox, GNOME Music
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1480
The idea behind hiding the notifications and media section on days
other than today was that they represent present activity together
with today's events, in contrast to past and future events from
other days.
After events were moved out of the message list, that behavior is
no longer useful: We just guarantee that the left-hand side of the
calendar will always be empty when browsing the calendar.
Adjust to that by removing the limitation by date.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1282
Sometimes an MPRIS media player will create and then destroy an object
before the signals that handle the object's destruction can be created.
This verifies that the object still exists after the necessary signals
have been created.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2776
The 'gdm' user is not going to run a media player, so there is no
point in allowing the corresponding section on the login screen.
All other sections are already disabled, so this is the only reason why
we end up with the message list instead of only showing the calendar.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2241
xgettext gained some support for template strings, and no longer
fails when encountering '/' somewhere between backticks.
Unfortunately its support is still buggy as hell, and it is now
silently dropping translatable strings, yay. I hate making the
code worse, but until xgettext really gets its shit together,
the only viable way forward seems to be to not use template
strings in any files listed in POTFILES.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1014
Since the mpris implementation of the notification tray supports showing
multiple notification (one for each player), it doesn't make sense to
have only one global property to store the message, since that only
allows referencing one message at a time.
Instead, handle the MediaMessages completely inside the scope of
`_addPlayer()`, this should allow showing more than one message again,
which broke with commit 4dc44304df [1].
[1] https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/791https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/833
ES6 allows to omit property names where they match the name of the
assigned variable, which makes code less redunant and thus cleaner.
We will soon enforce that in our eslint rules, so make sure we use
the shorthand wherever possible.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/805
I have observed a client in the wild (Chromium again) set CanPlay to
false momentarily while it is loading the next song. Previously, the
code would close the player proxy in that case, meaning that after
playing one track, the MPRIS message would disappear and never come
back.
However, I think this use of CanPlay, while apparently not usual, is not
incorrect according to the spec. We should hide the message instead of
closing the player proxy.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1362
In the wild we have buggy clients (notably Chromium 77 and earlier) that
send metadata with the wrong types. Previously, this would throw an
exception and prevent the MPRIS information from showing up in the
message list.
This changes the code to check if any incoming metadata is of the type
it is expected to be, and logs a warning if not, then continues on with
a default value.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1362
Remove the `this.actor = ...` and `this.actor._delegate = this` patterns in most
of classes, by inheriting all the actor container classes.
Uses interfaces when needed for making sure that multiple classes will implement
some required methods or to avoid redefining the same code multiple times.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/559
We are currently inconsistent whether to put the operators in front
of the corresponding line or at the end of the preceding one. The
most dominant style for now is to put condition and first branch on
the same line, and then align the second branch:
let foo = condition ? fooValue
: notFooValue;
Unfortunately that's a style that eslint doesn't support, so to account
for it, our legacy configuration currently plainly ignores all indentation
in conditionals.
In order to drop that exception and not let messed up indentation slip
through, change all ternary operators to the non-legacy style.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/725
ES6 finally adds standard class syntax to the language, so we can
replace our custom Lang.Class framework with the new syntax. Any
classes that inherit from GObject will need special treatment,
so limit the port to regular javascript classes for now.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/361
When 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
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
Media notifications currently always show the forward and backward
buttons as clickable, regardless of whether the corresponding action
is available or not. Media players usually address this by rendering
controls insensitive in this case, so do the same here.
https://bugzilla.gnome.org/show_bug.cgi?id=773884
The section titles usually don't provide a lot of value - messages
themselves are usually pretty unambiguous about their type, and
having a hidden shortcut to some settings panel or application isn't
essential either - except when showing the selected date when browsing
other days, as it adds context to the listed events. Based on that,
remove the section title as a general MessageListSection feature and
move it into the EventsSection, where we only show it when it is useful.
https://bugzilla.gnome.org/show_bug.cgi?id=775763
We lost media controls outside of notification banners when
implementing the new notification designs. Reimplement this
functionality as a dedicated "Media" section in the message
list based on MPRIS.
https://bugzilla.gnome.org/show_bug.cgi?id=756491
