Reference: https://jsdoc.app/about-getting-started

I don't know the convention for using custom icons in an extension.

Here's a good example of that.

I want symbolic version of this (source):

Show blocker-acquiring-symbolic icon indicator while it is being enabled.

Some inspiration.

For some reason, the extension works when being ran in a nested GNOME Shell session, but it doesn't work when ran on an actual GNOME Shell session.

I had no luck looking at the logs with:

journalctl --no-pager --since "1 hour ago" | grep pkexec

Right now, the extension doesn't remember what state it was in when a GNOME Shell session starts. We should save that in a gsettings schema.

Here's what it needs to contain:

• How it works (why it needs authentication, limitations, etc)
• How to install
  • The extension (e.g.o)
  • hBlock (PACKAGES.md)
• Where to report errors
  • False positives: hBlock
  • Everything else: right here
• Attribution
  • GSConnect: code examples of Subprocess
  • GJS documentation: code examples of Subprocess
  • Caffeine: code examples of custom icons
  • hBlock: all the heavy lifting
• How to know if it's working

Move all source files to /src, then have separate files for:

• BlockerIcons (icons.js)
• BlockerNotifier (notifier.js)
• BlockerRunner (runner.js)
• BlockerIndicator (indicator.js)

Only BlockerExtension should remain in extension.js.
The GJS guide on importing modules is here.

Many things are tied to the checked property of the toggle (the "blocked-enabled" preference, the visibility of Blocker indicator, etc). The problem is that this property changes as soon as the toggle is clicked, although the command that it triggers may fail.

We need to figure a way to "rollback" the change in the checked property if the command failed, but I don't know I could do that. Another idea would be reacting to a clicked signal and only change checked if the command was successful.

Now that we use a different icon for when hBlock is running, a notification is a bit too intrusive. We can start using notifications only when the command fails.

Perhaps a Makefile can work well for this. Some inspiration.

Although hBlock is MIT licensed, that only covers the software, not the brand. Besides, it's also really hard to tell the purpose of an extension called "hBlock toggle" if someone doesn't know what hBlock is. Here are some ideas:

• Blocker
• Blockade
• Barricade
• Bastion
• Fort
• Fortress
• Rampart
• Ward
• Warden
• Bulwark
• Fence
• Guard
• Crest
• Harbor
• Haven
• Herald (perhaps Harold, as a wordplay?)

Here's the GJS doucmentation on how to do that: https://gjs.guide/guides/gio/subprocesses.html#communicating-with-processes

To run it, install the necessary tools with:

npm install -g [email protected] eslint-plugin-jsdoc

Then lint with:

npx eslint *.js --config .eslintrc.yml

Follow the instructions here: https://gjs.guide/extensions/review-guidelines/review-guidelines.html#use-a-linter

Here are the plans:

• Use custom icon
• Redirect to hBlock installation instructions if hBlock is not detected

Running hblock populates the /etc/hosts file with hundreds of thousands of entries, so it can take a while. It's better to run this async, so it doesn't lock the whole UI of GNOME Shell.

Currently, a new notification is created and added to Main on every notification. Besides, they don't self-destruct when their pointers are nullified (as far as I know). For that to happen, we need to add:

source.connect('destroy', ()=>{this.notifSource = null;});

This comes from here.

Either keep only one notification (see this example) or make the notifications transient with isTransient: true.

Currently, Blocker only checks if hblock is installed when the extension is loaded. It should also check that whenever it tries to run a command.

I was able to get custom notifications working because of examples from https://github.com/dsheeler/gnome-shell-extensions-gravatar and https://github.com/swsnr/gnome-shell-extension-picture-of-the-day.