I’m using Ubuntu 18.04, which has Gnome Shell 3.28 (3.28.3+git20190124-0ubuntu18.04.1).
After I updated the extension to latest release (16), it fails to start. Gnome Shell reports this error:
Extension "System_Monitor@bghome.gmail.com" had error: TypeError: GObject.registerClass() used with invalid base class (is PanelMenuButton)
Downgrading to release 14 makes it work again.
Ubuntu’s appindicator extension has a similar issue from a while back, with pointers to an issue with the extensions website, but I’m unsure if this is related.
In any case, I decided to open this issue to at least document it. Feel free to close it if it’s intentional (Gnome Shell 3.28 no longer supported), or otherwise not a bug with System Monitor.
Tested this again and it seems to have been fixed at some point by some Ubuntu (18.04) updates: my test user still had version 8 of the extension, and I could no longer reproduce the issue, neither before nor after updating the extension to release v9. My main user’s desktop now also appears unaffected.
(I was going to try the workaround reported by @ChrisLancs, but ended up not having to. My ”List type” is set to ”Disabled”.)
Alternatively, after adding the PPA, replace ’cosmic’ with ’bionic’ in the sources list, as the package for Bionic currently appears to install and work in Cosmic just fine (from my brief testing).
So I did a little more digging, and found that this actually first cropped up in Ubuntu 17.10.
I then ran mozregression (back on 18.04, my main desktop) and here’s what it found:
7:12.48 INFO: Last good revision: 64bab5cbb9b63808d04babfbcfba3175fd99f69d (2017-10-25)
7:12.48 INFO: First bad revision: aa958b29c149a67fce772f8473e9586e71fbdb46 (2017-10-26)
7:12.48 INFO: Pushlog:
After that ”There are no build artifacts on inbound for these changesets (they are probably too old).”
As this was my first time ever using mozregression, I have no idea how useful that was, but if there’s some way I can narrow this down further, I’d be happy to.
Adrian: Thanks for taking a look! I’m using Ubuntu 18.04, and that appears to be crucial here: I created a 16.04 VM, installed all in-release updates (including Firefox 63), and just as you, was unable to reproduce the issue. I then upgraded the VM to 18.04 and the bug immediately manifested again.
I first reported this against 62 in Launchpad: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1798103
Firefox was since updated to 63 in Ubuntu and the issue remains.
Under Apache Web server configuration, there’s a prompt to create a symlink to enable the newly created site:
ln -s /etc/apache2/sites-available/nextcloud.conf /etc/apache2/sites-enabled/nextcloud.conf
As the instructions in this section are written for Debian, Ubuntu, and their derivatives,
a2ensite should be used instead:
The commands are currently functionally equivalent (AFAIK), but should this change sometime, the latter would be more future proof, besides being much shorter and easier to type.
Additionally, immediately following the
ln -s there is a section about Additional Apache configurations, which correctly instructs the use of
a2enmod to create the symlinks. Replacing
ln -s with
a2ensitewould thus harmonize the two sections.
All right. Thanks, Jeremy!
Some years back (2013/2014 maybe?) the ’New Window’ and ’New Tab’ menu items were combined into a single ’New Terminal’ item.
This apparently met with resistance from users, so Fedora and recently also Ubuntu have chosen to build Gnome terminal with
DISUNIFY_NEW_TERMINAL_SECTION to restore the old behavior.
This unfortunately leaves users of those distros, like myself, who actually prefer the simplicity of ’New Terminal’, with no practical way to restore that functionality (beyond rebuilding the package with the compile-time switch reverted).
After hearing me out, the Ubuntu maintainer suggested I file a bug here, asking to turn the compile-time option into a Gsetting so that the behavior could be more easily adjusted per user preferences.
So that is what I’m asking here.