These traditionally got the various ClutterEvent subtype structs as their
argument, so it was not allowed to use ClutterEvent generic getter methods
in these vfuncs. These methods used direct access to struct fields instead.
This got spoiled with the move to make ClutterEvent opaque types, since
these are no longer public structs so GNOME Shell most silently failed to
fetch the expected values from event fields. But since they are not
ClutterEvents either, the getters could not be used on them.
Mutter is changing so that these vmethods all contain an alias to the
one and only Clutter.Event type, thus lifting those barriers, and making
it possible to use the ClutterEvent methods in these vfuncs.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2950
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2872>
The environment module is used to initialize the environment, yet it
currently also defines the adjustAnimationTime() function.
Ideally it should not export any utility functions, in particular
once converted to ESM.
The function cannot be moved to the existing Utils module, as that
depends on an initialized environment, and can therefore not be
imported from environment.js, so use that opportunity to group
together several animation helpers in a new animationUtils module.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2822>
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>
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
The design team discussed the ellipses at the end of the hint text of
our entries and, even though they are present in most mockups, it turned
out they don't like them, so remove them.
It also turned out they don't like the prefixes like "Enter" before it,
so remove those, too.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/977
Since we don't really know what the buttons we're adding to the dialogs
are about, we can't configure a button to "be clicked" when the escape
key is pressed. So add a separate escape key handler to fix that, return
-1 and abort the request.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/961
When updating the buttons of the mount dialogs, compare the new buttons
to the old ones and only create new buttons in case something changed.
This makes sure key focus isn't reset or lost unnecessarily while a
dialog is opened.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/961
Since there is a generic layout for dialogs like that now, use it. Also
remove the functionality of focussing a window when clicking a list
item, it's not discoverable at all and pretty unexpected.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/961
Since MessageDialogContent.messageBox is going to be removed in a
subsequent commit, move the parts where it's used out of messageBox and
into the contentLayout instead. This will introduce wrong spacings in
some dialogs, which we're going to fix when implementing the redesigned
individual dialogs.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/886
Use the new StPasswordEntry for password entry fields
and remove all direct handling of clutter text of the entry
via clutter_text_set_password_char to show/hide the password
text. StPasswordEntry will provides a peek-password-icon which
will allow to show/hide the password present in the field to
the user in subsequent commits.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/619
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
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
Every since commit aa394754, StBoxLayout has supported ClutterActor's
expand/align properties in addition to the container-specific child
properties. Given that that's the only container left with a special
child meta, it's time to fully embrace the generic properties (and
eventually remove the child meta).
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/780
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 currently use no less than three different ways of indenting
object literals:
let obj1 = {
foo: 42,
bar: 23,
};
let obj2 = { foo: 42,
bar: 23 };
let obj3 = { foo: 42,
bar: 23
};
The first is the one we want to use everywhere eventually, while the
second is the most commonly used "legacy" style.
It is the third one that is most problematic, as it throws off eslint
fairly badly: It violates both the rule to have consistent line breaks
in braces as well as the indentation style of both regular and legacy
configurations.
Fortunately the third style was mostly used for tween parameters, so
is quite rare after the Tweener purge. Get rid of the remaining ones
to cut down on pre-existing eslint errors.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/716
While we aren't using those destructured variables, they are still useful
to document the meaning of those elements. We don't want eslint to keep
warning about them though, so mark them accordingly.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/627
Braces are optional for single-line arrow functions, but there's a
subtle difference:
Without braces, the expression is implicitly used as return value; with
braces, the function returns nothing unless there's an explicit return.
We currently reflect that in our style by only omitting braces when the
function is expected to have a return value, but that's not very obvious,
not an important differentiation to make, and not easy to express in an
automatic rule.
So just omit braces consistently as mandated by gjs' coding style.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/608
Make the dialog a widget itself, removing the `_group` property used for
handling the actor.
Update all the inherited classes to be also GObject implementations, moving all
the signals to proper object ones.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/55
This extends the ShellMountPasswordDialog by widgets which allow
specifying parameters supported by TrueCrypt and VeraCrypt compatible
volumes (TCRYPT). This includes:
- Whether the volume to be unlocked is hidden.
- Whether the volume to be unlocked is a system partition.
Note: TrueCrypt and VeraCrypt only support encrypting Windows
systems [1], so the label for this option is "Windows System Volume".
- Whether to use a PIM [2].
- Whether to use keyfiles. Unfortunately, GMountOperation doesn't
support TCRYPT keyfiles, so if this checkbox is checked, we tell the
user that they should unlock the volume with Disks, which supports
unlocking TCRYPT volumes with keyfiles.
[1] https://www.veracrypt.fr/en/System%20Encryption.html
[2] https://www.veracrypt.fr/en/Header%20Key%20Derivation.htmlhttps://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/126
