bug#52044: Various Program Settings not Saving and Icons not Recognized

bug#52044: Various Program Settings not Saving and Icons not Recognized

[Jaft via Bug reports for GNU Guix]

[-- Attachment #1.1: Type: text/plain, Size: 4211 bytes --]

I'm not sure if it's stemming from a bug or I've just missed a package or service I should've included but I find there're several programs I have installed which aren't saving their settings.
Catfish and thunar are two easy examples while gnome-calendar, arandr, and viewnior do save their preferences, when modified, just fine. In a sort of weird middle-ground, lxappearance will save, say, an icon change (I can check .config/gtk-3.0/settings.ini and see that the icons have been updated) but, upon opening it, again, I find that it says the previous icon set is what's been chosen (this doesn't affect the settings.ini file, though; I would need to actually reselect the old icon set and hit Apply for that to get updated, once more).


In a sort of similar vein, icons can't seem to be recognized for particular programs; thunar and gnome-screenshot are easy examples and I've attached an image indicating what I mean. Catfish is fine but I think it's falling back to the HighContrast iconset (interestingly, the only iconset that seems to work when I set it in lxappearance). rofi, even, isn't able to provide any application icons when using drun mode. lxappearance and nitrogren are two I've noticed using the icons I set (Papirus-Light, mostly).
I thought it might be an issue with how XDG_DATA_DIRS may be set but it's set to both /run/current-system/profile and my .guix-profile's share directories; my .guix-profile/share/icons only has hicolor in is but /run/current-system/profile/share/icons has all the expected icons in it, including hicolor. At least, it certainly is when I open a terminal but even launching, say, thunar from the terminal still has the exact same behavior.



I'll put the services and packages of my system config below but let me know if there's anything else I could provide which would also be helpful.
(packages
  (append
    (list (specification->package "openbox")
          (specification->package "nss-certs")
          ;;; algebra
          bc
          ;;; dunst
          dunst
          ;;; compton
          compton
          ;;; admin
          inxi-minimal
          htop
          ;;; lxde
          ;; lxterminal
          lxappearance
          ;;; xfce
          catfish
          tumbler
          thunar
          thunar-volman
          xfce4-power-manager
          ;;; xdisorg
          arandr
          tint2
          rofi
          clipmenu
          ;;; calendar
          gsimplecal
          ;;; version-control
          (list git                  "out")
          (list git "credential-libsecret")
          ;;; gnome
          gnome-keyring
          seahorse
          gvfs
          file-roller
          gnome-calculator
          gnome-font-viewer  ;; gsettings-desktop-schemas
          gnome-screenshot
          gnome-themes-standard
          ;;; gnome-xyz
          papirus-icon-theme
          ;;; fonts
          font-abattis-cantarell
          font-fira-code
          ;;; ncdu
          ncdu
          ;;; pulseaudio
          pulsemixer
          ;;; wm
          i3lock
          i3lock-fancy
          nitrogen
          ;;; linux
          ;; ntfs-3g
          ;; fuse-exfat
          ;;; file-systems
          ;; exfat-utils
          ;;; image-viewers
          viewnior)
    %base-packages))
(services (cons*
            (service slim-service-type (slim-configuration
                         (display  ":0")
                         (vt      "vt7")))
            (modify-services %desktop-services (delete gdm-service-type))))

[-- Attachment #1.2: Type: text/html, Size: 9689 bytes --]

[-- Attachment #2: Screenshot from 2021-11-22 13-34-59.png --]
[-- Type: image/png, Size: 147339 bytes --]

bug#52044: Various Program Settings not Saving and Icons not Recognized

[Liliana Marie Prikler]

Hi Jaft,

> I'm not sure if it's stemming from a bug or I've just missed a package
> or service I should've included but I find there're several programs I
> have installed which aren't saving their settings.
> Catfish and thunar are two easy examples while gnome-calendar, arandr,
> and viewnior do save their preferences, when modified, just fine. In a
> sort of weird middle-ground, lxappearance will save, say, an icon
> change (I can check .config/gtk-3.0/settings.ini and see that the icons
> have been updated) but, upon opening it, again, I find that it says the
> previous icon set is what's been chosen (this doesn't affect the
> settings.ini file, though; I would need to actually reselect the old
> icon set and hit Apply for that to get updated, once more).
Many GNOME-adjacent/GTK-based applications use GSettings to store their
configuration and are backed by a dconf store.  You can use dconf-editor
to inspect/change their values manually.
Communication between your application and the dconf store is provided
by the dconf-service, which itself uses DBus.  My guess is that either
dbus is not started at all or the dconf-service is not running.

> In a sort of similar vein, icons can't seem to be recognized for
> particular programs; thunar and gnome-screenshot are easy examples and
> I've attached an image indicating what I mean. Catfish is fine but I
> think it's falling back to the HighContrast iconset (interestingly, the
> only iconset that seems to work when I set it in lxappearance). rofi,
> even, isn't able to provide any application icons when using drun mode.
> lxappearance and nitrogren are two I've noticed using the icons I set
> (Papirus-Light, mostly).
Most GTK-based applications again use the GTK icon theme set by your
window manager (usually) using GSettings/dconf.  Most applications also
typically fall back to hicolor-icon-theme, but that appears to be
lacking from your system definition.  Note that it's *not* included in
gnome-themes-standard.

You appear to be using quite anemic versions of the GNOME/XFCE desktop
environments overall.  While yes, it is a bug that those applications
typically fail to deliver icons outside of their respective
environments, it is a fact we have to deal with.  An alternative
"solution" to this problem would require us to propagate stuff like
hicolor-icon-theme from each and every one of them, resulting in
conflicts if you want to bump just a single package.

