GNOME Shell Extensions in Debian 9.0
About
GNOME 3 introduced an extensions framework that allows its users to extend the desktop shell by writing extensions using JavaScript and CSS. It works quite well and dozens of extensions have already been uploaded to the extensions site. Some of these solve some annoyances that users typically share with GNOME, while others add useful functionality.
During DebCamp last year, I started packaging some of these for Debian. That’s been going really well. Now that Ubuntu is finally dropping Unity in favour of GNOME, it helps to serve as a nudge to get this blog post out that’s been stuck in drafts. These extensions also make their way into Ubuntu and other Debian/Ubuntu derivatives.
Here are some extensions I’ve been packaging that’s already in the archive:
gnome-shell-extension-dashtodock
Provides a multitude of options for the shell dock. Not only really useful but also well maintained by upstream, see their website for more info. This is a great extension if you support previous Unity users, since you can set your panel to look and behave very similarly to Unity. I think the app launcher is slightly better in Gnome because apps are easier to discover.
gnome-shell-extension-hide-activities
Simple extension that hides the “Activities” button from the top left corner.
gnome-shell-extension-impatience
Speeds up shell animations. Animations can make the system more usable, but it can also be either distracting or cause some slight delays while waiting for the animation to complete. This gives you a sliding scale that lets you choose how much you’d like to speed it up.
gnome-shell-extension-move-clock
Simple extension that moves the clock from the center of the panel to the right.
gnome-shell-extension-refreshwifi
In gnome-shell, network manager doesn’t automatically refresh the list of available network, which can be quite annoying. Currently a user has to turn wifi off and back on in order to see a refreshed list. This has been fixed upstream and will be in the next version of GNOME. In the meantime, this extension fixes that.
Update: Refreshing wifi in the background has been fixed in Gnome 3.22.2, which is now in stretch. This extension will be removed from the archives.
gnome-shell-extension-remove-dropdown-arrows
Items in the top panel contain dropdown arrows, which are useful for new users who might not be aware that they expand into more entries. For more experience users, the arrows tend to result in extra clutter in the panel, this extension hides those arrows.
gnome-shell-extension-better-volume
This allows you to hover over the volume control indicator and scroll up and down to increase/decrease the volume. Probably another extension that should really just be integrated into gnome-shell by default.
gnome-shell-extension-hard-disk-led
Many new laptops either don’t have a hard disk L.E.D. anymore, or they hide it so that it’s not really all that visible. This extension shows you hard disk activity in your panel. There’s also work being done to make it report reads and writes separately. I’ll be looking at backporting that when it’s available.
gnome-shell-extension-disconnect-wifi
Allows you to disconnect from the current network without having to turn off wi-fi entirely.
gnome-shell-extension-pixelsaver
Title bars can be incredibly pixel-hungry, which isn’t great on small displays. This extension hides the title bar when a window is maximised, and adds control buttons for that window to the top panel.
gnome-shell-extension-system-monitor
gnome-shell-extension-trash
Displays a trash icon to the top panel when there are items in trash. From there you can view or delete the trash contents.
gnome-shell-extension-multi-monitors
This extension adds some tweaks for users of multiple monitors. It’s most useful feature is that you can have desktop overviews on both displays and easily move apps between them.
More extensions
Here are some more extensions packaged in Debian that others have packaged:
- gnome-shell-extension-shortcuts – shows a keyboard shortcut overlay
- gnome-shell-extension-show-ip – shows ip address in the notification area
- gnome-shell-extension-autohidetopbar – hide the top panel
- gnome-shell-extension-caffeine – prevents computer from suspending when enabled
- gnome-shell-extension-mediaplayer – control mediaplayer from the system menu
- gnome-shell-extension-redshift – change colour temperature to improve attention span and sleep paterns
- gnome-shell-extension-suspend-button – adds suspend shortcut
- gnome-shell-extension-taskbar – adds plenty of options for the top panel and optional bottom taskbar
- ugnome-shell-extension-top-icons-plus – moves system tray icons from the bottom hidden menu to the top
- gnome-shell-extension-weather – weather report in panel
- gnome-shell-extensions-gpaste – clipbook manager
- gnome-shell-extension-onboard – on screen keyboard manager
Didn’t make it this time
Both Debian and Ubuntu are in feature freeze right now, and the following didn’t make it in the archives in time, but should be in the following releases (they’re still installable via the extensions site in the meantime):
- gnome-shell-extension-remove-round-corners – remove round corners on top panel
- gnome-shell-extension-proxy-switcher – adds menu in system menu to quickly switch between proxy settings
- gnome-shell-extension-apt-update-indicator – show apt status and available upgrades
- gnome-shell-extension-uptime-indicator- indicator that displays uptime
- gnome-shell-extension-dash-to-panel – great extension that combines the dock into the top panel
- gnome-shell-extension-tilix-dropdown – shortcut configurator for tilix’s quake mode
Next steps
Consider auto-enable
Currently, when you install these debian packages, (most of) the extensions won’t be enabled by default. Users have to use the gnome-tweak-tool to enable them after installation. The rationale behind this is that a system administrator of a network of computers might only want to enable certain extensions for certain users. After some more consideration, I think such administrators will probably already have a system (like a configuration management system) in place to manage this. So, to make it easier for the typical user, I think it’s worth considering enabling these by default with installation. Feedback welcome :)
Debian team
The list of packaged extensions are growing fast, and it would be nice to have these team-maintained. It might be a good idea to start a team for this or use an existing team under the Debian gnome team namespace.
Packaging guide
I’ve packaged enough Gnome extensions to be aware of the typical gotchas and things that need fixing. They’re overall easy to package and a good place to start for someone who wants to get into packaging. I want to put together a good short guide on how to properly package gnome-shell extensions.
Anything else?
Any other extensions you’d like to see packaged? Let me know. Even better, package it yourself and help test my extension package guide (once it exists) so that we can improve that too.
Consider auto-enable: yes please, absolutely. In fact, I think it could be seen as a way for sysadmins to enable this in a scalable way *without* having to tweak around configuration files.. either the package is there or it isn’t on a given workstation..
“Currently, when you install these debian packages, (most of) the extensions won’t be enabled by default. Users have to use the gnome-tweak-tool to enable them after installation.”
I believe the reason for this is that the list of enabled extensions is a single gsettings key. We can override the default system-wide (like GNOME Shell overrides the default for the list of “favourite apps” pinned to the dock), but overriding it to a dynamically-generated value would require non-trivial cooperation between extensions’ maintainer scripts, and any user who has changed the list would not receive the new default anyway.
So implementing this would probably require new “API” design and new upstream code, to be able to cover overrides in both directions (extension A is installed locally by user U and they want to enable it; extension B is installed system-wide but user U doesn’t want to enable it). In particular, enabling all extensions present in a “.d” drop-in directory in /etc would not allow the second form of override.
This seems like something that should absolutely be done upstream.
“The list of packaged extensions are growing fast, and it would be nice to have these team-maintained. It might be a good idea to start a team for this or use an existing team under the Debian gnome team namespace.”
All my extensions are in collab-maint git, and co-maintainers are welcome. I think the reason I didn’t use pkg-gnome was that at the time, pkg-gnome packages were consistently maintained in svn and I didn’t want to touch svn more than I had to.
Also, I’m not convinced that extensions *should* be enabled by default: they change the UX, and not always for the better.
The extensions in the official gnome-shell-extensions package (which is mostly the implementation of GNOME Classic mode) definitely shouldn’t be enabled when merely installed, because if they were, the normal GNOME session would accidentally turn into GNOME Classic whenever the gnome-core metapackage was installed! It would seem inconsistent to auto-enable other extensions, but not that one.
Many of the other extensions are a matter of taste – if they were unambiguously better than stock GNOME Shell, they wouldn’t be extensions, because upstream Shell would just have their behaviour. remove-round-corners, dash-to-panel, dashtodock, hide-activities, move-clock, pixelsaver, autohidetopbar, top-icons-plus all seem like things that are very much a matter of taste: they undermine Shell’s visual design as a pragmatic compromise to make particular things work the way a particular user prefers. (I’m the Debian maintainer of top-icons-plus, and it’s basically a hack to keep deprecated things mostly-working.)
I also wouldn’t want to inflict the caffeine extension on other users of a shared computer – it’s very convenient if you know what it’s for, but it’s non-obvious and not entirely reliable.
Finally, requiring users to enable extensions via gnome-tweak-tool has the side-effect that all users of extensions know how to turn them off! I think there’s value in that.
You *can* hover over the volume indicator and scroll to change the volume without an extension. Better volume just adds visual feedback when you do.
I agree there should be visual feedback by default, ideally the OSD that appears when you use a keyboard volume key.
Thanks for doing this. When I last played with extensions (many years ago) my biggest frustration was them breaking when I upgraded GNOME (minor version bumps). It’s possible that this is no longer a problem, but if it is, this is one big thing that packaging the extensions could address with adequately tight dependencies between extension packages and the gnome ones.
Is there already an extension that let’s you change the users time zone? If so, please package it!
Last time I checked, a user could not change their time zone in Gnome. If a user had root permissions they could change the time zone of the complete system, though. But my system runs on UTC, while my desktop changes time zones all of the time, when travelling.
“Last time I checked, a user could not change their time zone in Gnome. If a user had root permissions they could change the time zone of the complete system, though.”
Sorry, I don’t think this can work. The standard way to configure per-user time zone is an environment variable (TZ) which means if you set it for the whole desktop somehow, you can’t change it without terminating all your user processes (logging out) and starting again, because all the processes that are already running think they already know what the value of TZ is. Changing the system time zone that is used while TZ is unset uses a file (/etc/localtime) which processes can monitor, so it doesn’t have that problem.
Locales have the same problem: you can’t switch your whole session from English to French without logging out.
It’s a historical Unix design issue, rather than a GNOME or freedesktop problem.
About the time zone issue: The need to logout and login again to change the timezone is a minor inconvenience. But currently, one cannot change the time zone at all, only the time zone of the complete system – and only, if root gives their password :~)
A very raw idea would be: The Gnome function to set the time zone could change the TZ variable and additionally send a DBus signal “time zone changed to UTC+12”, and all programs that are timezone-aware need to interpret this signal and call tzset(3) from “time.h”. If they don’t, one can still logout and login and everything would be fine.
Talking about timezones and travelling: Is there already a Gnome clock, that shows more than one time in the panel? Like the cool Orage clock in XFCE? Visible without any clicks etc.? That would make changing the timezone less urgent. Last time I checked, Gnome in Debian did not have such a function.
Super cool. Extensions packaged right for Ubuntu / Debian. Working well in Gnome 3.24.
One extension I would really like to be packaged is gnome-shell-mailnag. The actual maintener is waiting to get Gnome 3.24 in his Arch distro.
https://extensions.gnome.org/extension/615/appindicator-support/
https://extensions.gnome.org/extension/723/pixel-saver/
https://extensions.gnome.org/extension/519/messaging-menu/
https://extensions.gnome.org/extension/1080/transparent-notification/
https://extensions.gnome.org/extension/708/panel-osd/
Nice work. I created before a tiny gnome shell extension, an accessibility indicator to show the state of keyboard modifiers. Generally needed when sticky keys is active (lock or latch mod). But I faced different behaviors in different gnome releases. It doesn’t work in some of them. Gnome was changing quickly and I did bother myself migrating it without edge updated doc (clear change log prepared for extension developers).
Please, how do you test your extension with multiples releases of gnome-shell? or are you just keeping track of debian stable?
Nice job!
I’m a gnome developer and main system is Debian for years. I have a question about debian packaging… Is it possible to see the git repo for this extensions package? I want to make my own deb package and I want to see an example for it with all autogen.sh/.am/ac autotools scripts?
Best regards, konkor (https://extensions.gnome.org/extension/1082/cpufreq/ https://extensions.gnome.org/extension/1254/obmin/).
Dear Konkor: You can find the source code of all Debian packages very easy:
0. First find your package. E.g. gnome shell extensions: apt search gnome-shell-extension and you get a list.
1. If you have deb-src lines in your /etc/apt/sources.list (or /etc/apt/sources.list.d/*.list), you can do “apt source packagename” and get the source code of a package.
2. Go to https://tracker.debian.org/ and type in the name of a package. E.g. type gnome-shell-extension- and tracker will autocomplete. Also you will find on the package page links to the git (or other VCS) repository, if the maintainer does use one.
3. Use dgit: dgit clone packagename and you get a local git repository containing the package source code.
There are more ways, e.g. use “dget” (with “e”, not “i”), or use codesearch.debian.net.
Thank you Martin!
I found all out. I did make the debian package https://github.com/konkor/obmin/tree/master/releases it was a bit tricky because the package has binaries, man pages, global icons, desktop shortcuts and the gnome extension…
Now I have an other question. How to find a sponsor or a maintainer for Debian repositories. Should I go to the some IRC channel or what?
Thanks again, Martin.
Hi konkor, I assume, you should either go to the #debian-mentors IRC channels on OFTC or to the debian-mentors mailing list (https://lists.debian.org/debian-mentors/). Just remember, that Debian is a volunteer project, so sometimes one has to have patience. Maybe you don’t get a response immediately, etc. You could also write an email to one of the maintainers of existing Gnome extensions and ask politely, whether they would sponsor. Again, remember, that they are volunteers and might not always respond immediately. Good luck! :~)
Martin, thank you again!