Xgettext learned about template strings now, which is good. However
it's still buggy, so instead of the "classic" xgettext issue with
backticks, we now have exciting new issues to find work-arounds for.
One issue is that it doesn't detect backticks inside string constants
as regular characters, so having an odd number of backticks throws off
its regex.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/792
We disable and enable extensions inside the `notify::active` signal
handler, but we shouldn't do that in case the change didn't come from
the user but because something else changed the state of the extension.
This causes an issue when the extensionPrefs window is open and the
session gets locked: The extensions are temporarily disabled by the
shell, extensionPrefs updates its switches on the state change and adds
those extensions to the `disabled-extensions` gsettings key inside the
signal handler. Now when the session is unlocked again, the extensions
won't be enabled again since they're forced-disabled.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/705
gjs no longer has an implicit dependency on GTK 3.0, so without
requesting an explicit version, we will get the highest available.
Our code isn't GTK-4 ready, so request 3.0 explicitly.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/686
By direclty using the underlying GSetting, whether or not an extension
appears as enabled or disabled currently depends only on whether it is
included in the 'enabled-extensions' list or not.
However this doesn't necessarily reflect the real extension state, as an
extension may be in error state, or enabled via the session mode.
Switch to the extensions D-Bus API to ensure that the list of extensions
and each extension's state correctly reflects the state in gnome-shell.
https://bugzilla.gnome.org/show_bug.cgi?id=789852
Extensions are used to calling the getCurrentExtension() utility function,
both from the extension itself and from its preferences. For the latter,
that relies on the extensions map in ExtensionUtils being populated from
the separated extension-prefs process just like from gnome-shell.
This won't be the case anymore when we switch to the extensions D-Bus API,
but as we know which extension we are showing the prefs dialog for, we
can patch in a simple replacement that gives extensions the expected API.
https://bugzilla.gnome.org/show_bug.cgi?id=789852
Each row represents an extension, so it makes sense to associate the
rows with the actual extensions instead of linking rows and extensions
by looking up the UUID in the external extensions map in ExtensionUtils.
This will also make it much easier to stop using the shared extension
loading / map in favor of the extension D-Bus API.
https://bugzilla.gnome.org/show_bug.cgi?id=789852
The existing 'ExtensionStatusChanged' signal has a fixed set of parameters,
which means we cannot add additional state without an API break. Deprecate
it in favor of a new 'ExtensionStateChanged' signal which addresses this
issue by taking the full serialized extension as parameter.
https://bugzilla.gnome.org/show_bug.cgi?id=789852
Extension preferences Application class is just a container for a GtkApplication
so instead of using composition we can inherit from the base GObject class.
Also replace signal connections with vfunc's.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/631
The current code is carefully avoiding an overly wide line length as
well as adding literal new lines to the string due to indentation. It's
clever and barely legible.
Instead, use one string per line similar to how they appear in the actual
output, and join them together when setting the clipboard text.
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
After the Adwaita refresh, the button shows up oval rather than
circular. To address this, make sure that the "image-button" class
is applied as well by using the dedicated setter function.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/482
Currently when a preference widget fails to load, we throw a raw
backtrace at the user. While that is undoubtedly useful information
for extension developers and bug reports, it is gibberish to most
users and hardly the first thing they should be exposed to.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/193
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
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
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
Since 5b3fb024be, the main window is only shown when not launched
with a valid UUID. As GtkDialog isn't meant to be used standalone,
we currently trigger a (harmless but annoying) warning in case
the main window isn't shown; we can avoid the warning by setting
up the preference dialog manually instead of using the GtkDialog
convenience class.
https://bugzilla.gnome.org/show_bug.cgi?id=781545
Update according to the latest mockups:
- don't use a border around the list as specified
by the latest HIG version
- use more generous spacing between controls
- allow extension descriptions to take up two lines
- drop GNOME branding from the window title
- make the app name consistent with the window title
https://bugzilla.gnome.org/show_bug.cgi?id=778672
While the extension prefs tool is not meant as the primary way for
users to configure extensions - that will be Tweak Tool - it still
doesn't hurt to expose the extension kill switch to easily turn
extensions back on after a session crash.
https://bugzilla.gnome.org/show_bug.cgi?id=778664
ScrolledWindow changed its allocation behavior, and the extension
list only takes up the minimum width rather than the available
width as intended. To get the previous behavior back, we need
to set the newly added :propagate-natural-width property ...
https://bugzilla.gnome.org/show_bug.cgi?id=771391
Our current UI is horrible in dealing with outdated extensions - we
don't give users any indication at all that something is not working as
expected (unless hiding the prefs button as we did until the last commit
counts).
To fix this, make the enable switch insensitive to indicate OutOfDate
extensions.
https://bugzilla.gnome.org/show_bug.cgi?id=736185
It is confusing to treat outdated extensions as if they didn't exist
in some places, but like any other extensions elsewhere. In particular
gnome-tweak-tool still allows to launch prefs for them while making
it clear to users that the extension will not work - opening the
list of installed extensions in that case is unexpected and confusing.
Just remove the version check for now, we will soon follow tweak-tool
and use it to disable the extension switch instead.
https://bugzilla.gnome.org/show_bug.cgi?id=736185
The extension-prefs tool is used by gnome-tweak-tool and the
extensions web site to display preferences. However as those
already implement their own extension lists, the main window
is not useful in that context (to not say it is rather silly).
Just skip the main window and only show the specified extension's
preference dialog in those cases.
https://bugzilla.gnome.org/show_bug.cgi?id=730829
Bring the extension-prefs tool in line with the mockup by adding
switches to enable/disable extensions, similar to the extension
page in gnome-tweak-tool.
https://bugzilla.gnome.org/show_bug.cgi?id=730829
The extension-prefs UI has never been great, but as the GNOME 3
design patterns are evolving, it is starting to look seriously
outdated. Modernize the UI a bit to have it fit in a bit better.
https://bugzilla.gnome.org/show_bug.cgi?id=730829
The asynchronous nature of extension loading, session loading, and more,
makes the code racy as to what is initialized first, and hard to debug.
Additionally, since gjs is single-threaded, the only code we're running
in a thread anyway is readdir, which is going to be I/O bound, so the
code here is actually likely to be faster.
Drop this in favor of some good old fashioned synchronous loading.
gnome-shell-extension-prefs supports opening a specific extension's
preferences directly from the command line by passing the UUID.
However this broke when extension loading was changed to be processed
asynchronously, as no extension has been loaded when the command
line argument is processed. Fix by deferring opening the extension's
preferences until all extensions have been loaded.
https://bugzilla.gnome.org/show_bug.cgi?id=694858
This allows us to move to a file-monitor based approach in the future.
Since we need signals, we convert the current set of functions to an
object we attach signals too, leading to the new ExtensionFinder object.
https://bugzilla.gnome.org/show_bug.cgi?id=677586
The "extension" object is what I previously called the "helper" object.
It contains the extension importer object as well as the metadata object.
Things that were previously added on to the metadata (state, path, dir, etc.)
are now part of this new "extension" object.
With the new importer changes brought on by the extension prefs tool,
extensions are left without a way to import submodules at the global scope,
which would make them rely on techniques like:
var MySubModule;
function init(meta) {
MySubModule = meta.importer.mySubModule;
}
That is, there's now a lot more meaningless boilerplate that nobody wants
to write and nobody wants to reivew.
Let's solve this with a few clever hacks.
Allow extensions to get their current extension object with:
let extension = imports.misc.extensionUtils.getCurrentExtension();
As such, extensions can now get their own extension object before the
'init' method is called, so they can import submodules or do other things
at the module scope:
const MySubModule = extension.imports.mySubModule;
const dataPath = GLib.build_filenamev([extension.path, 'awesome-data.json']);
https://bugzilla.gnome.org/show_bug.cgi?id=668429
A new tool, 'gnome-shell-extension-prefs' can load a new entry point from
extensions, 'prefs.js', which has an entry point to return a GTK+ widget.
This allows extensions to have their own preferences dialog, without each
extension needing to ship its own Python script and .desktop file.
https://bugzilla.gnome.org/show_bug.cgi?id=668429
