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
xgettext got better at recognizing template strings, so we can
replace more string concatenations. Alas xgettext is still buggy
(surprise, regular expressions are hard), so there are still a
handful of holdouts that prevent us from making a complete switch.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/792
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
This wasn't added on the GObject-ification in commit c4c5c4fd5c. This
introduced warnings and misbehaviors when closing the dialog. (Eg.
pressing the "show OSD" pad action would show stack different dialogs
on top each other).
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/800
Similar to the previous work-around, xgettext gets thrown off by
embedded quotes in template strings, in particular where a template
"breaks up" a pair of quotes.
Throw in some more comments to make xgettext happy, but whoever makes
the gettext toolchain not depend on fragile regular expressions will
be drowned in beverages of their choice ...
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/792
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
For GObject properties, we follow the convention of all-lowercase,
dash-separated names. Those translate to underscores in getters/setters,
so exempt them from the newly added "camelcase" rule.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/627
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
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 can use that newer method where we don't care about the actual position
of an element inside the array.
(Array.includes() and Array.indexOf() do behave differently in edge cases,
for example in the handling of NaN, but those don't matter to us)
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/152
On one hand, we were using a path instead of an URI on
rsvg_handle_set_base_uri(). This broke at some point in librsvg
(presumably for the best, handling paths there sounds non-standard)
leaving a blank svg (As the base image wouldn't be accessed).
On the other hand, we use this with the deprecated rsvg_handle_write()
which we should drift away from.
Using rsvg_handle_new_from_stream_sync() neatly solves both. We use
newer API based on input streams and GFiles, and it internally does
the right thing, bringing the pad OSD back to life.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/1220
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
As strings are guaranteed to use UTF-8 in the GNOME platform, generic
file APIs like g_file_load_contents() return raw data instead. Since
gjs' recent update to mozjs60, this data is now returns as Uint8Array
which cannot simply be treated as string - its toString() method boils
down to arr.join(',') - so use gjs' new ByteArray module to explicitly
convert the data.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/179
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
If the underlying X11 input driver creates multiple devices from a single
device node, we may end up picking up the wrong device. So, instead of
picking the first device based on node and bailing out if it's not a pad,
pick the first pad that has that device node, and bail out if there is
none.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/10Closes: #10
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
Customization of keycombo actions for strips/rings was lost in the
porting to new incarnation of Wacom support.
The UI here is slightly different, instead of requiring the user to
rotate/swipe in each direction to map each keycombo, the UI will
navigate the user through edition of both options, first one, then
the other.
https://bugzilla.gnome.org/show_bug.cgi?id=782033
If the padOsd is given a nonexistent ring/strip, things would fail
badly later when trying to paint a 0x0 StLabel. Just avoid creating
more ring/strip labels than those known by libwacom.
This is unlikely to happen, but seems better to protect against it.
https://bugzilla.gnome.org/show_bug.cgi?id=782033
Whenever there's more than one pad in the same group (eg. Wacom ExpressKey
Remotes), show a popdown menu to allow configuring those extra pads.
Devices are hot-pluggable, so the popdown menu will update its state
whenever pads are added/removed.
Also, allow to quickly change between pads by switching to its OSD by
just interacting with them. Always given they are in the same group.
https://bugzilla.gnome.org/show_bug.cgi?id=779986
This is an implementation of the pad OSD that's been previously
present in gnome-settings-daemon. Since things are moving closer
to the compositor, it makes sense to have this implemented as shell
UI.
https://bugzilla.gnome.org/show_bug.cgi?id=771067