I tested around a little and with the following I can at least see
the icons of nautilus and gnome-settings-daemon, even when using
e.g. ratpoison as my window manager
--8<---------------cut here---------------start------------->8---
(define anemic-gnome
  (package
   (inherit gnome)
   (propagated-inputs
    `(;; GNOME-Core-Shell
      ("adwaita-icon-theme" ,adwaita-icon-theme)
      ("gnome-keyring" ,gnome-keyring)
      ("gnome-session" ,gnome-session)
      ("gnome-control-center" ,gnome-control-center)
      ("gnome-settings-daemon" ,gnome-settings-daemon)
      ("gnome-system-monitor" ,gnome-system-monitor)
      ("gnome-shell" ,gnome-shell)
      ("gvfs" ,gvfs)
      ("mutter" ,mutter)
      ("gnome-calculator" ,gnome-calculator)
      ("gnome-font-viewer" ,gnome-font-viewer)
      ("gnome-screenshot" ,gnome-screenshot)
      ("gnome-terminal" ,gnome-terminal)
      ("nautilus" ,nautilus)
      ;; Others
      ("hicolor-icon-theme" ,hicolor-icon-theme)
      ("font-abattis-cantarell" ,font-abattis-cantarell)
      ("gnome-themes-standard" ,gnome-themes-standard)))))
--8<---------------cut here---------------end--------------->8---
using the following values of services while either leaving packages
as %base-packages or simply consing some other window manager to it.
--8<---------------cut here---------------start------------->8---
 (services
   (cons*
    (service gnome-desktop-service-type
             (gnome-desktop-configuration (gnome anemic-gnome)))
    (service slim-service-type
             (slim-configuration (display ":0") (vt "vt7")
                                 (xorg-configuration
                                  (xorg-configuration
                                   (keyboard-layout keyboard-layout)))))
    (modify-services %desktop-services
                     (delete gdm-service-type))))
--8<---------------cut here---------------end--------------->8---

The same can surely be done for xfce-desktop-service as well.  You are
free to cut even more inputs, but be warned that at some point
gnome-desktop-service starts raising errors when you try to build your
system.  It shouldn't do that when merely missing icons, though.

Cheers

bug#52044: Various Program Settings not Saving and Icons not Recognized

[Jaft via Bug reports for GNU Guix]

[-- Attachment #1.1: Type: text/plain, Size: 12140 bytes --]

 Thanks so much, Liliana, for the response; this really helpful and enlightening in terms of understanding Guix better (I think I tend to learn more intuitively from examples than anything).

> On Friday, November 26, 2021, 04:45:19 PM UTC, Liliana Marie Prikler <liliana.prikler@gmail.com> wrote: >
 >
 > Hi Jaft,
>
> > I'm not sure if it's stemming from a bug or I've just missed a package
> > or service I should've included but I find there're several programs I
> > have installed which aren't saving their settings.
> > Catfish and thunar are two easy examples while gnome-calendar, arandr,
> > and viewnior do save their preferences, when modified, just fine. In a
> > sort of weird middle-ground, lxappearance will save, say, an icon
> > change (I can check .config/gtk-3.0/settings.ini and see that the icons
> > have been updated) but, upon opening it, again, I find that it says the
> > previous icon set is what's been chosen (this doesn't affect the
> > settings.ini file, though; I would need to actually reselect the old
> > icon set and hit Apply for that to get updated, once more).
> Many GNOME-adjacent/GTK-based applications use GSettings to store their
> configuration and are backed by a dconf store.  You can use dconf-editor
> to inspect/change their values manually.
> Communication between your application and the dconf store is provided
> by the dconf-service, which itself uses DBus.  My guess is that either
> dbus is not started at all or the dconf-service is not running.

That makes sense; I definitely did not have anything dconf-related running. In case anyone else does stumble upon this E-mail thread and is curious, you can also circumvent running dconf (that was never a goal, for me; I just stumbled upon it) with xfconf; running my original setup with that installed actually caused settings to be saved perfectly.

> > In a sort of similar vein, icons can't seem to be recognized for
> > particular programs; thunar and gnome-screenshot are easy examples and
> > I've attached an image indicating what I mean. Catfish is fine but I
> > think it's falling back to the HighContrast iconset (interestingly, the
> > only iconset that seems to work when I set it in lxappearance). rofi,
> > even, isn't able to provide any application icons when using drun mode.
> > lxappearance and nitrogren are two I've noticed using the icons I set
> > (Papirus-Light, mostly).
> Most GTK-based applications again use the GTK icon theme set by your
> window manager (usually) using GSettings/dconf.  Most applications also
> typically fall back to hicolor-icon-theme, but that appears to be
> lacking from your system definition.  Note that it's *not* included in
> gnome-themes-standard.
This is where I'm still running into issues; I don't know if xfconf has any effect here (I haven't tested how things go without it installed) but I tried the Gnome setup that you demonstrated and, likewise, I was able to update and change (via gnome-tweaks) the icons. Out of curiosity, I tried XFCE as well (just the full setup) by adding to my services: (service xfce-desktop-service-type (xfce-desktop-configuration (xfce xfce))).

I also installed the hicolor and Adwaita icons as I read that Thunar (or maybe GTK app.s in general?) don't work at all if those aren't present (and, with mere light observance, that does seem to be true); logging into the XFCE desktop, it didn't seem like icons were working as the folders were all clearly Adwaita but, at some point, I realized that some of the icons were changing (namely, the files): it just wasn't changing all of them.

I took a look at my original setup, as well, and found the same result. I've attached some pictures of icon selection from within the XFCE desktop and it shows that the folders for a whole host of themes keep trying to use the Adwaita folders; not all of them but most.
(If I understood correctly,) you were saying that a similar setup to the Gnome example you gave could work with XFCE but running the full, plain XFCE (assuming I did that right) still resulted in this weird thing with the icons so I'm assuming there's something larger here, going on? It definitely works right, on Gnome, and I'm able to see all icons of the picked icon theme get loaded correctly but it seems, to me, that's not the case with XFCE.



Tangential but, bug-wise, unrelated: I mentioned rofi not showing application icons. Looking at the errors it produces, when run, I'm getting stuff like:
(process:30101): Helpers.IconFetcher-WARNING **: 06:23:32.467: Failed to load image: Couldn’t recognize the image file format for file “/run/current-system/profile/share/icons/Papirus-Light/96x96/apps/org.xfce.catfish.svg”

I tried searching for if anyone had run into a similar problem and found gdk-pixbuf2 2.32.1-1 with librsvg 2.40.10-1: "Couldn't recognize the image file format for file" error for SVG files · Issue #818 · msys2/MINGW-packages and [BUG] SVG rendering failed on rofi version 1.6.1 · Discussion #1235 · davatorium/rofi but the first didn't seem particularly related (beyond referencing the library, I think, rofi uses and, even then, Guix is on a later version, by now) and, in the second link, someone refers to Guix to reference how things should be setup so that didn't really bring much enlightenment, either.
I tried running rofi with G_MESSAGES_DEBUG=Helpers.IconFetcher, to get debugging messages and got:
Helpers.IconFetcher-INFO: 06:38:06.245: Add image extension: ani
Helpers.IconFetcher-INFO: 06:38:06.245: Add image extension: bmp
Helpers.IconFetcher-INFO: 06:38:06.245: Add image extension: gif
Helpers.IconFetcher-INFO: 06:38:06.245: Add image extension: icns
Helpers.IconFetcher-INFO: 06:38:06.245: Add image extension: ico
Helpers.IconFetcher-INFO: 06:38:06.245: Add image extension: cur
Helpers.IconFetcher-INFO: 06:38:06.245: Add image extension: jpeg
Helpers.IconFetcher-INFO: 06:38:06.245: Add image extension: jpe
Helpers.IconFetcher-INFO: 06:38:06.245: Add image extension: jpg
Helpers.IconFetcher-INFO: 06:38:06.245: Add image extension: png
Helpers.IconFetcher-INFO: 06:38:06.245: Add image extension: pnm
Helpers.IconFetcher-INFO: 06:38:06.245: Add image extension: pbm
Helpers.IconFetcher-INFO: 06:38:06.245: Add image extension: pgm
Helpers.IconFetcher-INFO: 06:38:06.245: Add image extension: ppm
Helpers.IconFetcher-INFO: 06:38:06.245: Add image extension: qtif
Helpers.IconFetcher-INFO: 06:38:06.245: Add image extension: qif
Helpers.IconFetcher-INFO: 06:38:06.245: Add image extension: tga
Helpers.IconFetcher-INFO: 06:38:06.245: Add image extension: targa
Helpers.IconFetcher-INFO: 06:38:06.245: Add image extension: tiff
Helpers.IconFetcher-INFO: 06:38:06.245: Add image extension: tif
Helpers.IconFetcher-INFO: 06:38:06.245: Add image extension: xbm
Helpers.IconFetcher-INFO: 06:38:06.245: Add image extension: xpm
(process:7244): Helpers.IconFetcher-DEBUG: 06:38:06.268: Query: preferences-desktop-theme(80)
(process:7244): Helpers.IconFetcher-DEBUG: 06:38:06.269: starting up icon fetching thread.
(process:7244): Helpers.IconFetcher-DEBUG: 06:38:06.270: Query: org.xfce.catfish(80)
(process:7244): Helpers.IconFetcher-DEBUG: 06:38:06.270: starting up icon fetching thread.
(process:7244): Helpers.IconFetcher-DEBUG: 06:38:06.271: Query: icecat(80)
(process:7244): Helpers.IconFetcher-DEBUG: 06:38:06.271: starting up icon fetching thread.
(process:7244): Helpers.IconFetcher-DEBUG: 06:38:06.271: Query: (80)
(process:7244): Helpers.IconFetcher-DEBUG: 06:38:06.271: Query: org.xfce.powermanager(80)
(process:7244): Helpers.IconFetcher-DEBUG: 06:38:06.272: Query: chromium(80)
(process:7244): Helpers.IconFetcher-DEBUG: 06:38:06.272: starting up icon fetching thread.
(process:7244): Helpers.IconFetcher-DEBUG: 06:38:06.272: found icon preferences-desktop-theme(80x80): /run/current-system/profile/share/icons/Papirus-Light/96x96/apps/preferences-desktop-theme.svg

(process:7244): Helpers.IconFetcher-WARNING **: 06:38:06.272: Failed to load image: Couldn’t recognize the image file format for file “/run/current-system/profile/share/icons/Papirus-Light/96x96/apps/preferences-desktop-theme.svg”
(process:7244): Helpers.IconFetcher-DEBUG: 06:38:06.272: starting up icon fetching thread.
(process:7244): Helpers.IconFetcher-DEBUG: 06:38:06.275: found icon org.xfce.catfish(80x80): /run/current-system/profile/share/icons/Papirus-Light/96x96/apps/org.xfce.catfish.svg

SVGs don't seem to be loaded as an extension, though librsvg is a dependency of rofi (I assume it's related to SVG handling for when rofi is running).


| 
| 
| 
|  |  |

 |

 |
| 
|  | 
[BUG] SVG rendering failed on rofi version 1.6.1 · Discussion #1235 · da...

SVG rendering failed on rofi version 1.6.1. Fallback the version to 1.5.4 and rendering works normally. Version ...
 |

 |

 |



| 
| 
| 
|  |  |

 |

 |
| 
|  | 
gdk-pixbuf2 2.32.1-1 with librsvg 2.40.10-1: "Couldn't recognize the im...

When MyPaint tries to load an icon for its initial runtime test, I get: ERROR: gui.application: Missing icon 'my...
 |

 |

 |




>
> You appear to be using quite anemic versions of the GNOME/XFCE desktop
> environments overall.  While yes, it is a bug that those applications
> typically fail to deliver icons outside of their respective
> environments, it is a fact we have to deal with.  An alternative
> "solution" to this problem would require us to propagate stuff like
> hicolor-icon-theme from each and every one of them, resulting in
> conflicts if you want to bump just a single package.
>
> I tested around a little and with the following I can at least see
> the icons of nautilus and gnome-settings-daemon, even when using
> e.g. ratpoison as my window manager
> --8<---------------cut here---------------start------------->8---
> (define anemic-gnome
>   (package
>   (inherit gnome)
>   (propagated-inputs
>     `(;; GNOME-Core-Shell
>       ("adwaita-icon-theme" ,adwaita-icon-theme)
>       ("gnome-keyring" ,gnome-keyring)
>       ("gnome-session" ,gnome-session)
>       ("gnome-control-center" ,gnome-control-center)
>       ("gnome-settings-daemon" ,gnome-settings-daemon)
>       ("gnome-system-monitor" ,gnome-system-monitor)
>       ("gnome-shell" ,gnome-shell)
>       ("gvfs" ,gvfs)
>       ("mutter" ,mutter)
>       ("gnome-calculator" ,gnome-calculator)
>       ("gnome-font-viewer" ,gnome-font-viewer)
>       ("gnome-screenshot" ,gnome-screenshot)
>       ("gnome-terminal" ,gnome-terminal)
>       ("nautilus" ,nautilus)
>       ;; Others
>       ("hicolor-icon-theme" ,hicolor-icon-theme)
>       ("font-abattis-cantarell" ,font-abattis-cantarell)
>       ("gnome-themes-standard" ,gnome-themes-standard)))))
> --8<---------------cut here---------------end--------------->8---
> using the following values of services while either leaving packages
> as %base-packages or simply consing some other window manager to it.
> --8<---------------cut here---------------start------------->8---
 > (services
>   (cons*
>     (service gnome-desktop-service-type
>             (gnome-desktop-configuration (gnome anemic-gnome)))
>     (service slim-service-type
>             (slim-configuration (display ":0") (vt "vt7")
>                                 (xorg-configuration
>                                   (xorg-configuration
>                                   (keyboard-layout keyboard-layout)))))>
>     (modify-services %desktop-services
>                     (delete gdm-service-type))))>
> --8<---------------cut here---------------end--------------->8---
>
> The same can surely be done for xfce-desktop-service as well.  You are
> free to cut even more inputs, but be warned that at some point
> gnome-desktop-service starts raising errors when you try to build your
> system.  It shouldn't do that when merely missing icons, though.
>
> Cheers  

