| 26 Apr 2023 |
 uep | surely not across process restarts | 04:55:01 |
 Jan Tojnar | yeah, definitely not | 04:55:36 |
| Jan Tojnar | it just runs the program and if it returns non-zero status code, the entry is ignored | 04:56:08 |
| Jan Tojnar | actually, that might be the issue | 04:56:41 |
| uep | the entry.. as in the list of thumbnailers.. sure | 04:56:43 |
| Jan Tojnar | running heif-thumbnailer without arguments appears to exit with 1 status | 04:57:30 |
| uep | oh no | 04:57:37 |
| Jan Tojnar | uep: try the following
libheif = pkgs.libheif.overrideAttrs (attrs: {
postInstall = attrs.postInstall or "" + ''
substituteInPlace "$out/share/thumbnailers/heif.thumbnailer" --replace "TryExec=heif-thumbnailer" "TryExec=true"
'';
})
| 04:59:21 |
| uep | libheif rebuilding which seems like a good start | 05:04:42 |
| uep | still no. the override worked but no difference in outcome | 05:06:28 |
| uep | hm | 05:17:23 |
| uep | it appears not to be using the file at all.. | 05:17:41 |
| uep | I changed it to "TryExec=${pkgs.coreutils}/bin/touch /tmp/heif-thumbs-up" | 05:18:02 |
| uep | no such file is made | 05:18:08 |
| uep | ❯ echo $XDG_DATA_DIRS | sed -e 's/:/\n/g' | grep current-system
/run/current-system/sw/share
| 05:19:48 |
| uep | so it should be found | 05:19:55 |
| uep | OH
| 05:31:32 |
| uep | fixed | 05:31:35 |
| uep | rm ~/.cache/thumbnails/fail/gnome-thumbnail-factory/* | 05:32:01 |
| Jan Tojnar | Yeah, that might be it, I was about to suggest playing with the API directly
env G_MESSAGES_DEBUG=all nix-shell -I nixpkgs=$HOME/Projects/nixpkgs -p glib gdk-pixbuf gnome-desktop gobject-introspection 'python3.withPackages(ps: with ps; [ pygobject3 ])' --run 'python3 -c "from gi.repository import GnomeDesktop; f = GnomeDesktop.DesktopThumbnailFactory.new(GnomeDesktop.DesktopThumbnailSize.NORMAL); print(f.generate_thumbnail(\"file:///home/jtojnar/samplefilehub2.heic\", \"image/heif\"))"'
and noticed that failures are cached mentioned there
| 05:33:25 |
| uep | although, weirdly, still no /tmp/heif-thumbs-up which means that bit isn't getting used, and explains how it's not failing for everyone on other platforms too | 05:34:09 |
| uep | so I suspect, in current nixpkgs, just having libheif.bin libheif.out in systemPackages, and SCROLLING FAR ENOUGH TO SEE NEW IMAGES, is enough to see it working | 05:39:42 |
| uep | but it seems worth fixing and enabling by default, given the pkg is already pulled in by eog | 05:40:24 |
| 27 Apr 2023 |
 @maralorn:maralorn.de | Anyone else experiencing weird artefacts around electron applications in gnome on unstable? | 13:12:47 |
 hexa | the element channel bar is glitchy for me on sway, if that counts as a datapoint | 14:31:30 |
 Fernando Rodrigues | In reply to @maralorn:maralorn.de
Anyone else experiencing weird artefacts around electron applications in gnome on unstable? Might be an upstream bug. Fedora Rawhide is also having issues with electron on GNOME. | 14:37:36 |
| Fernando Rodrigues | In reply to @maralorn:maralorn.de
Anyone else experiencing weird artefacts around electron applications in gnome on unstable? * Might be a bug for upstream. Fedora Rawhide is also having issues with electron on GNOME. | 14:37:46 |
| Fernando Rodrigues | * Might be a bug for upstream. Fedora Rawhide is also having issues with electron on GNOME. It might actually be an issue with mutter's XWayland implementation, not the apps themselves. | 14:49:49 |
| uep | FWIW, I haven't seen any such problem, using vscode and signal, and I have environment.sessionVariables.NIXOS_OZONE_WL = "1"; | 15:12:23 |
| uep | so if it actually is XWayland that could be bypassing it | 15:15:14 |
