Just like switcher popups, popup menus don't play well together with
system modals, and generally have a lower priority. So just like
switcher popups, close popup menus when a system modal dialog pops
up.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1536
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
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
Some vfuncs like `button_press_event`, `button_release_event` and
`touch_event` don't have handlers in the parent classes of
PopupBaseMenuItem. So don't call those handlers and return the default
Clutter.EVENT_PROPAGATE there.
This fixes a crash of the shell that happens when pressing a mouse
button inside the system popup menu and releasing it above a slider like
the volume slider again.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/787
The PopupMenuManager is supposed to grab and focus the menu actors, with
normal menus we always need to grab the actual menu but set the key focus to
the source actor so that it will be able to move the focus to the menu
child, if requested.
However there are menus such as the RenameFolderMenu that requires the
key-focus once prompted, so provide a focusActor property (defaulting to the
sourceActor) that can be set in order to define the actor to give the
keyboard focus to, when the menu is popped-up.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1604https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/720
The menu item ornament is used to put dots or checks in menus or otherwise
to define a padding for a label.
However in some cases we want to create a menu item with no left (in ltr)
padding.
In order to do that, define a HIDDEN Ornament mode that completely hides the
ornament actor.
The naming here might be confusing as this should probably be called NONE,
while the default mode is the invisible one, but it's too late to change it
now.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/720
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
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
We now have everything in place to replace Tweener for all animatable
properties with implicit animations, which has the following benefits:
- they run entirely in C, while Tweener requires context switches
to JS each frame
- they are more reliable, as Tweener only detects when an animation
is overwritten with another Tween, while Clutter considers any
property change
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/22
When expanding a submenu, we currently use a single tween to animate
both the submenu actor and the source arrow. We do this by tweening
a monkey-patched JS property on the main actor, which we then use
to update the arrow's GObject property on updates. As Clutter cannot
animate random JS properties, this trick will prevent us from using
implicit animations here.
The only reason I can think of for using a single tween is to keep
both animations in perfect lock step, but as expansion and rotation
are visually quite distinct, this shouldn't be required, so just
set up separate animations for each actor.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/22
Those unused arguments aren't bugs - unbeknownst to eslint, they all
correspond to valid signal parameters - but they don't contribute
anything to clarity, so just remove them anyway.
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
While we have some style inconsistencies - mostly regarding split lines,
i.e. aligning to the first arguments vs. a four-space indent - there are
a couple of places where the spacing is simply wrong. Fix those.
Spotted by eslint.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/608
We are currently inconsistent on whether case labels share the same
indentation level as the corresponding switch statement or not. gjs
goes with the default of no additional indentation, so go along with
that.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/608
A menu item activation might lead to a call to `itemActivated` which eventually
will close the menu which leads to a `PopupMenu.removeAll` that destroys all the
items, stopping the emission of the 'activate' signal for them.
Before commit 4258ae3e this was not happening because destroy'ing a javascript
object wasn't really disposing it and thus stopping the signal emissions.
So, ensure that `itemActivated` is called after that all the other callbacks
have been consumed, and so that the menu is closed as last thing.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1326https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/557
Don't use composition for PopupBaseMenuItem, but instead inherit from BoxLayout.
So remove the internal actor, making all the menu items actor themselves.
Add an actor property as fallback to avoid warnings for usage in menus.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/499
Menu items use a single 'active' state that follows both hover and
keyboard focus. It therefore makes sense for the active item to always
grab the focus, in particular as an item that is sensitive but not
focusable by keynav would be rather weird.
As it turns out, we do have a case that is weird enough where we want
exactly that, so only grab focus if the actor's :can-focus property
allows it.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/171
