all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Jaft via Bug reports for GNU Guix <bug-guix@gnu.org>
To: Liliana Marie Prikler <liliana.prikler@gmail.com>
Cc: "52044@debbugs.gnu.org" <52044@debbugs.gnu.org>
Subject: bug#52044: Various Program Settings not Saving and Icons not Recognized
Date: Thu, 2 Dec 2021 23:30:56 +0000 (UTC)	[thread overview]
Message-ID: <1064185428.3664991.1638487856653@mail.yahoo.com> (raw)
In-Reply-To: <5a6c09390a1e1b37bbb3c7c4a11b1e2e8504d738.camel@gmail.com>

[-- 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 --]

  reply	other threads:[~2021-12-02 23:32 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1962172575.272360.1637610844717.ref@mail.yahoo.com>
2021-11-22 19:54 ` bug#52044: Various Program Settings not Saving and Icons not Recognized Jaft via Bug reports for GNU Guix
2021-11-26 16:45   ` Liliana Marie Prikler
2021-11-28 12:52     ` Jaft via Bug reports for GNU Guix
2021-11-28 13:57       ` Liliana Marie Prikler
2021-11-29  4:01         ` Jaft via Bug reports for GNU Guix
2021-11-29  5:20           ` Liliana Marie Prikler
2021-12-02  2:10             ` Jaft via Bug reports for GNU Guix
2021-12-02 19:33               ` Liliana Marie Prikler
2021-12-02 20:16                 ` Jaft via Bug reports for GNU Guix
2021-12-02 20:50                   ` Liliana Marie Prikler
2021-12-02 23:30                     ` Jaft via Bug reports for GNU Guix [this message]
2021-12-17  6:56                       ` Jaft via Bug reports for GNU Guix
2021-12-17  9:00                         ` Josselin Poiret via Bug reports for GNU Guix
2022-01-03 22:05                           ` Jaft via Bug reports for GNU Guix
2022-01-04 20:00                             ` Liliana Marie Prikler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1064185428.3664991.1638487856653@mail.yahoo.com \
    --to=bug-guix@gnu.org \
    --cc=52044@debbugs.gnu.org \
    --cc=liliana.prikler@gmail.com \
    --cc=wamm_kd_schmelingski@yahoo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.