Hello Maxime.

> That's what I meant, thanks.  I guess the icons issue is GTK-specific
> and doesn't happen for Qt.

Yes, Qt allows the application resources (like icons) to be put into the
application binary on the build time, and that's how it's done usually.

> These substitutions look fine ... ... ... but they can be improved, by
> replacing the assoc-ref with search-input-file: (search-input-file
> inputs "/bin/ngspice"). That way, it doesn't depend on the package
> name anymore, which is preferred by
> <https://guix.gnu.org/blog/2021/the-big-change/> (*) and makes in some
> cases --with-input more usable. That blog post also has en example.

Done.

> By that logic, since qtbase and qtsvg are used at runtime too, they
> should be propagated as well, but ...
> > I tried to run simulations from the examples provided with the
> > Qucs-S and it seems to me that Qucs-S mostly works as it should.

> ... as you have observed, things work even when they aren't propagated
> (at least for qtbase etc., ngspice and octave have not yet been
> tested).

I usually put into "propagated-inputs" packages that provide some binary
that the current package use in the runtime.

So do you mean that I should rely only on "inputs" package property, and
the inputs will be propagated anyway if they're in use by the package?

> In theory, the propagation shouldn't be required because you added a
> 'substitute*', so in principle qucs-s should know where to find it.

Following your logic I moved NGSpice and Octave from "propagated-inputs"
to "inputs" as they substituted in the sources.

> Also, I noticed these substitutions modify configuration, could you
> verify they aren't saved in wherever qucs-s' configuration file is
> located? Because if they are, then even after an update of octave etc.
> it would seem that qucs-s would still use the old octave.

Good catch.  In my previous patch I substituted NGSpice and Octave in the
part of code that is executed only when no configuration is provided, so
the current binary versions used by default.  However after the first run
Qucs-S stores the paths to the configuration file:

--8<---------------cut here---------------start------------->8---
$ cat ~/.config/qucs/qucs_s.conf [General] ...
NgspiceExecutable=/gnu/store/jl159ilvjzxd0i45xf2z8llbhvl10w54-ngspice-37/bin/ngspice
...
--8<---------------cut here---------------end--------------->8---

So the next time Qucs-S run it gets the paths from the configuration
file.

I changed the substitutions so Qucs-S will ignore the paths to Octave
and NGSpice from the configuration and will always use the paths
provided by Guix.  Also any custom paths to Octave and NGSpice will be
overwritten in the config when the application exits.

That is sub-optimal in my view as we're messing up with the application
configuration logic and if a user wants to change those paths he or she
will be able to remove the config and set the paths in the startup
configuration dialogue, but the settings will have no effect; that will
be a bit confusing.

Yet at least Qucs-S will always use the right Octave/NGSpice path from
GNU Guix.

What do you think?

Here's the patch.