Webp images outside the browser

minh thanks, it works!

UPDATE: I can now open .webp images using, e. g., Gnome Image Viewer -- but there are not previews in Nautilus. I am running the default Budgie version of Solus.

You can open the image " webp" with Gimp, and then use the Export as "function" to change the images to jpg or any format you want. it will make a copy of the file next to the webp image. after that it will show up in nautilus. https://www.widsmob.com/articles/gimp-webp.html

Silversurfer Well, it's just that @unclemez reported that it is possible to get .webp previews working, so I was wondering why it doesn't work with me, although I used the same lines in terminal.

Thats strange, i installed the webp package from the Solus pacage senter, and then used the terminal to update;
sudo /usr/bin/gdk-pixbuf-query-loaders --update-cache.
or this way ;You need to install it first sudo eopkg it webp-pixbuf-loader
then sudo /usr/bin/gdk-pixbuf-query-loaders --update-cache
had to restart the system, but now the images show up in nautilus

Silversurfer , well, this is what I entered in the terminal, literally:

user@pc ~ $ sudo eopkg it webp-pixbuf-loader
Password: 
The following package(s) are already installed and are not going to be installed again:
webp-pixbuf-loader
No packages to install.
user@pc ~ $ sudo /usr/bin/gdk-pixbuf-query-loaders --update-cache
user@pc ~ $ sudo reboot now

After reboot, I checked Nautilus settings:

But .webp images still do not show up as icons in the file manager:

Don't know what else to check.

@Staudey said this earlier

Staudey unclemez Nice. Also a small update: @joebonrichie actually updated our usysconf tool to now support updating the loaders.cache automatically with updates (currently in the Unstable repository, will be part of the next sync)

so i recommend you wait this weekend update which should bring a fix to that problem
it's already Thursday, so few more hours won't hurt i believe

I have just run sudo eopkg check for a different purpose and it signalled that a webp-relevant package is broken:

Checking integrity of gdk-pixbuf                                     Broken
Corrupted file: /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders.cache

I've tried sudo eopkg rm gdk-pixbug but it says there is no such file. How can this be handled?

noise617
That's because the package name is gdk-pixbuf, not pixbug

Anyway, two important things to note about this:

1. As this is a cache file, which can be edited by our new gdk-pixbuf usysconf trigger (e.g. when you install the webp loader) it's not unusual for eopkg check to report it as "Broken", which simply means that it's not in the state it was in during the package installation. I do wonder however whether we should handle this a bit better now.
2. For the future: Standard procedure after you encounter a genuinely broken package shouldn't be to remove it, but instead to re-install it (using sudo eopkg it --reinstall <package-name>). Otherwise you might remove something vital to the system.

Ah the broken gdk-pixbuf package is due to the pre-compiled loaders.cache file getting overridden by the new usysconf trigger for gdk-pixbuf. I'll remove the pre-compiled loaders.cache file and let usysconf handle it exclusively. It is nothing to worry about in the mean while.

I've tried sudo eopkg check | grep Broken | awk '{print $4}' | xargs sudo eopkg it --reinstall and it succesfully re-installed three packages:

dropbox  gdk-pixbuf  noto-sans-ttf

However, sudo eopkg check still indicates:

Checking integrity of gdk-pixbuf                                     Broken
Corrupted file: /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders.cache

noise617 see the post directly above yours

brent, I don't understand how to handle this exactly.

joebonrichie, how did you handle the loaders.cache problem in the end?

noise617 You can safely ignore this issue for now. Will disappear with the next update. As Joey and I explained above that's just a consequence of the automatic way in which we handle the gdk-pixbuf loader cache now. Starting with the next update, the loaders.cache will be completely dynamically generated on the user system and therefore no longer tracked (and complained about) by eopkg check.

Staudey, got it, thanks for letting me know.