[Release] Follow the GNOME Shell Extensions Review Guidelines - Take 2

[JordanViknar]

General Guidelines

• Don't create or modify anything before enable() is called
• Use enable() to create objects, connect signals and add main loop sources
• Use disable() to cleanup anything done in enable()

General Tips

• Write clean code, with consistent indentation and style
• Use modern features like ES6 classes and async/await
• Use a linter to check for logic and syntax errors

Rules

• Only use initialization for static resources
  Extensions MUST NOT create any objects, connect any signals, add any main loop sources or modify GNOME Shell during initialization.

• Destroy all objects
  Any objects or widgets created by an extension MUST be destroyed in disable().

• Disconnect all signals
  Any signal connections made by an extension MUST be disconnected in disable().

• Remove main loop sources (N.A)
  Any main loop sources created MUST be removed in disable().

• Do not use deprecated modules
  Extensions MUST NOT import deprecated modules.

• Do not import GTK libraries in GNOME Shell
  Extensions MUST NOT import Gdk, Gtk or Adw in the GNOME Shell process.

• Do not import GNOME Shell libraries in Preferences
  Extensions MUST NOT import Clutter, Meta, St or Shell in the preferences process.

• Code must not be obfuscated
  Extension code MUST be readable and reviewable JavaScript.
  (Not sure how that applies to TypeScript code. Do I need to preserve comments ?)

• No excessive logging
  Extension MUST NOT print excessively to the log. The log should only be used for important messages and errors.

• Scripts and Binaries
  Use of external scripts and binaries is strongly discouraged.
  In Noiseclapper, this is unavoidable. I have yet to find an equivalent I can use in JavaScript directly for Python's socket library.
  However, I believe my usage should be tolerated, especially since the removal of SoundcoreLifeAPI months ago.

• Privileged Subprocess must not be user-writable (N.A)

• Extensions must be functional
  Extensions are reviewed, but not always tested for functionality so an extension MAY be approved with broken functionality or inoperable preferences window.

• metadata.json must be well-formed
  The metadata.json file that ships with every extension should be well-formed and accurately reflect the extension.

• Session Modes (N.A)

• GSettings Schemas
  For extensions that include a GSettings Schema:

  • The Schema ID MUST use org.gnome.shell.extensions as a base ID.
  • The Schema path MUST use /org/gnome/shell/extensions as a base path.
  • The Schema XML file MUST be included in the extension ZIP file.
  • The Schema XML filename MUST follow pattern of .gschema.xml.

• Licensing

• Copyrights and trademarks
  (Not sure how that applies when the name Soundcore is simply used in the description to... well, say the project is for Soundcore headphones. Should be fine with the disclaimer I put in the settings window.)

Recommendations

• Don't include unnecessary files
• Use a linter
• UI Design

[JordanViknar]

Development is currently paralyzed by exams.

For those who cannot compile the project, here's an already prepared file in the meantime.
[email protected]

Install it with

gnome-extensions install [email protected]

[JordanViknar]

• Use a linter

Completed by #16 and 0abdd86

[JordanViknar]

Gonna attempt to pass a review once again now that everything has been checked, good luck to me. 😎

[JordanViknar]

Gonna attempt to pass a review once again now that everything has been checked, good luck to me. 😎

Well at least there's only one thing wrong this time.

[JordanViknar]

Gonna attempt to pass a review once again now that everything has been checked, good luck to me. 😎

Well at least there's only one thing wrong this time.

Fixed by 8fd68cb

[JordanViknar]

👍