[-- Attachment #1.2: Type: text/html, Size: 27284 bytes --]

[-- Attachment #2: Screenshot from 2021-11-28 01-56-36.png --]
[-- Type: image/png, Size: 75254 bytes --]

[-- Attachment #3: Screenshot from 2021-11-28 01-57-20.png --]
[-- Type: image/png, Size: 77353 bytes --]

bug#52044: Various Program Settings not Saving and Icons not Recognized

[Liliana Marie Prikler]

Hi,

Am Sonntag, den 28.11.2021, 12:52 +0000 schrieb Jaft:
> [...]
> 
> (If I understood correctly,) you were saying that a similar setup to
> the Gnome example you gave could work with XFCE but running the full,
> plain XFCE (assuming I did that right) still resulted in this weird
> thing with the icons so I'm assuming there's something larger here,
> going on? It definitely works right, on Gnome, and I'm able to see
> all icons of the picked icon theme get loaded correctly but it seems,
> to me, that's not the case with XFCE.
So, what you're saying is that running the full XFCE stack with the
plain xfce from guix is currently broken?  I think that deserves to be
called a bug, but it'd also have a fairly simple patch of adding
adwaita-icon-theme, no?

> Tangential but, bug-wise, unrelated: I mentioned rofi not showing
> application icons. Looking at the errors it produces, when run, I'm
> getting stuff like:
> 
> (process:30101): Helpers.IconFetcher-WARNING **: 06:23:32.467: Failed
> to load image: Couldn’t recognize the image file format for file
> “/run/current-system/profile/share/icons/Papirus-
> Light/96x96/apps/org.xfce.catfish.svg”
> 
> I tried searching for if anyone had run into a similar problem and
> found gdk-pixbuf2 2.32.1-1 with librsvg 2.40.10-1: "Couldn't
> recognize the image file format for file" error for SVG files · Issue
> #818 · msys2/MINGW-packages and [BUG] SVG rendering failed on rofi
> version 1.6.1 · Discussion #1235 · davatorium/rofi but the first
> didn't seem particularly related (beyond referencing the library, I
> think, rofi uses and, even then, Guix is on a later version, by now)
> and, in the second link, someone refers to Guix to reference how
> things should be setup so that didn't really bring much
> enlightenment, either.
> 
> I tried running rofi with G_MESSAGES_DEBUG=Helpers.IconFetcher, to
> get debugging messages and got:
> 
> Helpers.IconFetcher-INFO: 06:38:06.245: Add image extension: ani
> Helpers.IconFetcher-INFO: 06:38:06.245: Add image extension: bmp
> Helpers.IconFetcher-INFO: 06:38:06.245: Add image extension: gif
> Helpers.IconFetcher-INFO: 06:38:06.245: Add image extension: icns
> Helpers.IconFetcher-INFO: 06:38:06.245: Add image extension: ico
> Helpers.IconFetcher-INFO: 06:38:06.245: Add image extension: cur
> Helpers.IconFetcher-INFO: 06:38:06.245: Add image extension: jpeg
> Helpers.IconFetcher-INFO: 06:38:06.245: Add image extension: jpe
> Helpers.IconFetcher-INFO: 06:38:06.245: Add image extension: jpg
> Helpers.IconFetcher-INFO: 06:38:06.245: Add image extension: png
> Helpers.IconFetcher-INFO: 06:38:06.245: Add image extension: pnm
> Helpers.IconFetcher-INFO: 06:38:06.245: Add image extension: pbm
> Helpers.IconFetcher-INFO: 06:38:06.245: Add image extension: pgm
> Helpers.IconFetcher-INFO: 06:38:06.245: Add image extension: ppm
> Helpers.IconFetcher-INFO: 06:38:06.245: Add image extension: qtif
> Helpers.IconFetcher-INFO: 06:38:06.245: Add image extension: qif
> Helpers.IconFetcher-INFO: 06:38:06.245: Add image extension: tga
> Helpers.IconFetcher-INFO: 06:38:06.245: Add image extension: targa
> Helpers.IconFetcher-INFO: 06:38:06.245: Add image extension: tiff
> Helpers.IconFetcher-INFO: 06:38:06.245: Add image extension: tif
> Helpers.IconFetcher-INFO: 06:38:06.245: Add image extension: xbm
> Helpers.IconFetcher-INFO: 06:38:06.245: Add image extension: xpm
> (process:7244): Helpers.IconFetcher-DEBUG: 06:38:06.268: Query:
> preferences-desktop-theme(80)
> (process:7244): Helpers.IconFetcher-DEBUG: 06:38:06.269: starting up
> icon fetching thread.
> (process:7244): Helpers.IconFetcher-DEBUG: 06:38:06.270: Query:
> org.xfce.catfish(80)
> (process:7244): Helpers.IconFetcher-DEBUG: 06:38:06.270: starting up
> icon fetching thread.
> (process:7244): Helpers.IconFetcher-DEBUG: 06:38:06.271: Query:
> icecat(80)
> (process:7244): Helpers.IconFetcher-DEBUG: 06:38:06.271: starting up
> icon fetching thread.
> (process:7244): Helpers.IconFetcher-DEBUG: 06:38:06.271: Query: (80)
> (process:7244): Helpers.IconFetcher-DEBUG: 06:38:06.271: Query:
> org.xfce.powermanager(80)
> (process:7244): Helpers.IconFetcher-DEBUG: 06:38:06.272: Query:
> chromium(80)
> (process:7244): Helpers.IconFetcher-DEBUG: 06:38:06.272: starting up
> icon fetching thread.
> (process:7244): Helpers.IconFetcher-DEBUG: 06:38:06.272: found icon
> preferences-desktop-theme(80x80): /run/current-
> system/profile/share/icons/Papirus-Light/96x96/apps/preferences-
> desktop-theme.svg
> 
> (process:7244): Helpers.IconFetcher-WARNING **: 06:38:06.272: Failed
> to load image: Couldn’t recognize the image file format for file
> “/run/current-system/profile/share/icons/Papirus-
> Light/96x96/apps/preferences-desktop-theme.svg”
> (process:7244): Helpers.IconFetcher-DEBUG: 06:38:06.272: starting up
> icon fetching thread.
> (process:7244): Helpers.IconFetcher-DEBUG: 06:38:06.275: found icon
> org.xfce.catfish(80x80): /run/current-
> system/profile/share/icons/Papirus-
> Light/96x96/apps/org.xfce.catfish.svg
> 
> SVGs don't seem to be loaded as an extension, though librsvg is a
> dependency of rofi (I assume it's related to SVG handling for when
> rofi is running).
> 
> 	
> [BUG] SVG rendering failed on rofi version 1.6.1 · Discussion #1235 ·
> da...
> SVG rendering failed on rofi version 1.6.1. Fallback the version to
> 1.5.4 and rendering works normally. Version ...
> 
> 	
> gdk-pixbuf2 2.32.1-1 with librsvg 2.40.10-1: "Couldn't recognize the
> im...
> When MyPaint tries to load an icon for its initial runtime test, I
> get: ERROR: gui.application: Missing icon 'my...
SVG handling is in a somewhat rough spot currently.  There's some GNOME
packages on current master, that have broken icons due to gdk-
pixbuf+svg being severely out of date.  These are for the most part
known (at least the core GNOME ones like evince) and will probably
vanish with the c-u-f merge.  Consequently, I don't think it makes
sense to report broken icons due to this reason on master; one would
have to look into the c-u-f situation. 

Note that SVG is anyway broken for those not on x86_64, because that's
the only platform that has Rust.  Maybe there's an effort to derustify
SVG handling in Gdk similar to how there's an open merge request to use
duktape in polkit.  If not, I did suggest elsewhere to pre-render SVGs
with other tools like inkscape.

Cheers

bug#52044: Various Program Settings not Saving and Icons not Recognized

[Jaft via Bug reports for GNU Guix]

[-- Attachment #1: Type: text/plain, Size: 2384 bytes --]

> So, what you're saying is that running the full XFCE stack with the
> plain xfce from guix is currently broken?  I think that deserves to be
> called a bug, but it'd also have a fairly simple patch of adding
> adwaita-icon-theme, no?
It does (to my untrained eyes) seem broken but not for the reason I think you're suggesting.
Patching to add adwaita-icon-theme would be the same as me installing it manually, right (just making sure my understanding's correct)? I tried installing Adwaita icons when testing things out so I don't think that's the issue.
The issue seems to be that icons such as Papirus and Delft aren't using their own folders; instead, they seem to be using Adwaita's (maybe via the gnome-icon-theme package?). I think the images I'd attached better demonstrate the situation than I can, with words; some of the icons in the icon selection window show the right icons for the theme while other ones (namely the folders) default to the ones in the Adwaita icon theme.
It seems, to me, like possibly an issue with the icon themes, themselves? I'm not sure why it would but it's not an issue with the Adwaita icons, themselves; they load fine. It's the other icons which aren't using their full range of icons and are, instead, defaulting to another icon theme for some of their icons.
I…couldn't say why (unfortunately…) but it seems more to do with the other icon themes and less with the Adwaita icons, themselves.


> SVG handling is in a somewhat rough spot currently.  There's some GNOME
> packages on current master, that have broken icons due to gdk-
> pixbuf+svg being severely out of date.  These are for the most part
> known (at least the core GNOME ones like evince) and will probably
> vanish with the c-u-f merge.  Consequently, I don't think it makes
> sense to report broken icons due to this reason on master; one would
> have to look into the c-u-f situation. 

> Note that SVG is anyway broken for those not on x86_64, because that's
> the only platform that has Rust.  Maybe there's an effort to derustify
> SVG handling in Gdk similar to how there's an open merge request to use
> duktape in polkit.  If not, I did suggest elsewhere to pre-render SVGs
> with other tools like inkscape.
Ahh, gotcha. I hadn't been aware; that makes sense, then. I think we can safely ignore this one for now.


> Cheers

  

[-- Attachment #2: Type: text/html, Size: 4254 bytes --]

bug#52044: Various Program Settings not Saving and Icons not Recognized

[Liliana Marie Prikler]

Hi,

Am Montag, den 29.11.2021, 04:01 +0000 schrieb Jaft:
> The issue seems to be that icons such as Papirus and Delft aren't
> using their own folders; instead, they seem to be using Adwaita's
> (maybe via the gnome-icon-theme package?). I think the images I'd
> attached better demonstrate the situation than I can, with words;
> some of the icons in the icon selection window show the right icons
> for the theme while other ones (namely the folders) default to the
> ones in the Adwaita icon theme.
> 
> It seems, to me, like possibly an issue with the icon themes,
> themselves? I'm not sure why it would but it's not an issue with the
> Adwaita icons, themselves; they load fine. It's the other icons which
> aren't using their full range of icons and are, instead, defaulting
> to another icon theme for some of their icons.
> 
> I…couldn't say why (unfortunately…) but it seems more to do with the
> other icon themes and less with the Adwaita icons, themselves.
Themes can inherit from another, i.e. default to another theme's icons
when some icon is not provided.  This might be a GNOME vs. XFCE thing,
but Delft's coloured folder icons work fine on the former.  You might
want to check upstream whether they do in fact support XFCE.  It could
however also be related to the SVG situation; if those folders only
exist as SVGs and they're not supported, chances are that a fallback
will occur as well.

Cheers

bug#52044: Various Program Settings not Saving and Icons not Recognized

[Jaft via Bug reports for GNU Guix]

[-- Attachment #1: Type: text/plain, Size: 2711 bytes --]

 Hey!

   > On Monday, November 29, 2021, 05:20:12 AM UTC, Liliana Marie Prikler <liliana.prikler@gmail.com> wrote:  >
 >
 > Hi,
>
> Am Montag, den 29.11.2021, 04:01 +0000 schrieb Jaft:
> > The issue seems to be that icons such as Papirus and Delft aren't
> > using their own folders; instead, they seem to be using Adwaita's
> > (maybe via the gnome-icon-theme package?). I think the images I'd
> > attached better demonstrate the situation than I can, with words;
> > some of the icons in the icon selection window show the right icons
> > for the theme while other ones (namely the folders) default to the
> > ones in the Adwaita icon theme.
> > 
> > It seems, to me, like possibly an issue with the icon themes,
> > themselves? I'm not sure why it would but it's not an issue with the
> > Adwaita icons, themselves; they load fine. It's the other icons which
> > aren't using their full range of icons and are, instead, defaulting
> > to another icon theme for some of their icons.
> > 
> > I…couldn't say why (unfortunately…) but it seems more to do with the
> > other icon themes and less with the Adwaita icons, themselves.
> Themes can inherit from another, i.e. default to another theme's icons
> when some icon is not provided.  This might be a GNOME vs. XFCE thing,
> but Delft's coloured folder icons work fine on the former.  You might
> want to check upstream whether they do in fact support XFCE.  It could
> however also be related to the SVG situation; if those folders only
> exist as SVGs and they're not supported, chances are that a fallback
> will occur as well.>
>
> Cheers

So, as soon as you mentioned this, I realized that made so much sense that I don't know why I hadn't realized it before now.
I only did a brief check but the Adwaita theme definitely uses more .pngs than .svgs and it seems reasonable, to me, that could be the cause.


I had noticed that the core-updates-frozen branch had been merged so I upgraded but found things pretty much the same as before.
I saw an old patch (http://git.savannah.gnu.org/cgit/guix.git/commit/?id=e311ef4f87f7ad8db2114e5f89961eea0240893b) and, while I'd checked rofi for gdk-pixbuf+svg – before –, – somehow – it made me think to check librsvg, this time, and found that it was using gdk-pixbuf, rather than gdk-pixbuf+svg. I then made a package inheriting librsvg but using gdk-pixbuf+svg, instead, and made a package which inherited rofi but used my librsvg package and, with that installed, rofi worked with .svgs, then.

Am I right in assuming librsvg ought to be using the latter, as the library deals directly with handling SVGs? If so, I can put together a patch to submit.
  

[-- Attachment #2: Type: text/html, Size: 5658 bytes --]

bug#52044: Various Program Settings not Saving and Icons not Recognized

[Liliana Marie Prikler]

Hi,

Am Donnerstag, den 02.12.2021, 02:10 +0000 schrieb Jaft:
> I had noticed that the core-updates-frozen branch had been merged so
> I upgraded but found things pretty much the same as before.
Please come back, you're within the wrong timeline.

> I saw an old patch (
> http://git.savannah.gnu.org/cgit/guix.git/commit/?id=e311ef4f87f7ad8db2114e5f89961eea0240893b
> ) and, while I'd checked rofi for gdk-pixbuf+svg – before –, –
> somehow – it made me think to check librsvg, this time, and found
> that it was using gdk-pixbuf, rather than gdk-pixbuf+svg. I then made
> a package inheriting librsvg but using gdk-pixbuf+svg, instead, and
> made a package which inherited rofi but used my librsvg package and,
> with that installed, rofi worked with .svgs, then.
> 
> Am I right in assuming librsvg ought to be using the latter, as the
> library deals directly with handling SVGs? If so, I can put together
> a patch to submit.
Have you checked using gdk-pixbuf+svg as input to rofi directly?  I
don't see why we would have to go in circles for librsvg, the component
you're trying to use is gdk-pixbuf.

Cheers

bug#52044: Various Program Settings not Saving and Icons not Recognized

[Jaft via Bug reports for GNU Guix]

> Am Donnerstag, den 02.12.2021, 02:10 +0000 schrieb Jaft:
> > I had noticed that the core-updates-frozen branch had been merged so
> > I upgraded but found things pretty much the same as before.
> Please come back, you're within the wrong timeline.

Oh, I don't mean that I used another branch; I saw it got merged to master (I believe) so I just did a guix pull and then guix upgrade. I'm still using stable. Sorry about the confusion!

> > I saw an old patch (
> > http://git.savannah.gnu.org/cgit/guix.git/commit/?id=e311ef4f87f7ad8db2114e5f89961eea0240893b
> > ) and, while I'd checked rofi for gdk-pixbuf+svg – before –, –
> > somehow – it made me think to check librsvg, this time, and found
> > that it was using gdk-pixbuf, rather than gdk-pixbuf+svg. I then made
> > a package inheriting librsvg but using gdk-pixbuf+svg, instead, and
> > made a package which inherited rofi but used my librsvg package and,
> > with that installed, rofi worked with .svgs, then.
> > 
> > Am I right in assuming librsvg ought to be using the latter, as the
> > library deals directly with handling SVGs? If so, I can put together
> > a patch to submit.
> Have you checked using gdk-pixbuf+svg as input to rofi directly?  I
> don't see why we would have to go in circles for librsvg, the component
> you're trying to use is gdk-pixbuf.

I just checked and it does; I was going off of the package formation in Guix but, checking the listed dependencies on the rofi GitHub page (https://github.com/davatorium/rofi/blob/next/INSTALL.md#external-libraries), it does list gdk-pixbuf as one so, perhaps, it makes more sense to build with that instead of librsvg.

I had assumed the package inputs for rofi were already accurate and, if gdk-pixbuf doesn't have SVG support while gdk-pixbuf+svg does, it seemed plausible that gdk-pixbuf+svg would be the preferred package for librsvg as librsvg is dealing with SVGs, perhaps part of the reason for SVG icons not getting rendered in applications like Thunar, XFCE, etc. (that being said, I'm unfamiliar with the librsvg code so, perhaps, this assumption of how the gdk-pixbuf dependency is being used is incorrect, on my part).

In any case, librsvg is not listed as a dependency for rofi while gdk-pixbuf is and swapping librsvg for gdk-pixbuf+svg in the rofi package still seemed to build it alright (and render SVGs) so, at least directly for rofi, directly using dgk-pixbuf+svg would still solve the SVG issue for it.

bug#52044: Various Program Settings not Saving and Icons not Recognized

[Liliana Marie Prikler]

Am Donnerstag, den 02.12.2021, 20:16 +0000 schrieb Jaft:
> > Am Donnerstag, den 02.12.2021, 02:10 +0000 schrieb Jaft:
> > > I had noticed that the core-updates-frozen branch had been merged
> > > so
> > > I upgraded but found things pretty much the same as before.
> > Please come back, you're within the wrong timeline.
> 
> Oh, I don't mean that I used another branch; I saw it got merged to
> master (I believe) so I just did a guix pull and then guix upgrade.
> I'm still using stable. Sorry about the confusion!
I am jokingly referring to the fact that core-updates-frozen is not yet
merged to master.  If you do live two years in the future, please tell
me the lotto numbers.  I need them before I die.

> > > I saw an old patch (
> > > http://git.savannah.gnu.org/cgit/guix.git/commit/?id=e311ef4f87f7ad8db2114e5f89961eea0240893b
> > > ) and, while I'd checked rofi for gdk-pixbuf+svg – before –, –
> > > somehow – it made me think to check librsvg, this time, and found
> > > that it was using gdk-pixbuf, rather than gdk-pixbuf+svg. I then
> > > made a package inheriting librsvg but using gdk-pixbuf+svg,
> > > instead, and made a package which inherited rofi but used my
> > > librsvg package and, with that installed, rofi worked with .svgs,
> > > then.
> > > 
> > > Am I right in assuming librsvg ought to be using the latter, as
> > > the library deals directly with handling SVGs? If so, I can put
> > > together a patch to submit.
> > Have you checked using gdk-pixbuf+svg as input to rofi directly?  I
> > don't see why we would have to go in circles for librsvg, the
> > component you're trying to use is gdk-pixbuf.
> 
> I just checked and it does; I was going off of the package formation
> in Guix but, checking the listed dependencies on the rofi GitHub page
> (
> https://github.com/davatorium/rofi/blob/next/INSTALL.md#external-libraries
> ), it does list gdk-pixbuf as one so, perhaps, it makes more sense to
> build with that instead of librsvg.
> 
> I had assumed the package inputs for rofi were already accurate and,
> if gdk-pixbuf doesn't have SVG support while gdk-pixbuf+svg does, it
> seemed plausible that gdk-pixbuf+svg would be the preferred package
> for librsvg as librsvg is dealing with SVGs, perhaps part of the
> reason for SVG icons not getting rendered in applications like
> Thunar, XFCE, etc. (that being said, I'm unfamiliar with the librsvg
> code so, perhaps, this assumption of how the gdk-pixbuf dependency is
> being used is incorrect, on my part).
Writing a short letter takes time.  So to summarize, librsvg is not
actually a dependency of rofi, gdk-pixbuf (with SVG support) is. 
Anything missing?

> In any case, librsvg is not listed as a dependency for rofi while
> gdk-pixbuf is and swapping librsvg for gdk-pixbuf+svg in the rofi
> package still seemed to build it alright (and render SVGs) so, at
> least directly for rofi, directly using dgk-pixbuf+svg would still
> solve the SVG issue for it.
Now that that's cleared up, you might want to synthesize a patch from
it.  Is there anything else that was swept under the rug and that we'd
need to actually resolve before closing this bug after fixing rofi?

Cheers

bug#52044: Various Program Settings not Saving and Icons not Recognized

[Jaft via Bug reports for GNU Guix]

[-- Attachment #1: Type: text/plain, Size: 4239 bytes --]

> Am Donnerstag, den 02.12.2021, 20:16 +0000 schrieb Jaft:> > > Am Donnerstag, den 02.12.2021, 02:10 +0000 schrieb Jaft:> > > > I had noticed that the core-updates-frozen branch had been merged> > > > so> > > > I upgraded but found things pretty much the same as before.> > > Please come back, you're within the wrong timeline.> > > > Oh, I don't mean that I used another branch; I saw it got merged to> > master (I believe) so I just did a guix pull and then guix upgrade.> > I'm still using stable. Sorry about the confusion!> I am jokingly referring to the fact that core-updates-frozen is not yet> merged to master.  If you do live two years in the future, please tell> me the lotto numbers.  I need them before I die.
Ohhh; haha. Now I get it. Welp; seems I must've misread something, somewhere.

> > > > I saw an old patch (> > > > http://git.savannah.gnu.org/cgit/guix.git/commit/?id=e311ef4f87f7ad8db2114e5f89961eea0240893b> > > > ) and, while I'd checked rofi for gdk-pixbuf+svg – before –, –> > > > somehow – it made me think to check librsvg, this time, and found> > > > that it was using gdk-pixbuf, rather than gdk-pixbuf+svg. I then> > > > made a package inheriting librsvg but using gdk-pixbuf+svg,> > > > instead, and made a package which inherited rofi but used my> > > > librsvg package and, with that installed, rofi worked with .svgs,> > > > then.> > > > > > > > Am I right in assuming librsvg ought to be using the latter, as> > > > the library deals directly with handling SVGs? If so, I can put> > > > together a patch to submit.> > > Have you checked using gdk-pixbuf+svg as input to rofi directly?  I> > > don't see why we would have to go in circles for librsvg, the> > > component you're trying to use is gdk-pixbuf.> > > > I just checked and it does; I was going off of the package formation> > in Guix but, checking the listed dependencies on the rofi GitHub page> > (> > https://github.com/davatorium/rofi/blob/next/INSTALL.md#external-libraries> > ), it does list gdk-pixbuf as one so, perhaps, it makes more sense to> > build with that instead of librsvg.> > > > I had assumed the package inputs for rofi were already accurate and,> > if gdk-pixbuf doesn't have SVG support while gdk-pixbuf+svg does, it> > seemed plausible that gdk-pixbuf+svg would be the preferred package> > for librsvg as librsvg is dealing with SVGs, perhaps part of the> > reason for SVG icons not getting rendered in applications like> > Thunar, XFCE, etc. (that being said, I'm unfamiliar with the librsvg> > code so, perhaps, this assumption of how the gdk-pixbuf dependency is> > being used is incorrect, on my part).> Writing a short letter takes time.  So to summarize, librsvg is not> actually a dependency of rofi, gdk-pixbuf (with SVG support) is. > Anything missing?
I believe that's accurate but I don't have much of any experience with work such as this so I was including my reasoning, in case I was off or misguided at all. That being said, I'd hazard that yours is an accurate summary, in totality.

> > In any case, librsvg is not listed as a dependency for rofi while> > gdk-pixbuf is and swapping librsvg for gdk-pixbuf+svg in the rofi> > package still seemed to build it alright (and render SVGs) so, at> > least directly for rofi, directly using dgk-pixbuf+svg would still> > solve the SVG issue for it.>
> Now that that's cleared up, you might want to synthesize a patch from> it.  Is there anything else that was swept under the rug and that we'd> need to actually resolve before closing this bug after fixing rofi?
Taking another look at some of the other programs I'd mentioned, I'd noticed that file-roller and viewnior are also using gdk-pixbuf; switching those inputs to gdk-pixbuf+svg made them render the icons from Papirus so  was thinking to make patches for those, as well?
Including gdk-pixbuf+svg as an input for thunar resulted in it being able to fully render icons appropriately, finally, but I couldn't figure out where gdk-pixbuf had been used (neither for thunar nor any dependencies), if at all. I'm assuming that simply adding it as an input, rather than trying to trace if gdk-pixbuf is used elsewhere in thunar's dependency graph, is considered bad practice, right?

[-- Attachment #2: Type: text/html, Size: 6468 bytes --]

bug#52044: Various Program Settings not Saving and Icons not Recognized

[Jaft via Bug reports for GNU Guix]

So my original plan of using gdk-pixbuf+svg somewhat can't work as it's not longer a viable package (at least, my attempts to upgrade runs into an error that says so); per commit feab09f72abc6d6eec16a1b8d27c231c747c0e00, it seems the idea is to use librsvg in place of it but, as I noticed in one of my previous E-mails, librsvg doesn't seem to have SVGs work (leastwise, in the programs I originally was using gdk-pixbuf+svg with as I'm not sure how to test in a way that's agnostic; I tried swapping gdk-pixbuf+svg with librsvg in the packages I'd been testing against and, while that allowed me to reisntall the programs without error, viewnior, thunar, and rofi are all back to not being able to render any icons which are SVGs).

bug#52044: Various Program Settings not Saving and Icons not Recognized

[Josselin Poiret via Bug reports for GNU Guix]

Jaft via Bug reports for GNU Guix <bug-guix@gnu.org> writes:

> So my original plan of using gdk-pixbuf+svg somewhat can't work as it's not longer a viable package (at least, my attempts to upgrade runs into an error that says so); per commit feab09f72abc6d6eec16a1b8d27c231c747c0e00, it seems the idea is to use librsvg in place of it but, as I noticed in one of my previous E-mails, librsvg doesn't seem to have SVGs work (leastwise, in the programs I originally was using gdk-pixbuf+svg with as I'm not sure how to test in a way that's agnostic; I tried swapping gdk-pixbuf+svg with librsvg in the packages I'd been testing against and, while that allowed me to reisntall the programs without error, viewnior, thunar, and rofi are all back to not being able to render any icons which are SVGs).

The way gdk-pixbuf works is that it relies on additional loaders
(plugin-like) for different image formats, that it is supposed to find
in ./lib/gdk-pixbuf-2.0/2.10.0/, along with a loaders.cache file pointed
to by the environment variable GDK_PIXBUF_MODULE_FILE.  Since there can
only be one GDK_PIXBUF_MODULE_FILE, it needs to contain all the
different loaders, and so needs to be generated per-profile with a
profile hook.

librsvg provides an svg loader, which thus needs to be present in the
profile of the installed packages.  You would need to propagate librsvg
in addition to having gdk-pixbuf as an input.

The best way to see if gdk-pixbuf should work is to look at `less
$GDK_PIXBUF_MODULE_FILE` and see if there is an entry for svg.

All of this of course relies on the fact that GDK_PIXBUF_MODULE_FILE is
set at some point before starting these programs.  It should be the case
in Guix if you log-in on the tty or graphically through a DM, but there
are some specific edge cases where it might be unset.  If it still
doesn't work for you with the above steps, could you tell us more about
how the programs you list are started, as well as how you log-in?

Best,
Josselin Poiret

bug#52044: Various Program Settings not Saving and Icons not Recognized

[Jaft via Bug reports for GNU Guix]

Hey, Josselin.

Thanks so much for all the info. and walking through how things work; it was really helpful.

In the end, I think I just missed restarting my computer; after doing so, the change that was made regarding gdk-pixbuf seems to've fixed whatever SVG issues I'd been having in a variety of places as everything, using the native packages – unaltered – in Guix, just worked.

I think it's fair to consider this closed as the change seems to've fixed all the SVG issues I'd been encountering.

Thanks so much for everything!






On Friday, December 17, 2021, 09:01:01 AM UTC, Josselin Poiret <dev@jpoiret.xyz> wrote: 





Jaft via Bug reports for GNU Guix <bug-guix@gnu.org> writes:


> So my original plan of using gdk-pixbuf+svg somewhat can't work as it's not longer a viable package (at least, my attempts to upgrade runs into an error that says so); per commit feab09f72abc6d6eec16a1b8d27c231c747c0e00, it seems the idea is to use librsvg in place of it but, as I noticed in one of my previous E-mails, librsvg doesn't seem to have SVGs work (leastwise, in the programs I originally was using gdk-pixbuf+svg with as I'm not sure how to test in a way that's agnostic; I tried swapping gdk-pixbuf+svg with librsvg in the packages I'd been testing against and, while that allowed me to reisntall the programs without error, viewnior, thunar, and rofi are all back to not being able to render any icons which are SVGs).


The way gdk-pixbuf works is that it relies on additional loaders
(plugin-like) for different image formats, that it is supposed to find
in ./lib/gdk-pixbuf-2.0/2.10.0/, along with a loaders.cache file pointed
to by the environment variable GDK_PIXBUF_MODULE_FILE.  Since there can
only be one GDK_PIXBUF_MODULE_FILE, it needs to contain all the
different loaders, and so needs to be generated per-profile with a
profile hook.

librsvg provides an svg loader, which thus needs to be present in the
profile of the installed packages.  You would need to propagate librsvg
in addition to having gdk-pixbuf as an input.

The best way to see if gdk-pixbuf should work is to look at `less
$GDK_PIXBUF_MODULE_FILE` and see if there is an entry for svg.

All of this of course relies on the fact that GDK_PIXBUF_MODULE_FILE is
set at some point before starting these programs.  It should be the case
in Guix if you log-in on the tty or graphically through a DM, but there
are some specific edge cases where it might be unset.  If it still
doesn't work for you with the above steps, could you tell us more about
how the programs you list are started, as well as how you log-in?

Best,
Josselin Poiret

bug#52044: Various Program Settings not Saving and Icons not Recognized

[Liliana Marie Prikler]

Am Montag, dem 03.01.2022 um 22:05 +0000 schrieb Jaft:
> Hey, Josselin.
> 
> Thanks so much for all the info. and walking through how things work;
> it was really helpful.
> 
> In the end, I think I just missed restarting my computer; after doing
> so, the change that was made regarding gdk-pixbuf seems to've fixed
> whatever SVG issues I'd been having in a variety of places as
> everything, using the native packages – unaltered – in Guix, just
> worked.
> 
> I think it's fair to consider this closed as the change seems to've
> fixed all the SVG issues I'd been encountering.
> 
> Thanks so much for everything!
Daily reminder (or neat fun fact if you're new) that Debbugs has no
permissions, so you can close bugs on your own my adding "-done" to the
bug number in the address.

Have a nice day :)