: VCS matches the version in the archive
- Git: https://salsa.debian.org/gnome-team/shell-extensions/gnome-shell-extension-appindicator.git
- Branch: debian/master
- Path: debian/changelog
- Browser: https://salsa.debian.org/gnome-team/shell-extensions/gnome-shell-extension-appindicator
- Last scan: 2021-07-19 06:34:10+00
- Next scan: 2021-07-26 22:09:00+00
- Debian changelog in Git:
gnome-shell-extension-appindicator (40-1) experimental; urgency=medium
[ Marco Trevisan (Treviño) ]
* New upstream release:
- statusNotifierWatcher: Emit StatusNotifierHostRegistered (and
Other signals we were missing for long time, the specs includes these
signals and they should be emitted when the watcher appears/disappears
So do this, although it seems that Qt apps are still ignoring it.
- indicatorStatusIcon: add polyfill for versionCheck in GNOME 40
- iconCache: Do not dispose the icon when clearing the cache.
The icon can be a property of the Gio.EmblemedIcon and we should not
dispose it as its parent doesn't support handling the child removal
- metadata: Remove 40.beta as supported given we support 40 already.
- promiseUtils: Promptly remove a source if was already cancelled
- promiseUtils: Disconnect cancellable when the promise is resolved.
In CancellablePromise we were connecting to the cancellable in order to
monitor its cancellation, however we never disconnected from it and this
was causing gjs to keep a reference on the promise itself, being the
scope of the cancellable callback, and thus never garbaging collecting
both the promise and its children (such as GSources).
So, connect earlier to the signal and once we've resolved the promise,
disconnect form the cancellable.
- promiseUtils: Disconnect cancellation signal after resolving or rejecting.
As per the previous commit we do disconnect from cancellation, but this
happens too early so the cancellation event isn't ever tracked.
We need in fact to handle it after that the promise is resolved or
In the rejected case, we need to be extra careful though, as in case
the cancellation happens as per cancellation's ::cancelled signal
callback we need to do this in the next idle cycle or we'll deadlock.
- prefs: Use es6 class and support Gtk4. GNOME 40 requires it
- appIndicator: Do not lower opacity on versions after GNOME 40.
There's no such effect upstream anymore so we don't want to switch that
- appIndicator: Also toggle desaturate effect on mouse hover
- settingsManager: Move gsettings initializtion to SettingsManager.
Quite simple class for now but it avoids us to initialize a new
gsettings instance for each indicator
- appIndicator: Track hover status using native StWidget's hover property
- IndicatorStatusIcon: Bind hover property with child IconActor.
Whatever happens during hover on the whole indicator (including label)
should affect also the icon, so we can just bind the hover property
- appIndicator: Use more consistent names for settings updates
- appIndicator: Cleanup emission of icon signal on status changes.
We were handling this already in a common place, so let's move there
- appIndicator: Get and expose the accessibility name.
Some indicators (such as the Ayatana appindicator based) may include
accessible descriptions so read and expose them if any or fallback with
the indicator title otherwise.
- appIndicator: Do not reload icons when updating the effects applied to it.
Those are just effects that are not dependent on the icon content, so
we can just update the icon without having check the effects all the
- trayIconsManager: Move handling of legacy tray icons into a nicer class.
Also move more into the wrapper AppIndicatorsIndicatorTrayIcon, and use
Shell.TrayManager's unmanage_screen() in newer versions of the shell
instead of relying on the ugly (and unreliable) tray unset + garbage
- indicatorStatusIcon: Use the accessible name or WM class for a11y.
We wrongly passed the indicator unique id as the accessible name to the
shell for ages, we must instead use something that the screen readers
may use for that.
So, on appindicators we can use the exposed accessible name while for
tray icons we can try use the wm class, even if it could be very generic
- indicatorStatusIcon: Do not create a menu for tray icons
- util: Wait for display opened only on X11 setup.
This is actually only relevant for wayland sessions with Xwayland, as
it may lead to opening the X11 display with some delay.
But let's keep it to be a bit more conservative, and unblock the case
for setups with no-x11 at all.
- appIndicator: Use custom theme icon based on Shell one as default theme.
Especially under wayland we should avoid to get the theme from the
default gtk one as it may be always unset, as it depends on the Gdk
Screen that is undefined in such scenario.
So add an helper function to create a new Gtk theme using the shell's
gtk icon theme and try to use it when no default gtk theme is available.
We could probably do this in all the cases, but for now let's keep X11
environment as it is.
* debian/gbp.conf: Do not use patch numbers
* debian/patches: Refresh
* debian/control: Add full support to gnome-shell 40
* debian/control: Update extension description
* debian/patches: Use meson based build system
* debian/control: Build depend on jq and meson
* debian/rules: Do not install compiled schemas
* debian/control: Add suggestions on extension prefs and libappindicator
* debian/upstream/metadata: Add upstream references
* debian/control: Use dh-sequence-gnome.
In this way we also get for free ubuntu-specific tools such as
dh-translations without having to do an ubuntu-specific fork
[ Fini Jastrow ]
* Add icon opacity, size, position and other effects settings.
The icons can be very colorful. Some people might not like it and older
icons do not blend too well with newer monochrome ones.
Add settings to configure multiple values of the icons and in
- Icons position in the panel
- Icon size
As per this a new preference dialog is provided to configure such values
* appIndicator: Fix resizing pixmap icons
Icons created from pixmaps can not be resized (properly).
When we create a icon from a pixmap we actually crate the icon in the
native size. For example if the smallest available pixmap is 22 px the
icon will also be 22 px, regardless of requested icon size.
This is ok if the pixmap is by chance the requested size. But this is
not always the case, especiually if the icon size is user selectable.
So after creating the pixmap image we tell it how big it shall be.
[ jingi_jeong ]
* feature: Add topicons-plus extension logic.
To add support to legacy tray, merge topicons-plus extension logic.
Create topicons.js file and connect with original appindicator code.
-- Marco Trevisan (Treviño) <email@example.com> Tue, 15 Jun 2021 01:18:26 +0200
- This branch is even with tag debian/40-1