Gnome Shell Extension Reloader Extension

• The Extension Reloader is compatible with Wayland and Xorg .
• The Extension Reloader is a debugging tool for Gnome Shell Extension writers.
• A panel button is provided which presents a menu of installed extensions.
• The panel button can be located to left, right, left center or right center of the panel.
• The scrolling menu is sorted by extension state numerically and extension name.
• The extension states are:
• 0 Unknown, 1 Enabled, 2 Disabled, 3 Error, 4 Out of Date, 5 Downloading, 6 Initialized
• The Extension Reloader will reload extensions in states 1, 2, 3 and 6.
• The Extension Reloader uses the shell's Extension Manager to perform the reload.
• Extensions in state 1, 2 and 6 ARE NOT read from disk when reloaded.
  For explanation see:
  https://bugzilla.gnome.org/show_bug.cgi?id=782186
  https://bugzilla.gnome.org/show_bug.cgi?id=782187.
• An extension in the Error state IS read from disk when it is reloaded.
• A message is displayed after the Gnome Shell Extension Reloader executes a reload request.

• The following are examples of the messages which can be displayed.
  
  
• 
  The reload of an extension in the Error state failed due to an error in the code of the extension being reloaded. The extension writer can make changes to the code on disk and repeat reloads without a session restart when the extension being debugged remains in the Error state.
  
  
• 
  The code of an extension in the Error state was corrected and then reloaded successfully.
  
  
• Xorg Session Wayland Session
  
  The extension reloaded was NOT read from disk. Any changes to the code on disk were not tested. Any code changes made to an extension NOT in the Error state must be loaded into memory by a session restart for the reload to be useful. It is important to remember to restart the session before reloading when debugging an extension not in the Error state which has errors affecting the proper operation of the extension. For operational errors (1) Make your code changes. (2) Restart the session. (3) Test to determine if the operational problem has been solved. (4) Return to (1) if the operational problem has not been solved.

Debugging extensions requires examination of the system log. Most Linux Distributions use systemd. The systemd command journalctl is very useful for debugging extensions. Using the Xorg Session when debugging allows "Alt F2 r" to read the extension code from disk before reloading. Wayland requires logout and login.

Debugging extension in Error [state 4]

Start journalctl with the -f option and direct the output to a file.

$ sudo journalctl -f > /tmp/error.txt

Reload the extension that failed.

Stop journalctl with "Ctrl c"

$ cat /tmp/error.txt or examine the file with an editor.

Near the end of the file you should find logging that identifies why the extension did not reload.

... Reloading Activities Configurator...
... JS ERROR: Extension activities-config@nls1729: ImportError: No JS module 'cairov' ...

Debugging extensions which are not in Error [state 4]

Coding errors can exist that do not prevent an extension from loading. When the erroneous code is executed a JS error can occur. The following example is a an error which occurs when a preference is selected. In this example journalctl -f is started in a terminal session. The preference is selected and the error is immediately identified in the journalctl terminal session.

In this case setting a preference fails due to a simple coding error, "thia" instead of "this".

... JS ERROR: ReferenceError: thia is not defined
... extensions/activities-config@nls1729/extension.js:455:9

If you can create an instance of an extension error by manual action simply monitoring the output of journalctl -f can reveal the code in error.

If the problem does not generate a JS error, it may generate a warning or other useful messages.
Using journalctl -f or journalctl --no-pager > /tmp/error.txt with the log function can be effective in isolating the problem.

log ('Debug: 001 START');

suspected extension code...

log ('Debug: 001 END');

Using numbered log function pairs along the expected execution path can verify the code is executing in the expected sequence.

The system log receives messages from many sources in real time. Selectively displaying the messages with grep is useful. Using "journalctl -f | grep Debug:" can uncover cases where a segment of code is not executed or not executed completely.

The contents of variables can be verified.
log ('Debug: 020 this._var = ' + this._var);

Example:



$ sudo journalctl -f | grep Debug

...gnome-shell[2009]: Debug: 001 START
...gnome-shell[2009]: Debug: 001 END
...gnome-shell[2009]: Debug: 020 leftTiled = true rightTiled = false
...gnome-shell[2009]: Debug: 001 END
...gnome-shell[2009]: Debug: 001 START
...gnome-shell[2009]: Debug: 020 leftTiled = false rightTiled = true
...gnome-shell[2009]: Debug: 001 END

The log function is very useful in debugging extensions.