Commits on Source (43)
-
Marco Trevisan authored
Fixes #212 LP: #1881669
678a4240 -
Marco Trevisan authorede0022db1
-
Marco Trevisan authored
LP: #1870795
33aef8fe -
[why] The spacing between icons shown by us seems a bit too wide. A lot of people would rather have a smaller distance between the icons. [how] Top bar buttons have a given padding. Additionally to that we pad the icons a bit more. That padding can be removed, without violating the design goals imposed by the top bar (i.e. menu button padding). This makes the visual appearance a bit more pleasing. And still conforming. I'm sure people will want to further decrease the distance, but that will violate the required button padding. A composite button would have to be used then instead (like the aggregate menu does). Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de> LP: #1896779
a4748f73 -
[why] We remove all style settings from the gnome-shell.css that usually affect the menu buttons. This includes the default icon size. When the icon has some 'other' size, this will leave us with garbage. [how] Just overwrite the padding of the system gnome theme. Keep all other style settings intact (including icon size). [note] We do not query the current style to build the new style, because (at least at the moment) no other style setting is done anywhere. When in some point in the future a style is set before this new line (which in unlikely, because it is at the top of the constructor), we would have to assemble the new setting more carefully. Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de> LP: #1896779
9c20756f -
Gnome Shell enables the extensions before the desktop itself is ready to accept widgets. This can result in errors. In the case of appindicator, it results in applications that are launched during startup not showing an indicator because, when the extension tries to add the icon to the Gnome Shell interface, it still isn't ready for that, thus failing. But other applications, launched after the Shell has completed the startup process, will work fine. This patch fixes this by checking in the `enable()` method if Gnome Shell is still starting up, in which case it waits until the `startup-complete` signal is triggered before continuing. LP: #1870795
8413a0bf -
It seems that the reason for not showing sometimes the appindicators during startup is because Gtk.IconTheme.get_default() returns NULL. This seems to happen only very early during startup, so this patch waits until it returns a valid value before continuing enabling the extension. Of course, this patch is just a hack. If this really fixes the problem, the bug must be fixed upstream. LP: #1870795
dfce4bf0 -
LP: #1849142
b084b692 -
Gdk.DisplayManager has a signal to specify when the default display is available. This patch makes use of it to detect when the enable work can continue. It also does the waiting for the display and for 'startup-complete' in parallel. LP: #1870795
d94fe381 -
Marco Trevisan authored
LP: #1849142
361ff315 -
LP: #1896785
4c14a3c7 -
Marco Trevisan authored
This is not defined by the official API (nor we implement it), so let's get rid of it. LP: #1896785
fcf6ee52 -
Marco Trevisan authored
And also remove the idle if instead we got a valid icon meanwhile. This may happen in the case that the icon ID (and so name or size) changed since the time we requested an invalid icon, and in such case we would still have the idle running. So we need to ignore a new one in case the new icon is still invalid, while we need remove the source if the new icon is available. LP: #1849142
9257613d -
Marco Trevisan authored
We do suport it, even if with some limitations
e3b0af02 -
Marco Trevisan authored
Use the actual name for RegisterStatusNotifierHost and ensure that we return an error in the expected way. LP: #1896785
a5db2a31 -
Marco Trevisan authored
Ensure we won't miss or mis-use other method or signal again LP: #1896785
e6b3441c -
Marco Trevisan authored
We don't support those, so there's, no point to expose the properties to GLib as it may create resources for that, and we would end up monitoring tooltip changes. LP: #1896785
7285bd48 -
Marco Trevisan authored75934c40
-
Marco Trevisan authored
In case we cancelled a request we already removed the set, so we won't find it. So first check if we can complete the operation, in case we can we can delete the cancellable, otherwise do it only in case of another un-handled error
3107e9a5 -
Marco Trevisan authoredaf161751
-
Marco Trevisan authored
Use some more modern JS code to handle this
f70938c9 -
Marco Trevisan authored
No need to be so verbose in new JS to create an object with a variable key
fd88ad03 -
Marco Trevisan authored
This is currently and normally just a key value, but even in the case we'd get multiple properties, we don't care about their contents here.
466f138e -
Marco Trevisan authored3720099d
-
Marco Trevisan authored
When updating icons we temporarily mark the current icon as not in use, however if we return it as it matches the cache, then we must mark it again as inUse, otherwise will be removed from the cache.
f7488bdd -
Marco Trevisan authored
The icon cache expects the icons to be marked as "inUse" as still valid, however we were not setting this parameter correctly: - When setting it to true, we need to ensure that the cached icon that we got from the IconCache is actually the one we're using (as we may be using an equal object, but not the same instance). - When unsetting it, we need to read the actual Icon from the parent Gio.EmblemedIcon or Gio.Emblem.
bd6fff0b -
Marco Trevisan authored
The icon cache has been built with the idea of caching actors, however now we only cache the actual actor contents which is eventually always a GIcon, so there's no point to complicate it. Also use native JS Maps and remove destroy notification support, as icons have not such capability anymore. As per this, when returning the GIcon added to the cache we need to make sure that we're returning the object that is actually in the cache and not an equal object that may be already there.
713619b6 -
Marco Trevisan authored
It means nobody required it so far, so we're free to dispose it.
a402cb99 -
Marco Trevisan authored
No need to cleanup the icons all the times, even if there are many it's unlikely that we're going to reuse them in the last minute, so now the garbage-collector is ran each minute, and each time we request for an icon we increase its life of 10 seconds.
6aa7a4ae -
Marco Trevisan authored
No need to try to check properties that we don't ever had in the proxy, so let's use the cached properties a base, plus the extra ones intersected with the ones we actually care about (that are listed in the interface file).
194f5d52 -
Marco Trevisan authored
Those variants are quite big and even for smaller icon set we may loose various milliseconds only to check if a property content changed (when the client already said us so). Thanks to @kanru, as per comment [1]. [1] https://github.com/ubuntu/gnome-shell-extension-appindicator/issues/226#issuecomment-646953956 Closes: #226 LP: #1884396
a4199361 -
Marco Trevisan authored
Use a quick timeout (set to 16ms, that is still our 60fps target) to make possible to batch properties changes so that if more than one come together we can just send out one signal. This also ensures that many inter-connected properties are handled in order. Potentially we could also stop the property changes emission when a property request is cancelled, but if we already got a result when another one is requested we can proceed sending the one we already have, without need to complicate the code here.
4af79b8a -
Marco Trevisan authored
When an indicator updates its properties very often, the shell may slow down so let's limit the number of updates per second (right now set to about 4) by accumulating the received signal changes and performing the properties update with some delay. Helps with #226
d3a0f8a6 -
Marco Trevisan authored
On properties changed we may endup emitting some signals multiple times, causing the same operations to be re-started multiple times, avoid this for the same properties changes, by recording the changed properties and emitting the same signal just once.
4a0d751d -
Marco Trevisan authored9a8b4489
-
Marco Trevisan authored39fe5686
-
Marco Trevisan authoredb6a2e855
-
Marco Trevisan authored0d72bcfd
-
Marco Trevisan authoredcbb4f887
-
Marco Trevisan authored77f2f451
-
Marco Trevisan authored
GNOME 3.36 series bugfix version 33.1
2ca0f1dd -
Marco Trevisan authoredc8f9eb40
-
Marco Trevisan authoredd70c7aa8