As gnome-shell is moving to ESM, it will now load extensions as
standard modules instead of using legacy imports. The change boils
down to exporting the Extension class as default, but we can also
start using standard imports for introspected modules now, so do
that at the same time.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/259>
gnome-shell started transitioning to gjs' object spacing rule,
i.e. `{foo: 42}` instead of `{ foo: 42 }`.
We have a much smaller code base than the shell and aren't using
a secondary "allowed-but-deprecated" configuration that allows a
gradual transition, so just pull the switch and update to the new
style.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/240>
As a side-effect of supporting class fields, regular constructors
now work in GObject subclasses. Using _init() still works and
there's no functional difference, but it's simply much nicer
to use the same syntax for all classes.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/215>
Extensions review guidelines enforces extensions to
don't create objects in the constructor of the class
that init() returns. so creating settings object in enable()
can make the extension compatible with the ego review guidelines.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/197>
GTK4 removes the generic GtkWidget API for accessing an inserted
action group, so we need an alternative for tracking the currently
selected theme.
Using the underlying GSettings object looks like the easiest option,
so do that.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/148>
While we don't endorse or support 3rd party theming, the extension
exists and is actively used. However right now the most convenient
way of setting it up is by installing Tweak Tool; give users an
alternative by providing a simple settings dialog ourselves.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/117
String concatenation is considered bad style after ES6 added
template strings. The latter is the replacement we generally
want, except where the aforementioned xgettext bug would trip
over the backtick/slash combination.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/49
Since template strings were added in ES6, string concatenation is
considered bad style. There's a catch though: xgettext currently
has a nasty bug concerning the combination of backticks and slashes.
Avoid that issue by building filenames with the corresponding GLib
helper function.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/49
After replacing Lang.Class with ES6 classes and adopting arrow notation
for anonymous callbacks, we only use the Lang module 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.
So just use the built-in function directly instead of the wrapper.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell-extensions/issues/30
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.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell-extensions/issues/30
setThemeStylesheet() stopped accepting %null to revert to the default
stylesheet. The issue is fixed in gnome-shell master, but work around
it for 3.15.2 to not ship broken (again).
Just like we look in XDG_DATA_DIRS, we should honor XDG_DATA_HOME
as well.
For compatibility reasons, we look in ~/.themes first, then ~/.local/share,
then /usr/share.
A long due update, since this was merged in gjs and core shell.
We no longer need to mess with __proto__ and prototype, and can
use decent syntax for true object oriented programming.
(This affects all except xrandr-indicator, since I want to port
that to GDBus too, using the new bindings right from the start)
Retrieve Convenience from the extension helper object (Me), and
pass no arguments to initTranslations and getSettings (since the
metadata has all that is required)
Introduce a common settings.mk file, which is included in extensions
that need GSettings, to ensure that conventions are respected, and
necessary fixes can be applied from one place.
Add "gettext-domain", "extension-id" (containing the base part of the
UUID) and "gschemabase" (which, combined with "extension-id", gives
the GSettings schema) to metadata.json, autogenerated by the build
system.
It is not used anymore, now that translations are bundled with
the extension. Also, in the zip files it ended up with my home
folder, which is not nice.
Common code for retrieving translations and GSettings schemas has
been factored out into lib/convenience.js, which is part of
every extension installation.
Since that code relies on renames done at zip file creation time,
extensions can no longer be installed with "make install". Instead,
one should create the zip file and install it with the tweak-tool.
There is also a bash script, local-install.sh, that will install
everything in zip-files.
Also, since the GSettingsSchemaSource code is not yet in a stable
GLib release, extensions using GSettings have seen their stable
shell version removed.
Now, typing "make zip-file" will create a standard zip-file for each
extension, with everything necessary, including translations and GSettings schemas.
These files can then be installed with the tweak-tool or uploaded
at extensions.gnome.org
Based on an earlier patch by Jasper St. Pierre.
