GNU bug report logs - #52044
Various Program Settings not Saving and Icons not Recognized

Previous Next

Full log

Message #35 received at 52044 <at> debbugs.gnu.org (full text, mbox):

From: Jaft <wamm_kd_schmelingski <at> yahoo.com>
To: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
Cc: "52044 <at> debbugs.gnu.org" <52044 <at> debbugs.gnu.org>
Subject: Re: Various Program Settings not Saving and Icons not Recognized
Date: Thu, 2 Dec 2021 23:30:56 +0000 (UTC)

[Message part 1 (text/plain, inline)]

> 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?

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.