Since ES5, trailing commas in arrays and object literals are valid.
We generally haven't used them so far, but they are actually a good
idea, as they make additions and removals in diffs much cleaner.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/805
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
If an else block only contains an if statement, the two can be
combined into an if-else block, which cuts down on indentation
and usually helps legibility.
There are exceptions (for instance where the outer if and else
blocks are mirrored), but where it makes sense, change the code
to avoid lonely ifs.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/805
Nesting functions can be helpful for private helper functions, but
here they are accessing some variables from the outer scope and
shadowing others. Split them out to avoid any ambiguity.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/805
The event blocker in AllView is responsible for stealing click events
from the icon grid and closing the folder popup. The event blocker is
kept unreactive when no folder popup is visible, and it's made reactive
as a response to the 'open-state-changed' signal.
Using this signal, though, is problematic. When opening an app folder,
the icon grid first opens space for the folder to fit in; during this
period, it's possible to click on another folder icon, and break the
icon grid state.
Make sure the event blocker is reactive immediately after clicking on
a folder icon.
Related: https://gitlab.gnome.org/GNOME/gnome-shell/issues/1470https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/816
Objects implementing EventSource should have some mandatory methods and
properties, we can ensure this by defining an EventSourceBase abstract
class.
So inherit EmptyEventSource and DBusEventSource from it making sure that
they implement all the needed methods, using native properties and
replacing the 'notify::*' fake signal emissions with proper object
notifications.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/563
Use GObject based objects for ModemGsm, ModemCdma and BroadbandModem.
This allows to define a base class that we can use to natively define
properties and notify property changes.
We can now remove the "fake" notify signals with proper properties
notifications.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/563
Animation background is just wrapping a native GnomeDesktop BGSlideShow
object, so instead of using composition we can now just inherit from the
native GObject, re-using native properties when possible, and avoiding
to keep an extra wrapper to the bg file.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/563
Resizing effects are more finicky as other effects, as the actual
animation is delayed until we receive the ::size-changed signal.
However that signal may never be emitted if the window is destroyed
just after starting the size-change effect, in which case the effect
is never completed, blocking mutter from destroying the corresponding
window actor.
Address this by tracking when a resize effect is pending, and complete
the effect when appropriate.
https://gitlab.gnome.org/GNOME/mutter/issues/655https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/815
In the xwayland-on-demand scenario, it may happen that Xwayland is
shutdown (causing a restart of ibus-daemon to drop ibus-x11) while
we are typing.
If we have a bit of bad luck, this will cause the IBusInputContext
to be disposed (due to its bus "closing") at a time when we have
an ibus_input_context_process_key_event_async() request on the fly.
As the object is disposed in between this would tickle JS (rightfully
complaining that it's been disposed under its feet) and make us pass
an actually NULL IBusInputContext to the corresponding _finish()
function (despite the IBusInputContext being still held alive by some
other refs). This will assert and abort in
ibus_input_context_process_key_event_async_finish() then.
To handle this, listen for IBusInputContext::destroy, and reset our
internal state, this way we can compare on the JS side that the
IBusInputContext is indeed an up-to-date one.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/813
I've observed that UPower can occasionally report a charge level of 100%
while the state is still "charging". This usually doesn't last very long
but it is noticeable because the power icon changes to a "missing icon"
icon. This will handle that rare case correctly.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/814
For stable branches, we currently only check out the correct mutter
branch for merge requests. For the regular pipeline, our code to
determine the current shell branch fails because CI runs on a
temporary "pipeline/12345" branch that doesn't exist for mutter.
Switching to the correct gitlab environment variable fixes that.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/811
Clutter originally cluttered its namespace with key symbols, before
prefixing all symbols with KEY. We still use the unprefixed symbols
occasionally, replace them so mutter can drop the deprecated symbols.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/808
Since polkit takes a few milliseconds from initiating the session to
emitting the "request" signal, don't introduce visual distraction by
hiding the password entry and showing it again a few ms later.
So start a timeout of 200 ms when we destroy a session and if no session
request (i.e. a request for a password-authentication) happened during
this timeout, hide the password entry.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/788
Since we don't know if polkit/PAM will request a password (emitting the
"request" signal) or use another authentication method like a
fingerprint after the current authentication failed, hide the password
field and make the "Authenticate" button insensitive after cancelling
the session, just like we do when creating the dialog.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/788
Set the key focus to the password field only after we got a request
(and therefore know that a password is requested) instead of using
`setInitialKeyFocus()`. This way we don't try to focus the password
field by default if we aren't showing it (e.g. in case the user has no
password or is using fingerprint login).
Also we have to move the call to `grab_key_focus()` to happen after
`_ensureOpen()`, because otherwise the ModalDialog will set the focus to
one of the buttons while opening itself.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/788
Show the user avatar for all users, including the root user. The root
user will always have the generic avatar, but it looks more consistent
than showing no avatar at all.
This way we also don't have to worry about the spacing introduced by the
polkit-dialog-user-layout CSS class, which would give the
"Administrator" label a small offset to the left.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/788
Instead of every individual StThemeNode. There are essentially two kinds
of theme nodes: Those we create for lookups, and those interned by the
theme context and used by StWidgets. Listening to the signal on the former
is pointless as they are short lived and not meant to be really used for
drawing. So it is only essential to track stylesheet changes in those we
intern for later use.
This change does precisely that, it lets the StThemeContext track the
stylesheet changes and let all known theme nodes reset their state for
it.
The internal array holding all connected handlers for this signal in glib
was about the biggest single allocation made in gnome-shell, as interned
theme nodes nodes are around the 4 to 5 digit numbers. This essentially
makes it disappear.
This however means that widgets that are explicitly set a theme through
st_widget_set_theme() don't get their theme node implicitly updated.
There's little reasons to use that API, so perhaps this is an acceptable
tradeoff.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/779
A StWidget could get its style from a) a theme set in the StThemeContext,
and b) directly through it's ::theme property. Generally, overriding CSS
through the latter cannot be recommended as it loses any connection with
the global theme (eg. the ones you get through selector specificity).
It sounds a bit too powerful and pervasive, there's no use for it in
gnome-shell and doesn't look like something that could be recommended on
extensions. So, just drop this piece of API.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/779
