GNOME Shell Extensions in Debian 9.0

You may also like...

17 Responses

  1. anarcat says:

    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..

  2. smcv says:

    “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.

  3. smcv says:

    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.

  4. Greg K Nicholson says:

    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.

  5. Jonathan says:

    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.

  6. Martin says:

    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.

  7. smcv says:

    “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.

  8. Martin says:

    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.

  9. Claude says:

    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.

  10. Abdellah says:

    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?

  11. konkor says:

    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 autotools scripts?
    Best regards, konkor (

  12. Martin says:

    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 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

  13. konkor says:

    Thank you Martin!
    I found all out. I did make the debian package 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.

  14. Martin says:

    Hi konkor, I assume, you should either go to the #debian-mentors IRC channels on OFTC or to the debian-mentors mailing list ( 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! :~)

  15. konkor says:

    Martin, thank you again!

  1. 6 April 2017

    […] GNOME Shell Extensions in Debian 9.0 […]

Leave a Reply

Your email address will not be published. Required fields are marked *