Closed fiftydinar closed 1 month ago
I use that, not sure it works build-time? Have to test. Seems it installs into ~/.local/share/
, might have a way to override.
I use that, not sure it works build-time? Have to test.
I think that it has some --system
flag or something.
But I don't see it in code how it installs languages or schema with --filesystem
method, since --dbus
method wouldn't work in build-time.
It seems that it just extracts the zip to /usr/share/gnome-shell/extensions
or /usr/local/share/gnome-shell/extensions
& that's it.
It doesn't seem to compile gschema afterwards either.
I am more interested in this tbh
" Potential improvement would be automatic installation of latest Gnome extension for supported Gnome version."
It seems that this part of code is responsible for fetching data from https://extensions.gnome.org
https://github.com/essembeh/gnome-extensions-cli/blob/main/gnome_extensions_cli/store.py
It seems that this part of code is responsible for fetching data from extensions.gnome.org
Seems to do get queries like: https://extensions.gnome.org/extension-query/?search=a&shell_version=40
or https://extensions.gnome.org/extension-query/?pk=55&shell_version=40
(paste into browser). I can't figure out if the pk
param does anything.
@xynydev I think that this makes it even possible to just include extension names in extension list, since extension names are unique (see OpenWeather vs OpenWeather Refined)
So recipe can look like this:
type: gnome-extensions
install:
- Blur my Shell
- Night Theme Switcher
However, I have to think about how version override would look (latest suitable extension version would be installed by default).
I think we should at least work to dynamically support that and what we have currently. Also supporting using extension IDs would be preferrred IMO since names can be not specific/unique enough or changing, while IDs are unique and unchanging. It's also better than the current method as it'd always get the latest version.
I think we should at least work to dynamically support that and what we have currently. Also supporting using extension IDs would be preferrred IMO since names can be not specific/unique enough or changing, while IDs are unique and unchanging. It's also better than the current method as it'd always get the latest version.
I added support for installing through extension names & It works nicely.
But I have a problem with installing extensions in PK (ID):
Blur my Shell extension.gnome.org homepage: https://extensions.gnome.org/extension/3193/blur-my-shell/
Blur my Shell with name is available: https://extensions.gnome.org/extension-query/?search=Blur%20my%20Shell&shell_version=46
Blur my Shell with PK (ID) is not available, even when specified (no matter if shell_version is ommited or not): https://extensions.gnome.org/extension-query/?pk=3193&shell_version=46
Searching extensions through name is more intuitive & consistent, while searching through PK (ID) will not always give desired results.
Work on this can be followed here: https://github.com/fiftydinar/gidro-os/pull/25
I don't see how to get this fixed tbh. I would just refer image-maintainers to use names & drop work on adding support for PKs (IDs).
About what happens when extension changes it's name, in my current work, module would complain & fail the build with the message:
ERROR: Extension 'Some unknown extension' does not exist in https://extensions.gnome.org/ website
Extension name is case-sensitive, so be sure that you typed it correctly,
including the correct uppercase & lowercase characters
Similarly, module would fail if the existing extension would not be compatible with Gnome version of the image with the message:
ERROR: Extension 'Some unknown extension' is not compatible with Gnome v46 in your image"
I implemented legacy support for installing extensions, which retains compatibility with existing configs. I warn the users in the logs that they should switch to new install method.
Users can use legacy method of installing extension if they want to enforce specific version of extension.
The only thing that remains to be implemented in this rewrite is support for uninstalling & docs (the hardest part :P) And maybe code can be reused between legacy & new method of installation somehow.
I made the PR here with documented improvements below: https://github.com/blue-build/modules/pull/238
This might make it better to install Gnome extensions in build-time. Potential improvement would be automatic installation of latest Gnome extension for supported Gnome version.
https://github.com/essembeh/gnome-extensions-cli